Terrain rendering techniques

[Mentat]

Does anyone have any good book recommendations for terrain rendering?

I am interested in implementing a continuous LOD system, and am not sure where to begin.

[princec]

I can offer this advice about terrain rendering: if you're just writing an indie game, do it brute force with a quadtree or octree, and design the complexity around your minimum graphics card spec. Or you will simply spend a lot of time doing something far more complicated than it needs to be to achieve the desired effect.

Cas :)

[EpicBoy]

...and in the end, will probably end up with something slower than a simple quad-tree/brute force rendering scheme. Generally speaking, most LOD schemes are just not worth it these days.

[Nemesis]

For our game we started out with model made of meshes arranged in 2-dimensional array and just rendering what's visible from the player's view up to a fixed distance ahead. Being a straight 3d scroller.. this was quite easy.. the camera always faced in the direction of -Z. In a sense the technique was borrowed from 2d tile-based scrolling where tiles were replaced by meshes representing patches of terrain.

However, we found out that the rendering was taking too much time so the tech guru in the team came up with a rendering algorithm that varied the geometry detail of the mesh depending on distance.. and it actually worked in any direction. It was quite a challenge for him as he had to fit it around our existing model structures in order not to break existing code. He actually managed (bless him!) and we experience a substantial improvement.. to the point that we could afford to extend the horizon and the play area.

The shot below shows the terrain in action in debug mode, with colour edges indicating the transition points between different levels of geometry detail.
http://colinvella.no-ip.com/perihelion/018.jpg
This is a more recent shot:
http://colinvella.no-ip.com/perihelion/057.jpg

Anyway.. enough bragging.. the point I'm trying to make is that it may be worth-while investigating some terrain rendering algorithms particularly if you're rendering large open-air spaces. There are some books available on the subject but you're probably better off looking up whitepapers and the source code examples available on the net.

[ggambett]

I second Nemesis' suggestion. I cut the heightmap into 64x64 chunks and treat each patch independently (edges shared by two different patches are tricky). I update the patch subdivision based on distance, in a discrete scale of 3 steps (camera very close, medium distance, very far). The distance check and eventual recalculation is done 2-4 times per second or based on distance (this depends on the patch size and the speed of the camera).

This has the advantages of LOD (fewer triangles) and it has a relatively small overhead (since some of the patches are recalculated sometimes and not too close in time)

[Kai Backman]

Buy, buy, buy (or use OpenSource). Look at somthing like Torque or OGRE that have a included terrain renderers. If you decide to write your own, apply to a post graduate position at your local university and drop the game project .. ;)

Well, it might not be that dramatic, but you will complete your project much faster by using someone elses code... :)

[Greg Squire]

I agree with Mistaril. Why reinvent the wheel? There's so many terrain engines out there, even many free open source ones. Find one or buy on and use it. Your time would be better spent on the details of the game instead of the rendering engine.

[ggambett]

I agree with Mistaril. Why reinvent the wheel? There's so many terrain engines out there, even many free open source ones. Find one or buy on and use it.
In fact, the terrain I described above is a highly modified version of one of OGRE's terrain plugins. So I didn't reinvent the wheel, I adapted it to my car :) More advantages of open source!

[Dan MacDonald]

I'm working on a platform where off the shelf terrain rendering isn't available. One of the better systems I've seen for CLOD is

http://www.gamasutra.com/reatures/20000228/ulrich_01.htm

If your not familiar with the exsisting body of knowlege surrounding CLOD terrain you may have a hard time with the article, it's written assuming you are familiar with the implementation details of the other methods. (Lindstrom, Rottger, ROAM, etc.)

[kerchen]

When I was building a terrain renderer last spring, I found a couple of books that provided a good starting point for learning about the topic:

"Focus on 3D Terrain Programming" by Trent Polack. ISBN 1-59200-028-2

"Real-Time 3D Terrain Engines using C++ and DirectX 9" by Greg Snook. ISBN 1-58450-204-5

However, I was focused on making a lunar landscape, so I wasn't very interested in the bits about making realistic looking trees and grass. Also, a lot of the material in these books was drawn from the Internet (no big surprise there), so you can probably find everything you need online.

[EpicBoy]

FYI, the terrain in Unreal Tournament 2003/2004 was brute force. It was broken up into smaller segments which were culled against portals, but that was it. No LOD was used.

[marcusl]

Try Cipher engine (http://www.cipherengine.com), just had a landscape renderer added, cool well supported engine with full source for $100..

Marcus

[Nemesis]

FYI, the terrain in Unreal Tournament 2003/2004 was brute force. It was broken up into smaller segments which were culled against portals, but that was it. No LOD was used.
Are you sure the maps aren't mostly indoor? I have a feeling that the "outdoor" bits aren't height-map based i.e. probably modeled like the indoor bits.

[EpicBoy]

I work at Epic. :)

Trust me, we have a real honest to goodness terrain system. Check out some of the larger Onslaught maps. They are huge, entirely outdoor, and rendered brute force (with portal culling of terrain sectors).

[DragonsIOA]

In my current project I'm just using brute force with quadtree culling. I tried out some of the LOD approaches but didn't find them to be worth the trouble since my grid is only 256x256. Fillrate has proven to be the bottleneck since I use texture splatting, and reflective water effects. Of course, my game requires hardware T&L due to the sheer amount of geometry used so things may be different if you're targetting a lower spec.

[Nemesis]

I work at Epic. :)
Ummm.. ok.. can't argue there! :) I guess that as with many optimisation techniques, there are specific cases where using CLOD / ROAM etc. is worthwhile.. e.g. some really large terrain.

[mkovacic]

I second Nemesis' suggestion. I cut the heightmap into 64x64 chunks and treat each patch independently (edges shared by two different patches are tricky). I update the patch subdivision based on distance, in a discrete scale of 3 steps (camera very close, medium distance, very far).
If you're already limiting yourself to 3 discrete steps you should just precalculate them and be done with it. If you use "flanges" for chunk-to-chunk connectivity (strips of quads "hanging" from the chunk edges), you'll never need to touch your vertex data at all.

Anyway, the approach I would recommend is basically this:

http://www.tulrich.com/geekstuff/chunklod.html ,

with "flanges" (I don't know if that's what Thatcher is using these days, it very well may be), and no geomorphing.

[Indiepath]

As stated before...Blitz3D or Torque does this nicely.

[EpicBoy]

Blitz terrains are notoriously slow and don't allow nice texturing techniques.

[Mentat]

Thanks to everyone for your input!

I will check out the recommendations made in this thread.

[Chaster]

Having made about 8 different terrain engines myself (for various projects), I would recommend that you stay away from ROAM (it's terrible for modern TNL graphics cards). ROAM was designed before hardware TNL became prevalent, and its' dependence on the CPU will bottleneck any modern graphics card.

The method I favor (as most hardware friendly) is chunked geomipmapping. Do a google on "geomipmap" and you should find a paper or two on it. There are modifications you can do to it to make it CLOD, and if implemented well, it does not stall out your pipeline like other CLOD algorithms do.

On the other hand, with the advent of programmable GPUs, people have been coming back to CLOD but done entirely on the video card. This can be VERY fast and very smooth, but you are eliminating the entire market of people who don't have the nice programmable GPU cards (which might be fine for you... shrug).. Of course, the geomipmap algorithm can ALSO be implemented as a GPU program, so..... ;)

People can and do go on and on and on about the merits of various approaches... So I will just stop here.. heh.

Just my .02...

Chaster