export optimized mesh non-integer vertx positions and tiling

[schamberlin]

Hi! I'm a new L3DT user and very impressed so far. I've got a couple of questions about mesh exporting and tiling.

What exactly does "export optimized mesh" do for optimizations? Does it only remove vertices, or does it also relocate them?

When I export a 256 x 256 heightmap as optimized mesh in OBJ format and look at it in a text editor, the X and Y coordinates are almost all integers between -128 and +127. But a few percent of the vertices have non-integer XY coords like 211.6875, 243. Is that expected? If they're all integers from -128 to 127 then I can use GL_BYTE as the vertex format in OpenGL ES to save memory, but with values like 211.6875 I can't.

Probably nobody actually uses a heightmap as small as 256x256, but a similar problem applies to larger maps when trying to use GL_SHORT instead of GL_FLOAT. I think any operation that moves a heightpost so it's no longer on a regular grid is eliminating one big advantage of using heightmaps. Or am I overlooking something?

Semi-related question: how can tiled maps be rendered with good performance, since it will create texture maps that aren't a power-of-two size? For example, a 2048x2048 map with a 256x256 tile size will generate a bunch of 257x257 tiles and textures, because there's one column and row of overlap between tiles to make them seamless. As far as I know, non-power-of-two sized textures will suffer a performance penalty when rendering, or may not even work at all on some hardware. I see there's a checkbox in the exporter to resize images to the nearest power of two, but then you'll have a 256x256 texture applied to a mesh with 257x257 vertices. Does that still look OK?

Thanks for making a great tool!

[Aaron]

Hi Schamberlin,

Welcome to the forum, and thanks for the question.

The mesh optimiser doesn't relocate vertices as such. However, the grid spacing of the vertices will be different for some areas in certain circumstances. If the heightmap size in X and Y is one greater than a multiple of the ROAM decimator's patch size (64px), then the grid will be uniformly spaced everywhere. So, for instance, a 513x257px heightmap will use a uniformly spaced grid everywhere. If the size condition is not not met, then the patches on the north and/or eastern edges would be partially unfilled, which makes the decimator algorithm most unhappy. To fix that, I resample the leftover pixels in the partially unfilled patches to fill the patch completely (using linear interpolation), which has the affect of giving a finer grid spacing for just those patches.

In short, if your size in X and Y is a multiple of 64 plus one, you'll have a regularly spaced grid everywhere.

I see there's a checkbox in the exporter to resize images to the nearest power of two, but then you'll have a 256x256 texture applied to a mesh with 257x257 vertices. Does that still look OK?

As far as I know, yes. I can't tell the difference visually. Please let me know if you find otherwise.

Best regards,
Aaron.

[schamberlin]

Thanks, that makes sense. It appears it's not possible to create heightmaps in non-power-of-two sizes in L3DT, though. If I create a new project and set the heightmap size to 513 x 257, when I get to the design map wizard step it says the heightmap must be resized to 512 x 256. So it looks like I'm stuck with power-of-two sized heightmaps, which means a non-uniformly spaced vertex grid after mesh decimation? Or find an external mesh decimator tool that doesn't care about power-of-two sizing, or maybe try writing my own?

[Aaron]

Hi Schamberlin,

You can generate a heightmap at, say, 512x256, then use the 'Operations->Heightfield->Resize menu option to bump it up to 513x257 for the mesh decimator export.

Please note you should probably do the heightfield resizing after you've generated the other map layers (textures, alphas, etc.), as I'd guess you probably don't want those layers to have funky +1 sizes too.

Cheers,
Aaron.