|[ < ]||[ > ]||[ << ]||[ Up ]||[ >> ]||[Top]||[Contents]||[Index]||[ ? ]||[ Search: ]|
To facilitate future improvements the plugin is split into several smaller and communicating components
At current there are two implementations of data feeder, one renderer and one collision 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
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.
3D offset in XZ-plane of cell relative to mesh center. See more under coordinate systems
3D size of cell in CS units. Defines the xz size as well as the max height scale.
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.
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.
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
Block resolution in number of gridpoints. Should be power of two, other values are rounded down. Default value is 16.
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.
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.
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
File name of the heightmap data.
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.
File name of the material map data.
Height offset value to add to height values after loading.
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.