SpeedTree 6.0 introduced the concept of optimized/variable vertex declarations for the computer-generated vertex shaders used with the 3D vegetation geometry for all LODs. While very memory efficient and faster on platforms that are vertex fetch limited, it means that the client application cannot depend on fixed structures to represent their vegetation's vertex data. Especially for integrations that utilitize only the Core library to extract the vertex data, this can be terribly frustrating.

The 5.x Compilation Mode was added to the SpeedTree Compiler that remedies this issue. It essentially enables all effects for all LODs, forcing all possible vertex data into the SRT file and results in the same vertex shader declarations for each type of geometry (e.g. branches, fronds, etc). This is labelled “5.x Mode” because this is how that version of SpeedTree operated. In addition to static vertex declarations per geometry type, a single vertex/pixel shader pair is generated per geometry type.

The 5.x Compilation Mode is an option in the SpeedTree Compiler application. Specifically, as illustrated below, it's a “Material merging” option in the Compile settings.

The Compiler and SRT Exporter will generate a set of standard 7.x SRT files. The SDK functions as it normally would on these files, only the vertex declarations are static. Also note that each of the SRenderStates in each SRT file will return true when SRenderState::Is5xModeActive() is called. If your application depends on this compilation mode, it's probably a good idea to test this condition or at the very least place in an assert() statement. See our example code for more.

A set of non-standard shaders is also exported. Instead of the hashed filenames normally produced (e.g. “18289_e38_ps.fx”), one set of vertex & pixel shaders are generated per geometry type. Specifically:

• Branches_vs/ps.fx

• FrondsAndCaps_vs/ps.fx

• Leaves_vs/ps.fx [non-camera-facing 3D leaf meshes]

• FacingLeaves_vs/ps.fx [traditional camera-facing meshes]

• RigidMeshes_vs/ps.fx
• Billboard_vs/ps.fx

• Grass_vs/ps.fx

These shaders aren't meant to be used as-is, but should be seen as a starting point for your own shaders, particularly if wind effects are to be used. Note wind restrictions in the next section.

Due to the radically different approach post-5.x versions of the SDK take to wind and vertex declarations in general compared to 5.x, it's impossible to export intact, complete 6.x wind effects in this mode. Specifically, all wind is disabled in the exported shaders by a single “#define ST_WIND_IS_ACTIVE 0” near the top of the source files.

SpeedTree uses a number of mutually exclusive wind effects. For example, the fronds of a palm tree have a very different motion than say, the branches of a large oak tree. If those branches are secondary branches, there's a good chance they'll be represented by frond geometry. That is, they'll be textures which are pictures of individual branches, but they'll still be considered frond geometry in the pipeline. So, when the FrondsAndCaps_fx/ps.fx shaders are generated, it's not possible to accommodate both the behavior of the smaller oak fronds and the palm tree. Versions newer than 5.x make separate shaders for each.

Clients can take the generated 5.x shader files and modify/recompile them to suit their needs by #define different wind-related macros at the top of the file.