Geomipmapped implementations seem to be the big thing now, although some people still swear by ROAM or CLOD. I personally found that Geomipmaps with a decent crack patching scheme and geomorphing worked extremely well.

Frankly, I think that even ROAM 2.0 is not worth using. ROAM 2 is good for large scale terrain visualization...but for games, it's not worth it. It still does too much on the CPU for essentially negligible benefits. So if you're doing generic terrain rendering it might be worth looking at, but if you're writing a game/game engine, don't waste your time.

(Same thing goes for most adaptive algorithms, including CLOD and BDAM.)

After implementing geomorphing (with geomipmapping) myself recently, I can't help but think its not really worth it. Which is odd 'cos before (and from a visual point of view) I really like the idea.

Pros:
- Smooth LOD changes, no popping
- Do it in a vertex shader so static geometry
- You can morph your crack fixing method (like skirts) which keeps things nice and tight.

Cons:
- Whopping amounts of extra memory
- Very little actual visual gain
- Precalc stage for morph values is a time consuming (to code *and* to run)
- Because of complex precalc, changing the heightmap gets much more tricky to do on the fly
- Morphing can actually be visually distracting

I'm inclined to say that with the memory and time saved by avoiding geomorphing then you could probably push your LOD distances out further and make the actual popping pretty much unnoticable.

HVs seem to push the opinion that it's better now to just push the patches unloded (brute force). This has been said on NVidia events 2 years ago and in ATI speeches at the GDC.

Here's a quite from my blog here at gamedev (17th august):

Quote:Yesterday evening I browsed the ATI website because I wanted to download the new RenderMonkey. And there I stumbled onto the speech held by Richard Huddy about Speed Optimizing and such stuff. Quite interesting. The most interesting part was his talking about the triangle throughput and terrain rendering. It was something like : "Don't bother about Roam or any other LOD implementation for terrain. Your target triangle throughput is 40-50 million triangles per frame. So if your terrain is only 5 million triangles, then just draw it brute force. You should only bother on how you put it into the vertexbuffers..."

Personally I tested it out with a 120k triangles terrain (untextured) which rendered at an impressive 560 FPS on my Ati 9800 pro. That's ~67 million triangles. Adding texture would bring that down but the raw power is there (on modern cards).

Whatever LOD method you use, there's always (!) an overhead for calculating the right LOD.

Roam has the (major) disadvantage that in worst case you have to recalculate everything every frame.

Roam 2 is a little bit better since it adds hardware friendly triangle stitching.

GeoMipmap is fast and (unless you alter your terrain in realtime) you can precalculate the error metric table for a given screen resolution offline. Same applies to the LOD tables if you stitch to a given patch size.

So much for the terrain LOD.

The second part you've touched in this thread is "How to prevent unnecessary terrain patch drawing". This could be a whole topic on its own since there are many ways how to prevent terrain patches to be drawn if not necessary. And they still are all used.

The most used algorithm to manage this is octree (or the special subform of quadtrees) which are actually containment algorithms. You could also say that they are axis aligned subdivision processes and therefor very comparable with binary trees (such as bsps).

Now, Octrees (and their subform quadtrees) have the inconvenience that you have a lot of tree traversal if you have a high view range. There are some optimizations that can be done but this adds memory usage and calculation time.

Loose Octrees can solve some problems you have when entities (such as buildings, trees or vehicles) are just on the border of a subcube. You then expand the cube until a critical size where you snap it back into place and move the entity into the adjacent cube. (this is also applicable to quadtrees; it has been described in one of the game programming gems books).

PVS systems have the *big* inconvenience that they are difficult to calculate and increase the memory usage the more you detail the grid you use to calculate the visibilities. Also, you might want to add a "height" to the PVS if your camera is not ground bound.

Occlusion culling seems to be the way to go if you have large, very detailed terrains and your camera is ground bound (flying above the terrain renders 90% of the occlusion volumes invalid). This can be quite memory and test efficient but get's more complicated once you use other occlusion objects than cubes (be it axis aligned or not). Altering the terrain in real time is a no-no here, since it would take just to much time to recalculation the occlusion volume (if you're not using cubes).

I have to dig more into the other methods you mentioned but the above list gives you a litle overview of what has been/is used.

While we're talking about geomipmapping, I think Chunked LOD or something in between the two is more suitable for larger terrain. The problem with GMM is that the patches are all of the same size, so you end up using too many patches for large landscapes. Instead of reducing the number of triangles per patch, like GMM does, it's better to increase the size of the patch itself (it's kind of like taking 4 lower LOD GMM patches, and pasting them together to a single patch). With the help of vertex shaders, you can even make your x, y, and indices arrays shared, and only change the z (assumming z is "up"), normals, and texture coordinates from one patch to the next (you can make the indices buffer shared even without vertex shaders).

Quote:Original post by Metron
Occlusion culling seems to be the way to go if you have large, very detailed terrains and your camera is ground bound (flying above the terrain renders 90% of the occlusion volumes invalid). This can be quite memory and test efficient but get's more complicated once you use other occlusion objects than cubes (be it axis aligned or not). Altering the terrain in real time is a no-no here, since it would take just to much time to recalculation the occlusion volume (if you're not using cubes).

Depending on the exact situation, you may be able to use a low LOD version of the terrain (offset down somewhat) for occlusion culling, or find some other solution. You just have to make sure that your occlusion mesh is always inside the rendered geometry, so that you won't cull away something that's visible. It's not impossible, just tricky.

i think everything that needs to be said has been said but i'll way in with this brute force vs LOD.

brute force as NVidia or Ati are keen to point out is a perfectly good way of rendering your terrain, and in most cases it's true, for a small patch of terrain it's fine. Unreal Tournament uses brute force for it's terrain for example.

However for larger patches of terrain, anything above a few hundred square metres or kilometre and you should be looking into LOD'ing algorithms.

In my own opinion ROAM and ROAM 2.0 aren't worth it, ChunkedLOD is interesting but there are numerous optimisations that have been implemented so don't forget to look around for those, GeoMipMapping is very quick and simple, but don't bother with the GeoMorphing, just increse the size of the patches to take advantage of the Gfx cards rendering power, if you make that value variable enough then you can adjust on a per graphics card basis, so you can effectively test it's performance and adjust you patch sizes for the machines spec.

I've never used Clipmaps personally but the results seem universally awesome such as Lutz's planet renderer (which looks amazing dude!) [grin]

anyway good luck, go for brute force to start with, implement a simple LOD system or GeoMipMapping without Geomorphing and start playing around. At the end of the day it depends what you're trying to achieve for the kind of engine/game you're trying to make.

Andy

My take is to not care about LOD, write your engine, sort by Shader, then by Textures.
If you are NOT CPU limited, then consider LOD, otherwise, forget about it.