SpeedTree's wind effects are implemented through a powerful system that is both flexible and scalable, scaling all the way to cinematic quality used in dozens of feature films. Surprisingly to many, in the games SDK, wind effects are implemented largely by vertex shaders. There are no bones or bone weights used in the simulation. Due to this approach, every instance can have a unique wind signature so that two instances of the same base tree standing right beside each other will have noticeably different wind behavior.

There's also an aggressive but seamless LOD system where hero trees can have fully implemented wind effects up close, but fade those effects to something more modest as the camera moves away, finally to a gentle global sway as the tree turns into a low-res 3D mesh or billboard.

An example of our real-time wind system appears in the video below:

jA3yMnVzrdw ;#; Wind Behavior Preview in SpeedTree Modeler ;#;

Finally, there is a rolling wind effect that really helps to tie a set of trees together to make them look and behave like a single forest. It is particularly effective for grass fields.

Other pages in the wind documentation section cover the details, but the broad strokes of the wind 'pipeline' are as follows:

1. Modeler: Define the wind you want inside the SpeedTree Modeler. The highest level of wind is defined in this application, but note that for each modular wind effect you enable, more instructions will be added to the final vertex shader. This page details each effect option and its relative expense.
   
   
2. SPM File:When an SPM file is saved from the Modeler and loaded into the Compiler, it comes with a number of SpeedTree-specific per-vertex values (i.e. vectors, weights, frequencies) that drive the wind behavior. The SPM also has all of the “global” values the user entered for the various wind behavior (e.g. is rolling wind enabled, if so, it'll contain the noise parameters, etc).
   
   
3. Compiler: Within the Compiler, users have the option of toggling wind altogether, toggling just the rolling wind effect, and most importantly, tuning the wind LOD levels for each base tree. Once completed, each tree is baked into the SRT file, to be loaded and rendered by the SDK.
   
   
4. Shader Templates: When the Compiler compiles SPM files into SRT files, it also generates a set of shaders to efficiently render that model based on the user preferences, set in both the Modeler and the Compiler. These templates contain the shader source that controls the wind algorithm and seamless LOD behavior. These templates can be freely modified. The main file is Include_Wind.fx which houses the high-level function SpeedTreeWindModel().
   
   
5. C++ SDK: The CPU plays an important role in the wind simulation. Each base tree (SRT file) contains the user wind settings from the Modeler which feed the CWind class. As the forest frames are rendered, each base tree's CWind class acts as a state machine for the wind simulation for that type of tree, computing and uploading a few control variables to the wind shader constant buffer. This means that there will be some synchronization between instances of the same base class, but there are shader effects that serve to make each instance behave uniquely.
   
   

In the Modeler, there is an AppWizard that's pretty good at taking a solid first shot at tuning a tree model's wind parameters realistically. Users are free to tune its results once the wizard has been executed. The video below shows the results of running the Wind AppWizard on our Coconut Palm model:

GJiY4sG4xb4 ;#; Example Results with Modeler Wind AppWizard ;#;