TerrainViz performance depends more on the CPU capabilities than on the GPU speed because the terrain tessellation computed by TerrainViz does not produce a huge set of triangles.
But because tessellation is computed at each frame, the calculation of the mesh is very CPU consuming.
The tessellation is done on the total amount of data supplied. For instance for an input terrain of 10000*10000 (height values) the total number of triangles would be 10000*10000*2 = 200 million triangles!
The process consists of evaluating these 200 million triangles and approximating the geometry to keep some thousands of triangles to reproduce the terrain. This process is time consuming.
Whereas in Open Inventor the number of displayed triangles can be the main limit, in TerrainViz, the tessellation is the primary limiting factor.
The GPU performance and amount of RAM become more important for texturing needs when working with a deep quadtree of textures.
Holes are used to avoid drawing parts of the terrain where elevation values match the condition set in the SbTVizData class and its derived classes.
For instance, if you have a terrain with undefined zones, you should set a single elevation value for all of the samples within these areas.
Then set this elevation value as the hole value, and the undefined areas will not be drawn.
This feature can also be used to suppress parts of the terrain such as the sea, rivers, and also used as a kind of a clipping plane.
The TerrainViz viewer supports some new constrained motion behaviors: fly, constant elevation, and walk modes.
These modes are available through the right mouse menu or through the bottons on the right side.
It also includes some navigation tools (compass, information display) and allows addition of custom tools.
TerrainViz supports its own file format: a .dat file (ASCII or binary) for elevations, raster images (JPEG, PNG, TIFF...) for textures, and an XML file describing the layout of the terrain (See next topic). The elevation file is a simple grid of altitude values plus a header.
If you have some georeferenced files (dted, arc info grid, geotiff...) you must use the preprocessing classes to transform them into the internal format of TerrainViz. You provide the preprocessor classes with the data you want to use, and these classes select, organize, and merge the data to fit the internal format.
The elevation data is organized as a binary or an ASCII file with a header of the following type:
# TerrainViz V1.0 ascii ------------------> Version number and ascii or binary file
# type uchar -------------------------------> Type of values (uchar, ushort, float,...)
# size 599 599 ----------------------------> Number of samples per line and per row
# encoding LITTLE_ENDIAN ---------> Encoding type: little or big endian
Then each elevation value is printed and separated with a space character as follows:
# TerrainViz V1.0 ascii
# type uchar
# size 599 599
# encoding LITTLE_ENDIAN
128 123 119 119 119 121 123 124 124 124 123 123 123 123 126 127 126 123
123 123 128 132 133 135 136 137 138 138 138 138 138 138 138 138 138 138
...
Currently, TerrainViz only deals with regular grids for elevation data. The only way to use any other data structure is to convert your data to a regular grid. You will have to sample and interpolate your data to get a compatible grid. Then you will need to add a header as decribed before (See previous topic). We plan to process additional data structures in future releases of TerrainViz.
Currently, TerrainViz cannot prevent specific areas of the terrain from being refined in the tessellation process. (We anticipate this feature will be available in a future release.) So, to avoid having the terrain appear to shift around objects you should change the geometry of the terrain, making flat areas under the objects that you want to place on the terrain surface. As flat areas are less sensitive to the refinement process, this will allow the objects to "stick" to the surface better.
As the terrain surface changes due to triangulation refinement, an easy way to keep the linear and surface information is to make an offscreen image of the desired information at the same resolution as the highest resolution textures and with 4-component rendering selected (i.e., using setComponents(SoOffscreenRenderer::RGB_TRANSPARENCY)). This offscreen image can then be supplied as an overlay texture to the texture preprocessor and merged with the other textures.
For example, to add country borders to your terrain, you can make an offscreen image in which the borders are opaque and everything else is transparent. Then supply it as an overlay texture to the texture preprocessor.