SpeedTree wind effect can scale widely. That is, they can be off, simple, or very complex (as in 400+ instruction vertex shaders). As such, users should take great care about when to scale up and by how much.
|Note: This page focuses largely on shader/GPU performance tuning as there is little to be done to impact CPU performance because almost the entire wind computation load is in the vertex shaders. CWind::Advance() (often invoked through CForest::WindAdvance()) is the only function that uses any reasonable amount of measure CPU time.
Tuning in the Compiler Application
For each tree in the Compiler application, users can tune the wind LOD. As long as smooth LOD is enabled (the Effect LOD dialog option per tree), the Compiler will generate shaders that smoothly transition between wind effects so there will be no noticeable pop. There are four options:
Full: Use every wind effect as specified in the Modeler application. This can often be tremendously expensive and should be used with caution, as the full wind effect is often used in cinematic applications and can add several hundred instructions to a vertex shader. See the section below on tuning parameters available in the Modeler.
For wind LOD, go to global or no wind as soon as possible. We have found that for trees will full wind, going from full in the highest LOD to global in the next works very well in terms of performance and perception. For smaller models like shrubs and bushes, going to no wind as soon as possible is also recommended since when rendered very small, wind effects are difficult to perceive.
|Note: If a tree model has any wind effect other than “None” in the last discrete LOD, the billboard shader will be compiled with global wind enabled.
To A/B test the overall impact wind computations are having on your scene, you easily disable all wind effects my unchecking “Enable wind” in the Compiler→Effects options.
Tuning in the Modeler Application
Within the Modeler application, there are several controls that can be used to enable or disable particular wind effects. Each of these options may represent a significant jump in the vertex shader instruction counts, so they should be carefully tuned. Access them by clicking on the 3D fan icon in the Modeler. These options appear throughout the property bar:
Branch Motion→Level N→Style: Options include “Disabled”, “Simple”, “Directional”, and “Directional (palm frond style)”. These styles are listed in order of performance from fastest to slowest. Each level adds a new component to the oscillating behavior of the branches, requiring more shader instructions. “Simple” is often enough when wind direction indication does not play a critical in the application.
Branch Motion→Level N→Oscillation Style: The “Basic” setting performs a simple, approximated sinusoidal oscillation. The “Swaying” option simulates a more realistic, erratic branch motion at the expense of extra shader instructions.
Branch Motion→Rolling→Enabled: Options include “None”, “Level 1”, “Level 2”, and “Both”. These options are listed in order of performance from fastest to slowest. Each branch level that has rolling enabled utilizes an approximated sinusoidal wave to simulate waves of wind traveling through the model at the expense of extra shader instructions.
Leaf Motion→Ripple N→Style: Options include “None”, “Vertex normal”, and “Computed”, listed in performance order from fastest to slowest. When using the “Vertex normal” option, leaf vertices oscillate along their vertex normal, requiring no extra per-vertex data. The “Computed” option requires the oscillation vector (packed into a single float) be uploaded with each vertex and is therefore slower. This option should be limited to use with two-sided meshes (e.g., palm fronds with distinct tops and bottoms) or specialized meshes such as Spanish moss.
Leaf Motion→Tumble N→Twitch→Enabled: Available only when tumbling is active, this option simulates the random, unpredictable oscillations of small leaves in windy conditions. It piggy backs on the existing tumbling calls for the motion but adds a sinusoidal approximation and a pow( ) call to the shaders.
Frond Motion→Ripple→Style: Options include “None”, “One-sided”, and “Two-sided”, listed in order of performance from fastest to slowest. “One-sided” rippling requires no extra per-vertex data and ripples each vertex along its normal. “Two-sided” rippling requires a ripple direction (packed into a single float) be uploaded for each vertex. This style should be restricted for use with two-sided geometry such as palm fronds with distinct tops and bottoms.