Memory
There are numerous techniques to employ to reduce memory usage in the SDK and with the SpeedTree applications Modeler and Compiler. To monitor how much heap space and vertex/index buffer memory the SDK is using, please refer to this section. To reduce areas of possible excess memory use, follow these guidelines.
Loading SRT files can consume a fair amount of memory (specifically, the size of the SRT file). Here are a few tips for reducing memory usage after load:
There are a number of steps that artists can take to lower memory usage when creating the SpeedTree assets in the SpeedTree Modeler.
The vertex buffers are serialized straight out of the SRT file. The vertex declarations vary per-model and per-material. The more effects that are enabled through the Compiler's Effect LOD dialog, the larger the vertex declarations will be, increasing the vertex buffer size. 16-bit float and single-byte values are the basic types used. Minimum-effects vertex declarations can be as small as 16 bytes, where high-effect declarations may get as large as 48, 52, or more bytes.
Note that the SDK will use 16-bit indices whenever possible but will shift into 32-bit mode on an as-needed basis. For one tree model (i.e. one SRT file), the SDK will look at all of the branch geometry LODs collectively. If the number of vertices exceeds 65,535, it will use 32-bit indices only for that one tree model's branch geometry. The SDK will then look at fronds and then finally leaf meshes, using the appropriate index size each time.
—-
The bulk of the memory used by the SDK comes from the texture maps it loads. We encourage programmers to familiarize themselves with the SpeedTree Compiler application, which generates and manages all of the textures used by individual trees and whole forests.
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.
The CInstance class is used to represent both tree instances (using the derived CTreeInstance class) and grass instances (using CGrassInstance). One of these objects are needed for each of the visible instances. For dense scenes or those with long draw distances, the size of this class may be an issue. The SDK offers a compile-time option for reducing the size somewhat. If SPEEDTREE_COMPRESS_INSTANCE_VECTORS is #defined in Forest.h, each vector is stored in three bytes. When undefined, each vector is stored as a Vec3, or twelve bytes, four times the space. When millions of instances are in play, this eighteen-byte difference can grow large. The trade-off however, is reduced performance when streaming instance lists on the fly, particularly the billboards. The instance vertex buffers expect full-sized floats there and the added conversion on the fly takes its toll.
A common mistake is employing too large a draw distance. Long draw distances impact both memory and performance in the following ways:
Use the heap reserve system in the SDK to set limits for various quantities, receiving warnings in most cases when the limits are exceeded.