Shader system overview

Developers are free to use their own shaders and are not bound by any SpeedTree templates or conventions. The sole restriction is that the vertex declaration of the vertex shaders must match the vertex packing set in the Lua script in the Modeler used on .stsdk export. You are free to use different vertex formats for each .stsdk/shader pairing if you wish – you are not restricted to single format.

The shaders we use for our reference forest are located in [SDK Installation Path]/SampleForest/Shaders/Vegetation/. We have provided sample shaders for forward and deferred rendering. The vertex declarations for the tree shaders match Standard.lua, the grass shaders match Standard_Grass.lua, and the billboard shaders match Standard_Billboard.lua, all of which can be found in the Modeler installation. Refer to render configuration system for details on how to match .stsdk files and render states to specific shaders.

During graphics initialization, through the callback-based render configuration system, the Runtime SDK allows the host application to set which shader to use for each render configuration. In our example in the reference application, decisions are made as to when to use forward or deferred shaders (the reference application can be configured either way), when to use tree-specific, grass-specific, billboard/imposter-specifc shaders, and when to use the depth-only or fogged variants of those shaders.

Wind

Each of the sample shaders use what we call “SpeedTree Games 9” wind (SpeedTree has different algorithms based on version and speed requirements). For SpeedTree's wind approach, see Wind Overview.

While the How to use this SDK section details different ways to use the Runtime SDK, there is an approach we see some developers take related to wind that involves leveraging the wind system but bypassing the rest of the SDK run-time. There are several ways this can be done, but the core components are:

  • Per-Vertex Data: Find a way to preserve the per-vertex wind data generated by the Modeler. This is easily done by using the Runtime SDK's .stsdk file loading functions, but the Modeler can also export all vertex data using the .xml export. This per-vertex data is key to implementing SpeedTree's unique and efficient approach.
  • CPU-Side State: The Runtime SDK uses the SpeedTree::CWindStateMgr class, defined in Include/SpeedTree/Core/SpeedTreeWind.h, to advance the wind state for each base tree. Values are uploaded via shader constants for the wind shader.
  • Wind Shaders: The Runtime SDK includes several wind types but the main file for the wind system is Include/SpeedTree/Core/SpeedTreeWind.h. All wind modes leverage both the per-vertex data and the wind state variables to achieve the wind animation entirely in the vertex shader stage.

Shader compilation

We include a utility for compiling shaders for use with the SpeedTree Runtime SDK (speedtree_shader_compiler.exe in the [SDK Install Path/SampleForest/Shaders/ folder). The batch file sitting next to it, compile_all_speedtree_shaders.bat, recurses through the folder structure, compiling all .hlsl files that it can find. It distinguishes vertex and pixel shaders by their “_vs” or “_ps” suffixes, an SDK standard.

While you are free to invoke fxc.exe directly (for example: for DirectX 11), the compilation utility will also #define a few macros for each target platform. For example, when compiling to DirectX 11, it will invoke fxc.exe with /DST_DIRECTX11=1, letting the SpeedTree-specific include files know which platform is being targeted. It will also place the compiled files in a subfolder next to the source. In the case of DirectX 11, the subfolder will always be called shaders_directx11/. This is where the SpeedTree Runtime SDK will look for platform-specific compiled files by default, but developers are free to change this in our C++ source.

Note

The Linux version of the Runtime SDK has no Linux scripts for recompiling shaders in [SpeedTree SDK]/SampleForest/Shaders/.