Experiment - Large Terrain Rendering

I took a few days off of the bug fixing process to investigate on adding a terrain system to GameStart.

I considered a few different methods:

• The simpler one with no lod and a fixed resolution (usually pretty low due to the lack of lod). These systems are very quick to program but are far from optimal on all fronts. They usually consume a lot of unnecessary memory for the static mesh and will most always still have the heightmap in memory to feed the collision engine. While you can put a high-level manager around patches of static terrain to increase the area and resolution you cover there's really no point in trying. You're going to have an insane amount of paging to keep the memory from exploding and much more than with a smarter approach, so let's move on.
• Old-school state of the art such as ROAM are very good on the polygon count front but require too much CPU work while the GPU got very good at dumbly pushing millions of triangles on screen. I did not entirely discard this solution but went for another first.
• Chunked-lod this is a very easy to implement solution which can be made to use the GPU in a very efficient manner. That's where I choose to start my implementation.

I started with a KD-tree implementation which while it seemed like a good idea was really overly complex due to the unconstrained patch aspect ratio (a square terrain split in two starts by giving two rectangles). Worst, it required to either fully store the display lists on the GPU (same caveat as the simpler method) or use immediate mode.

Switching to a quad-tree solved most of these problems. The quad-tree keeps a constant level of tessellation within a patch as each finer level increase the resolution by 2 while reducing the patch size by 2.

By exploiting this fact a single VBO can be used and reused to draw any patch in the quad-tree at any level of detail. The VBO only needs to be scaled and positioned appropriately and programmed to fetch the correct height map samples.

To note, this approach can be fully done on the GPU by fetching the height map from the vertex shader. That is not what I am doing at the moment but this is a minor extension to program and it will reduce the CPU load even more.

The current implementation integrates perfectly with the system. Multiple terrain can be declared, any size and arbitrary maximal precision, the only limit is the available memory since there is no paging support. However, 250mo can buy you the following: 4km² at 50cm precision with fully dynamic shadows (covering 1.5km in front of the camera) on a 8600M running at 15 to 60fps depending on the viewpoint. Oh yes, there is DOF, SSAO and noise filtering everything on a two monitor setup on a laptop from the editor so yeah... Performances ought to be even better in real life conditions.

It's looking good already and there's definitively quite a few things left to be done to enhance all this. The terrain uses the same material definition as any other object so its shader tree can be reprogrammed if necessary.