If a man owns land, the land owns him - Ralph Waldo Emerson

Just back from a weekend break in London so I did not program for the past few days. Coming home yesterday we were delayed in the train station for 7 hours so while sitting around I had plenty of time to think about what I wanted to achieve with the terrain segment of the Decade Engine. Here are some improvements. (I know I said in my last post that I was just going to add Vertex Arrays and VBO's but after some consideration I believe that the following additions are also required.)

1) Change from using a .raw file to using my own custom format. The .raw file used 1 byte for each value. This limits the range of values from 0 to 255 and only whole numbers are included. I didn't notice any issue with this when I was rendering small terrains (up to 512x512) however now that much larger terrains are being rendered 8192x8192 (134,217,728 faces) a very undesirable stair case effect is emerging. Take a look at the attached screenshots. As the values of the terrain are rounded the terrain grows in increments making it look unnatural. I am going to create my own file format which will use floats instead of unsigned chars. This has the advantage of being correctly able represent the terrain however will result in a larger file size and a longer read/write time for the file. I believe the advantage greatly outweighs the problems.

Stepped Terrain caused by .raw file data storage

2) Now that larger terrains are being rendered some more intelligent culling of patches is required. Simply checking if each patch is visible to the camera (by checking collision with the viewing frustum) is not enough. The mentioned 8192x8192 terrain segment is made up of 232,324 patches. With the current implementation this results in 232,324 frustum checks per frame. By adding a simple node tree most of these checks can be bypassed.

A node tree is a method of subdividing the mesh (terrain in this instance) into smaller sections. For instance, with the terrain I would divide it horizontally and vertically through the centre resulting in 4 segments, top right, top left, bottom right and bottom left. These segments would then be recursively divided until the required tree depth is reached. When doing frustum checks the terrain algorithm would first check collision with the node tree. If the Top Right Segment (or any other segment) was not visible by the frustum all of its children could immediately be ignored as not visible. If the Tree Node is visible by the frustum each of its children would be checked etc..etc... I expect that this will give a huge performance increase when used with large terrains for both geomipmapped and brute force terrains.

Stepped Terrain caused by .raw file data storage

3) Add support for Vertex Arrays and VBO's in geomipmapped terrains.