I'm currently contemplating building a simple(?) terrain 'engine'. In the past I've used heightmaps and the usual stuff like that. What I'm really interested in right now is a way to have overhangs\tunnels in my landscape; this excludes using heightmaps of course. This probably means I have to create the terrain as a mesh and load it into my app. No problem so far.. However, I'm looking for a way for this mesh to display a lot of detail close to the camera and less further away; with heightmapped terrains you would, for example, use geomipmaps\ROAM for this. Is there a way to apply techniques like this to an arbitrary mesh without creating cracks in realtime? I was thinking about creating a low poly mesh and use that as a 'skeleton' for subdivision. During runtime I can then subdivide the quads and displace the new vertices using some algorithm. Is this feasible? A screenshot to show you what I would like to do: http://img186.imageshack.us/img186/78/teapottp7.png Any replies are very welcome! Regards, Paul

Hi Paul.

Have you read the article in chapter 1 of GPU Gems 3 (Generating Complex Procedural Terrains using the GPU? I think it's the one implemented in NVidia's cascade demo (http://www.nzone.com/object/nzone_cascades_home.html) and looks very good. It is implemented using DirectX10 features though. I've seen another promising volumetric approach to terrain rendering somewhere but I can't find the bookmark now...

Otherwise any general mesh lod algorithm is worth looking at - you know of progressive meshes by Hoppe (http://research.microsoft.com/~hoppe)?

Thanks for your reply ndhb!
That Nvidia demo looks awesome! However, I'll be sticking to dx9 for a while for obvious reasons. If I understand it correctly, they are using a dynamic marching cubes algorithm on the cpu but it's not progressive as far as I know. Thinking about a 'dynamic progressive marching cubes' algorithm makes my head hurt :P
The progressive meshes by Hoppe are really what I was looking for. Thanks for the link! Maybe I should've googled 'progressive mesh' instead of 'adaptive mesh' in the first place :)

Thanks for your reply NineYearCycle. I've looked at your link and that is indeed what I'm after. However, I'm wondering why they are dynamically building a mesh around the voxels because they state that their terrain is static.

I was thinking about using the volume approach in a map editor. For example, you would specify a heightmap for the terrain surface and then start carving out features in the terrain. The resulting volume would then be tesselated (marching cubes), optimized a bit, saved as a mesh and imported in the game. Ingame this mesh would be progressively rendered using Hoppe's technique (see ndhb's post). Isn't this approach more efficient than theirs?

On another note; the goal is to create a 'simple' game set in this terrain. However I'd like the game to run smoothly on mid-end machines while also allowing the game to look good on high-end machines. Now, are there any conventions about the max. number of poly's one throws at a graphics card? How many polygons can I expect a mid-end graphics card to handle per second? I know that frametime depends on a lot of other factors, but a rough estimate would be great. Furthermore, I know that these values are accessible from ATi\NVidia, but I've read somewhere that the provided values are only attained under special circumstances.

[Edited by - Pauluss86 on March 10, 2008 12:34:35 PM]

I think the volume approach when sculpting, and exporting it as a progressive mesh data structure sounds like a good idea. I would very much like to see the result when you are there.

If you send the vertices and indicies efficiently, one guess could be more than 200.000, but you probably don't want to go above 500.000 per frame. Maybe mid-end is GF6 series now?