The SpeedTree Compiler application gives artists a great deal of flexibility in controlling the speed vs. beauty tradeoff.In those times when speed may be lacking, artists and programmers should both be aware of the types of settings that can make a big difference in performance, particularly when using the SpeedTree SDK.
Also see the GPU Performance tips page for general advice, much of which is controlled through the Compiler app.
The SpeedTree model library is quite a large assembly of art assets. It contains hundreds of high resolution textures, with no regard for what a game engine may require. Resolutions are generally powers of two and can be as large as 2048 pixels high for a single bark texture. Our philosophy is that it's much easier to scale down than up, but be careful to use an appropriate size.
The Compiler deals with essentially two types of textures: independent and atlased. Independent textures are generally those that require wrapping or are otherwise of a large resolution, like branch diffuse/normal and detail maps. These are most often simply scaled down and converted to the target platform's compressed texture format, but the scale will be 1.0 by default. Atlased textures are those where leaf, fronds, and branch cap textures are cobbled together in a single texture. Users can scale each element in an atlas independently to get the best use of the resource and minimize waste. It is not uncommon for “cap” textures in our model library to be 512×512, which is a monumental waste of texture atlas space, so can should be taken that each atlas member is assign a size that makes sense.
The Compiler also generates billboard atlases, where the billboards are of arbitrary size. It's important that billboards for larger trees are rendered at higher resolutions than others (e.g. a very tall pine that may tower over other shorter trees makes for a very visible billboard as well as a 3D-to-billboard transition). Also, the Compiler allows the billboard textures to merged into the atlas for the 3d tree. Merged main and billboard atlases have the advantage of possibly reducing wasted space as reducing texture bind in your render loop. However, they do result in larger overall textures which can drag down individual texture samples in the shaders.
Each tree in the forest to be compiled has effect LOD settings (i.e. material LOD). These settings are per material (a single tree can have multiple materials per LOD) and can dramatically affect rendering performance. The sliders in the Effect LOD slider (pictured below) are color coded, where red indicates a more expensive effect and green a faster effect. The LODs run from left to right, highest LOD to lowest.
Note that the generated shaders will, for the most part, gradually transition between LOD effects. For example, a per-pixel diffuse lighting effect may gradually transition into a per-vertex lighting effect by flattening the normal map as the camera moves further away. Another example is that the specular component may gradually fade from being per-pixel, to per-vertex, finally to not being part of the lighting equation at all.
The shadow flags in this dialog are largely for use with SpeedTree reference shadow system, but the values generated (e.g. cast, receive) can still be accessed for your own shadow system.
The Wind LOD dialog has one slider that allows the tree model to possibly transition from full wind (think lots of subtle leaf wind effects), to branch wind, to global wind, and finally to no wind. Full wind can be very expensive, sometimes doubling or tripling the vertex shader instruction count, so it should be used judiciously and only for those trees that can benefit from it the most (e.g. hero trees). These transitions are also gradual, so you should never seen popping between LODs due to wind.
Global wind is a very simple effect and is even applied to the billboard geometry to help smooth the transition from a swaying 3D model. Branch wind is a good compromise between full and global wind effects.
Note that in addition to this Wind LOD slider, the Modeler application provides a great number of wind tuning options, all of which affect performance as they carry over into the Compiler application and enable and disable parts of the shader's wind template.
Rolling wind is controlled per compilation session in the Compile settings. If disabled, all trees will compile without this expensive option. If enabled, the trees that have it enabled in the Modeler will use it during compilation.
When “Compile” is selected in the Settings tree on the top left of the Compiler application, a set of options are presented. The Compiler provides brief contextual help. One of the most important options, under Shader Compilation, is “Material Merging.” There are six options that allow users various trade-offs: draw call counts, shader length, and material quality.
|Note: Since both aggressive modes modify material colors, it's possible that you may see slight color changes between LOD states. This is a known side effect of these aggressive modes. To counter it, use fewer unique color sets in the Modeler.|
The Compiler will write an assortment of data to the Output window after compilation. Under Compile Properties / General, there is a Reporting combo box that contains “Concise,”, “Detailed,”, and “Very Detailed” options. For programmers running this app, we recommend using Detailed, as it will list each LOD for each model as well as each draw call for each LOD, including which geometry types are represented in each draw. “Very Detailed” explodes with additional data and it probably only of interest to our own programmers!