4.10.11.1 General description

To facilitate future improvements the plugin is split into several smaller and communicating components

• Terrain system - defines cells, keeps track of loaded data, dispatch request to the collision, rendering and data feeder parts.
• Data feeder - provide height data on demand by either loading it from disk or generating it by for example fractal algorithms.
• Renderer - converts height data into triangles and feeds them into the rendering pipeline, providing LoD, culling etc.
• Collision system - do collision detection between height data and rays, segments and triangles.

At current there are two implementations of data feeder, one renderer and one collision system.

Terrain System

The terrain system is the central part in ‘terrain2’ plugin as it contains definitions of cells as well as holding all other parts together.

The main component in the terrain system is the ‘cell’. Each cell within a terrain system is a self contained area of the 2d map that contains its own height map, material map, renderer-, feeder- and collision-settings. The self-contained aspect is also related to that the cell is the unit used for paging (on-demand loading and unloading) of terrain data.

Each cell is defined by a small set of properties

Coordinate system

One important point to remember when dealing with terrain2 is the coordinate spaces it use. There are two major coordinat spaces to keep track of, namely ‘heightmap space’ and ‘model space’.

Heightmap space is the 2D coordinate space in which the heightmap is specified, it has (0,0) in upper left corner of heightmap and x increase to the right while y increase down. Most operations on cell level, such as ‘iTerrainCell::GetNormal()’ and ‘iTerrainCell::GetHeight()’ operates on coordinates in heightmap space.

The second coordinate space is the 3d model space, which is the normal per mesh-object coordinate space that all meshes in CS have. The transform between model space and world space is defined by the iMovable of the mesh wrapper. All rendering is in model space as well as some mesh global APIs such as HitBeam.

The transform between heightmap space and model space have a fixed orientation (rotation) while the linear components are set via the per cell size and offset.

Renderer

The renderer plugin is the most obviously visible plugin. It takes the terrain height data and transforms it into a list of triangles for rendering and in the process does such things as mesh simplifcation (LOD algorithms).

In the current codebase of CS there is just one implementation of the rendering plugin which is based on the "bruteblock" algorithm. Bruteblock works by dividing the full cell grid into four quadrants, then continuing to subdivide those until either the lowest subdivision level is reached or the LOD algorithm determins there should be no more subdivisions.

Bruteblock accepts a number of named parameters to control the LOD behaviour

Data feeders

The data feeder is responsible for loading and pre-loading of terrain height and material map data. There are two implementations, the simple and the threaded data feeders. They both utilize the same loading code and properties however the threaded feeder have the ability to preload data in the background at the cost of some overhead and higher memory usage.

The feeders take three parameters

Collision plugin

The collision plugin is responsible for doing collision detection between the height map and triangles or segments/rays. There are currently just a single implementation which use a variant of the digital differential algorithm to compute the intersection points directly without having to triangulate the terrain. The collision plugin have no properties.

This document was generated using texi2html 1.76.