[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Written by Jorrit Tyberghein, (jorrit.tyberghein@uz.kuleuven.ac.be).
This mesh object represents a landscape engine. It features four static LOD levels and dynamic lighting for one directional light. In future it will also have support for dynamic shadows but this is still a todo at this moment.
The basic principle behind the terrain engine is that the entire terrain is divided in a number of blocks. Usually this is equal to 8x8 blocks for the terrain but this is something that you can control. The division into blocks is important for three reasons. The first reason is that LOD selection happens on a block level. i.e. every block is shown at one level of LOD independent from the other blocks. The second reason is that visibility culling for terrain engine also works on block granularity (also the visibility algo itself goes deeper for doing the actual tests). The last reason for the blocks is that every block can have a seperate texture. This is important because some hardware has texture limitations and you often want to overlay a very big texture on a landscape. Since very block has its own texture you can do this easily.
The terrain engine is based on a height function (as opposed to a heightmap
alone). Support for heightmaps is provided too by converting a heightmap
to a height function. But in general you can feed the terrain engine with
any function height=heightfunc(x,y)
. You can also optionally give
a normal function. If not given the landscape engine will calculate normals
from the height function automatically.
Every block is further divided into a grid. For example, with a grid of 16x16 every block will have 16x16 quads or 16x16x2 triangles at the highest detail level. The combination of blocks and grids control how many triangles the entire terrain will have.
The terrain engine supports four levels of LOD which it will use independently for every block. Level 0 is highest detail. You can control the distance at which every LOD level kicks in and you can also control the quality of every level.
The terrain engine supports a visibility algorithm based on a quad-tree. The visibility algorithm will cull away geometry on a blocks level (i.e. either an entire block is visible or not). But internally it will use a quad-tree which can (and should) go deeper than the blocks resolution to make sure that the visibility testing is fine enough.
Every block has its own texture. You can use a big texture and split it into individual parts. One part for every block. Crystal Space also has a texture generation utility which is able to create realistic terrain textures given several base textures and a heightmap.
The terrain engine also supports one colored directional light without shadows. In the future we will have support for dynamic shadows.
The following SCF class names are used (for CS_LOAD_PLUGIN()
):
Objects in this plugin implement the following SCF interfaces (get
with SCF_QUERY_INTERFACE()
):
This plugin has no factory state interface.
The fire mesh factory loader has no parameters.
`iTerrFuncState' is the SCF interface that you can use to set/get settings for a landscape object. The definition of this interface can be found in `CS/include/imesh/terrfunc.h' and that's also the include file you need to include in your applications to use this plugin. Using this interface you can access the terrain parameters.
The terrain loader recognizes the following keywords:
<factory>factoryName</factory>
<material index="" />
<material>materialName</material>
<material start="" end="">materialName%d</material>
printf
style string
containing a %d
to indicate the number used for the material
name. `start' and `end' indicate the range of materials
to set (block numbers).
<correctseams w="" h="" />
(partsize-2)*8+2
. In this case (with
partsize equal to 128) this would mean a total texture of 1010x1010 where
every block gets a 128x128 texture where the borders are shared with the
adjacent block (hence the 126x126 that is really allocated for one block).
If you follow these guidelines you can then use <correctseams w="128" h="128" />
and you will have perfectly aligned textures for all 8x8 blocks.
<blocks x="" y="" />
<grid x="" y="" />
<grid x="16 y="16" />
means that every block will use
16x16 quads (or 16x16x2 triangles) at highest detail. The default value
for `grid' is 8x8.
<topleft x="" y="" z="" />
<scale x="" y="" z="" />
<color red="" green="" blue="" />
1,1,1
.
<dirlight>
<position x="" y="" z="" /> <color red="" green="" blue="" /> </dirlight> |
x,y,z
is a normal vector for the light.
red,green,blue
is the color of the light.
<loddist level="" distance="" />
<lodcost level="" cost="" />
0.03
, 0.08
, and 0.2
. So `loddist'
controls at which distance a new LOD level is selected while
`lodcost' controls the quality of every LOD level. The base
quality (i.e. highest quality) of every block is controlled with the
`grid' command.
<quaddepth>quaddepthValue</quaddepth>
<vistest />
<heightmap>
<image>imageFile</image> <scale>scaleValue</scale> <shift>shiftValue</shift> </heightmap> |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |