Tiled Terrain as static meshes

[JonChaos]

Hi
Im in search for a tool or app which allows to export a heigthmap in small tiles as static mashes.
Maybe 3 meshes per tile to do manual lod.

Does someone know of a tool capable of doing this ?

If there is no such tool would it be possible to write a irrlicht app for doing it ?
The app would read the heightmap file , cut it into tiles and load them .
Then it would manually set the lod for the tiles and save them as meshes.

Would such a thing could be doable withouth much hacking of the irrlicht engine ?

[hybrid]

Why do you want the terrain to be exported as meshes? It's basically possible, I just something similar for reading a terrain's heightmap from a huge raw map. I built a smaller heightmap by reading the chosen values from the huge map, wrote it back into a smaller heightmap and reloaded it into terrain scene nodes.
the RAW loader is flawed, though, it only works for 32bit floats, so be aware of that. I'll probably change these things in the near future.

[vitek]

Why do you want the terrain to be exported as meshes?

Performance would be one good reason. Creating a mesh from a heightmap is likely to be more expensive than just reading a simple mesh. Another good reason is that he could open the tiles in some 3D editor to modify them.

the RAW loader is flawed, though, it only works for 32bit floats, so be aware of that. I'll probably change these things in the near future.

That is a problem with the RAW heightmap format. There is no header data inside the heightmap file that tells you the format, the file is just raw pixel data. Usually it is 8 or 16bit integer data, but sometimes it is float.

Travis

[hybrid]

But you'd loose LOD support and other things specific to the terrain scene node. So faster loading on cost of render performance.
The problem with the RAW loader is that it allows for setting bitwidth, but it loads directly into a float. So there's no chance to make it work with other bitwidth than 32bit native floats. It should read into an int or float (set by some other parameter) and allow scaling the values. Moreover, the interface is not exposed, yet, which makes it almost impossible to access the RAW loader.

[Umbra]

For just the terrain i dont see why you need LOD but for objects you can still use LOD.

And about making the meshes just use any 3d rendering soft like Lightwave,Blender or 3DS. Make the big mesh and then slice it up. OR just make the terrain parts direcly.

[hybrid]

Now, a full terrain scene node has almost 65535 vertices, that's quite a lot to be rendered all the time even from a distance. That's what makes the current terrain scene node quite fast - it dynamically reduces that number. But this LOD mechanism is specific to terrain scene nodes.
There is no automatic LOD support for other scene nodes in Irrlicht.
He wants to make a terrain from some huge heightmap, not model it manually in some app.

[vitek]

But you'd loose LOD support and other things specific to the terrain scene node. So faster loading on cost of render performance.

Not necessarily. Nobody said he just wanted to throw the meshes into a mesh scene node. Given a mesh of triangles, you can do the same dynamic LOD that is done inside the current terrain node. The frustum culling could also be done quite easily.

Travis

[Umbra]

Now, a full terrain scene node has almost 65535 vertices, that's quite a lot to be rendered all the time even from a distance. That's what makes the current terrain scene node quite fast - it dynamically reduces that number. But this LOD mechanism is specific to terrain scene nodes.
There is no automatic LOD support for other scene nodes in Irrlicht.
He wants to make a terrain from some huge heightmap, not model it manually in some app.

Why would it be 65535 ?? that might be true if you use an hightmap. Certanly NOT when making the terrain with static meshes

If you make the terrain from static meshes its up to you how many meshes are in screen (In the terrain).

[JonChaos]

Why do you want the terrain to be exported as meshes?

There are many reasons:
- In a big terrain you would always have to page terrain data.
If you load the terrain as heightmaps there it will always waste performance when converting the heightmap to a mesh.
With static meshes this step can be avoidet.

- Overhangs , caves and such are easier to do with static meshes

- you can optimize the meshes by hand or with tools while with heightmaps you have to trust in the algorithm doing this


In the end i want to have 3 meshes per tile.
This is going to be done mostly with tools to reduce the poly count of the meshes.

Missing lod isnt a problem also as im going to use lua scripts to do the paging of terrain and objects and i want to use 3 levels of terrain lod.


I already found a tool which allows to export heightmaps as 3d meshes.
http://www.ridgecrest.ca.us/%7Ejslayton/wilbur.html

Wilbur can export the heightmaps as wavefront .obj files.


Now i only need a tool to tile the heightmaps / textures / detailmaps.

[pinballwizard]

Missing lod isnt a problem also as im going to use lua scripts to do the paging of terrain and objects and i want to use 3 levels of terrain lod.

This sounds really interesting, as I've been thinking about something similar (also using Lua).

How many tiles do you plan to keep in memory at once? Will you be swapping in/out tiles based on a 2D map (x,y) or a 3D map (x,y,z)? How will you organize the tiles (and their LOD's) on disk? Will textures be bundled with the tiles? How will you prevent your game "stuttering" as tiles are loaded (IIRC, Irrlicht is not thread safe, ruling out loading in a separate thread)?