• View
• Edit
• History
• Print

GroundRendering

Ground Rendering means the rendering of the cells mostly. It should include water as well (which is not implemented by cell rendering), however currently this is not the case.
Including the water rendering into the ground rendering architecture is a TODO.

Plugin architecture

The ground rendering architecture consists of plugins. This architecture makes development a lot easier, as the plugin can be reloaded without restarting boson and only very little recompilation (only the plugin) is necessary.

Communication between the main boson code and the ground renderers occur only through the BoGroundRendererManager and the BoGroundRenderer clases.

The class BoGroundRendererManager is used to create a new ground renderer, by giving the class name of the desired renderer (such as BoDefaultGroundRenderer) to it. The manager then creates the new ground renderer from the plugin library factory and initializes it.

Ground Renderers

The actual ground renderer consists of several levels. The bottom level is the class 'BoGroundRenderer' which primarily defines the ground renderer interface.
Additionally this class implements a couple of methods that are unlikely to change and therefore don't need to be in the plugin. An example for this is the rendering of the cell grid.
So the BoGroundRenderer class is supposed to be an interface - most ground rendering code should go to derived classes.

The class BoGroundRendererBase in the plugin is derived of BoGroundRenderer and is the base class of every ground renderer.
This class does all tasks that are common to all ground renderers, such as building the list of visible cells. Anything that should be done by all ground renderers should go here.

The actual ground renderers are derived of BoGroundRendererBase, such as BoDefaultGroundRenderer. These classes implement the actual renderer.

Building list of visible cells

The first task of rendering is to build a list of visible cells. This should do both, hide fogged cells and make sure that only cells inside the view frustum are rendered (performance).

This is done using a quadtree currently.

Additionally the tree also implements LOD: when at a certain depth a node is at least partially visible, but very far away from the camera, then a single large cell covering the whole node is added to the list instead of all cells of the node.

Note that building the cell list is probably the most important part of the ground renderer. By reducing the amount of cells that are to be displayed, the actual rendering can be made a lot faster with only a little of overhead (the tree is extremely fast). However this is a very difficult and tricky part, as e.g. LOD usually reduces quality to a certain degree. A good LOD implementation is therefore one that can't be noticed.