Crystal Space 2.0.0: 4.10.10.1 General description

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

#### 4.10.10.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

Setting | Description
gridsize | Number of height points in each direction. Should be one more than power of two (2^n+1) such as 129,257,1025. CAUTION: For time being the grid must be square.
position | 3D offset in XZ-plane of cell relative to mesh center. See more under coordinate systems
size | 3D size of cell in CS units. Defines the xz size as well as the max height scale.
heightdata | Array of height data for each gridpoint, ordered left to right, top to bottom. Other geometric properties of the landscape such as normal direction and tangent plane is derived from the height data.

#### 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

Parameter | Description
block resolution | Block resolution in number of gridpoints. Should be power of two, other values are rounded down. Default value is 16.
lod splitcoeff | Coefficient used in the calculation of per block lod level. Can approximatly be interpreted as the distance to split in number of block-widths. Default value is 16.
splat distance | Distance where to switch from material splatting to basemap rendering. Passed on to the shader via the `‘texture lod distance’` shader variable. Default value is 200.

#### 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

Parameter | Description
heightmap source | File name of the heightmap data.
heightmap format | Data format in the heightmap source. Possible values are IMAGE, RAW8, RAW16LE, RAW16BE, RAW32LE, RAW32BE, RAWFLOATLE, RAWFLOATBE. The number specify the bit width, le/be little endian or big endian. Default value is IMAGE which means the data is a image to be loaded by the normal image loaders (such as a png image). When loading a raw format map, make sure to use the right format as no data validation is done. Invalid data can cause your application to crash.
materialmap source | File name of the material map data.
offset | Height offset value to add to height values after loading.

#### 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.

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

This document was generated using texi2html 1.76.