Keeping memory usage low

There are numerous techniques to reduce memory usage in the SDK and the SpeedTree Modeler application. To monitor how much heap space and vertex/index buffer memory the SDK is using, see Tracking Resource Usage. To reduce areas of possible excess memory use, follow these guidelines.

Loading .stsdk files can consume a fair amount of memory (specifically, the size of the .stsdk file reflects that amount of RAM it will take to load), but there are some measures that can be taken to reduce memory usage after the .stsdk file is loaded:

1. After querying the tree's geometry to build your application's vertex and index buffers, call CCore::DeleteGeometry() on the loaded object to delete the internal copies of the vertex and index buffers, which represent the bulk of the memory allocated by the load function.
   
   
2. In addition to keeping art assets of reasonable size, using the smallest number of unique .stsdk files in a scene is also recommended (note that this does not restrict the number of trees/instances in a scene, only the number of unique/base trees). Not only will it reduce the amount of memory used, but it will increase the speed of the forest renders through a reduction in state changes. A few unique .stsdk files in a given forest can go along way if varied rotations and scales are used.
   
   
3. If you're done using the SpeedTree SDK at any point in the application, call CCore::ShutDown(). It's a static function that will clear up the last remaining memory used by the SDK.

There are a number of steps that artists can take to lower memory usage when creating assets in the SpeedTree Modeler.

• Keep in mind that each level of detail (LOD) level uses memory. Specifically, each LOD level uses independent vertex and index buffers, so using using fewer LOD levels will save overall memory. Ultimately, after calling CCore::DeleteGeometry(), this memory will reside on the GPU, not in system RAM.

• Take care not to overbuild geometry. How much of the branches and fronds are still visible when the leaves are on? If they can't be eliminated, can their resolution be reduced? Refer to the Modeler documentation for polygon-reducing techniques to employ.

• Take advantage of the excellent LOD system and drop out detail as rapidly as possible. Look at trees in the SpeedTree games model library for good example LOD implementations.

• Try to keep the total number of vertices for all LODs for each geometry type below 65,535. Once this threshold is crossed, the SDK index buffer will double in size as it will switch from 16-bit to 32-bit indices. While it takes a substantially detailed real-time tree model to exceed 65k vertices, the SpeedTree pipeline will adapt as necessary.

Outside of the Core library, where per-tree memory costs are paramount, the Forest library's memory consumption is directly related to the number of visible tree/grass instances.

A common mistake is employing too large a draw distance. Long draw distances impact both memory and performance in the following ways:

• More memory consumed by the CVisibleInstances class to represent the visible 3D trees, their LOD values, and all of the visible billboards.

• The culling procedures will take longer to execute due to the increased cell count (although 3D tree processing will remain largely unaffected).

• Longer draw distances will consume considerably more billboard instance vertex buffer space.

Use the heap reserve system in the SDK to set limits for various quantities, receiving warnings in most cases when the limits are exceeded.