Table of Contents

Culling & Population

Terrain System

Note that the terrain system in the SpeedTree SDK does not support any specific file format for terrain population. It will simply provide the client application with blank cells to populate as needed. The client is free to populate those cells based on any data or algorithm available. Note that the reference application does use an example-level class called CTerrainData that IDV uses to load terrain data. Feel free to use this as a basis for your own population data system if helpful.


Culling

Once the CTerrain object has been properly initialized, it can be called on to provide a list of visible terrain cells for any given view. The example below shows how to cull the terrain for a given view and then traverse both the newly created cells and the overall visible cells.









Culling results are returned through the STerrainCullResults structure:







The TTerrainCellArray type is just a typedef for CArray. CArray is SpeedTree's lightweight version of STL's std::vector<>.



Population

To populate the new cells, the client application will need to provide a height for any (x,y) position that the terrain system requests. Additionally, the application could be configured to include texture coordinates, per-vertex normals, ambient occlusion hints, colors, splat mixtures, etc. Note that this data is being passed directly into a CGeometryBuffer object, not a generic structure.

IDV has set up an example terrain rendering system, but there is no reason your application cannot be modified to upload different vertex attributes, use a modified shader, etc. The following code illustrates a simplified example of how to populate a single terrain cell (as returned in STerrainCullResults::m_aCellsToUpdate). A working example can be found in Application.cpp of the SpeedTree SDK reference application in the function CApplication::PopulateTerrainCells().








Note that speed is a key issue in this function. While it's only called when the camera roams into a new area, if this function is too slow, it will cause lagging as the camera roams as several cells can be created in one frame. Terrain resolution also has a strong effect, especially since it has to move in powers-of-two+1 sequence: 17, 33, 65, 129, etc. Each move up in resolution will actually quadruple the amount of work done by this function (as well as the vertex shader).

If your application requires a minimum of Shader Model 3.0, then it could be possible to only populate a vertex buffer with (x,y) locations and pull the height values from a texture lookup, greatly reducing the CPU impact of this function.