Hi, I am planning to code a real-time terrain engine with LOD, which will serve as a basis to some further experiments such as plugging in a physics library like ODE and testing some AI algorithms on bots … I was wondering what the community's experience was with the current state of the art in real-time terrain algorithms. I have done some googling and came across these interesting sites: http://research.microsoft.com/~hoppe/ geoclipmaps http://www-static.cc.gatech.edu/~lindstro/software/soar/ SOAR http://www.llnl.gov/graphics/ROAM/ ROAM http://tulrich.com/geekstuff/chunklod.html Chunked-LOD. http://www.vterrain.org/LOD/Implementations/index.html which gives a list of Terrain LOD implementations Geoclipmaps appears to be the latest algorithm around (2004), the paper claims it to be relatively simple to implement and looks rather efficient, as it can nearly run on the GPU alone. But on my side the paper raises some questions : How are the nested clipmaps fed with new data ? From my profane understanding, the coarser clipmap is fed from decompression of some data that perhaps lies somewhere in RAM or on the disk. As for the other nested clipmaps, the input comes from their parent clipmap, using super sampling, plus some noise to add more details. If this is correct, I find this rather strange as it would mean that the most precise data in use would be the one given at the topmost and coarsest level, the lowest levels only adding noise to it. From what I have understood of SOAR, it appears as collection of clever but subtle algorithms, which are not trivial to implement and which forbids the use of VBOs. But I am not sure of this. Could someone correct me if I am wrong, as if this is true it would be a major drawback considering today’s hardware. I haven’t read ROAM’s paper yet, but from what I came across on the net, it appears as an obsolete algorithm considering today’s hardware, though a clever one at the time. Finally Chunked-LOD is the one I am currently considering, as it looks relatively simple to implement and from a naïve perspective the tree structure appears rather well suited to extend it to do future stuff. Sorry for this long post, but I am curious to read the feedback from people who implemented these algorithms, as for my part I have only read the papers and haven’t dug into the real stuff yet.

Hi. I'm interested in the same area as you. I think most people believe that the state-of-the-art engine depends on what your requirements are. Some algorithms are good for large heightmaps (maybe 8k+), some are easier to texture, some use very little ram, some takes up more Shader space. It's a balance...

I can't answer your specific questions about geometry clipmaps but look at the paper from http://www.terrain.dk for a good review of existing approaches. Also Dachsbachers paper is quite thorough, http://deposit.ddb.de/cgi-bin/dokserv?idn=979598087.

If you plan to release your engine you might want to know that some techniques in Hoppe's geometry clipmaps have a patent pending (as far as I know). I don't know the details about license.

Many people go for "Thatchers, Chunked LOD" or another variation of De Boer's algorithm. One thing to watch out for with these is the possible complications blending textures between different levels.

"SOAR" and especially "ROAM" are considered obsolute by many people because of the high(er) CPU requirements. If you plan on a low-specification engine (not requiring latest GPU's), they are not completely crazy however.

If your heightmap doesn't exceed around 1-2k samples you can get away with brute-force on modern hardware. That is, assuming you have a static terrain geometry and use Display List or similar or use VBO's with dynamic terrain geometry. View Frustum Culling and Terrain Occlusion approaches are important topics as well, regardless of choosing LOD or non-LOD.

- Nicolai

Quote:Original post by ndhbIf your heightmap doesn't exceed around 1-2k samples you can get away with brute-force on modern hardware.

Even if it does, you can "get away with" in many cases. It depends what you are doing.

If you write a flight simulator or a space simulation, then obviously your viewing range goes from dozens to hundreds of kilometers to possibly hundred thousands of kilometers. Obviously, there is no way you can do without level of detail, as you would have billions and billions of vertices to render.

However, most games offer rather something on the order of 50-250 meters of viewing range, and for this application, brute force with coarse frustum culling of terrain tiles is perfectly sufficient. If you throw a few dozen tiles each having a rough 1k vertices (for a tile size of 33x33, for example) at the graphics card, then any reasonably modern hardware could not care less, even if you do several passes. Remember that the beauty of fixed LOD heightmaps lies in the fact that almost all of it is constant data, so the actual bandwidth needed is surprisingly low.
Also, exploiting the vertex cache works very nicely with brute force (calculate once, apply to all -- can even hardcode indices). Of course it works nicely with LOD schemes too, but it is a lot more complicated.

Actually, brute force is not only sufficient, in most cases it is better than any level of detail scheme, as the GPU can easily handle it, your CPU cycles go into other important things, and you avoid a lot of complexity and the known problems that adhere to level of detail schemes.

Very true about brute force and gaming. The work I am doing myself is a simulation enviroment and not exactly a game. Most research papers the last few years (that I have found) have concentrated on HUGE terrains (for GIS etc. purposes) which is usually not what you need for games. Also take into consideration any issues that might arise when applying textures, shadows, lighting. Many of the aforementioned articles doesn't discuss these important issues in detail.

A useful approach for texturing the terrain resulting from the algorithm by de Boer, is discussed in the paper by Anders Brodersen, "Real-Time Visualization of Large Textured Terrains" (www.daimi.au.dk/~rip/pubs/TerrainVis.pdf).

- Nicolai

Thank you both for your answers and for the links you have put, they seem very interesting. I totally agree on the fact that the papers I have read disregard other considerations such as the ones you have mentioned, considerations which I do not master at all. So I think I will document myself on these matters, keeping at the back of my head the things I have understood concerning terrain LOD.

Now as for the requirements that I have, the answer is that I have nothing precise yet, I am working on these for a hobby. But the big picture of what I would like to achieve, would be a 3D environment with a minimum of physics, in which I would be able to perform some experiments on AI. So I have no real eye candy constraints, and I was wandering if I could drop them to the benefit of building an environment handling big domains. Anyway thanks again for the time you have spend answering my questions.