PART III: Terrain Rendering with a Scene Graph

The first two parts of this series of posts covered the development and evolution of my terrain rendering code from my previous generation Brainstorm game engine. This post will cover in details the current implementations limitations and my proposed ideas for improving the Terrain rendering for the new Brainstorm game engine.

Wasted effort when entire parent is within the viewing frustum. For example a parent which is completely within the viewing frustum contains 16 leaf nodes. despite knowing that the entire parent is visible we still go down the quad tree and conduct another 20 visibility checks before the decision is made to render the 16 leaf nodes.

Alternatively instead of returning a simple Boolean when testing a viewing volume for visibility we could return an enumerated value that could be represent as.

enum Visibility
{
     NOT_VISIBLE;
     PARTIALLY;
     COMPLETELY;
}

From this we could program the visiblity checking code to automatically pass all child nodes as visible and add them to the render list if the parent is determined to be completely visible. Alternatively if it is only partially visible then it should continue to check child visiblility as per normal. I believe that the extra overhead of calculating if a bounding volume is partially or completely visible would be less effort than the wasted visibility checks.

Level of Detail (LoD) considerations. The terrain pixel shader is quite intensive requiring a total of 15 texture look ups and blending operation on a per pixel basis. While this provides great detail when the terrain is up close, the distant patches still use the complicated pixel shader for not much visual benefit ie the terrain is too far away for the player to notice the amazing textures. A single triangle could be covered by just 1 pixel or even less.

So instead of the texture lookup on distant terrain patches the terrain textures can be simplied into a single average RGB colour that is blended, this takes some of the load off the pixel shader without any loss in experience by the player. but no matter how simple we make the pixel shader the amount of effort it takes to process the required vertices is there. Surely there is something we can do to improve that.

As the terrain patches get further away from the player so too do you lose the need for so many verticies to represent the complexity of the terrain, a number of vertices may start to appear as a single point so why not skip a couple of pointless vertices? Well that's exactly what we'll cover in the final part of this series as we tie LoD into our scene graph system to give us a complete Terrain rendering solution.