The SpeedTree SDK is the run-time component of a powerful real-time vegetation system. It is written in C++ and designed to be integrated into a real-time engine on multiple platforms.

Project artists use the standalone SpeedTree Modeler and Compiler applications to design & edit vegetation content, exporting their results to the SRT (SpeedTree Run-Time) file format. At its most basic level, the SpeedTree SDK can be used to read these files and render them efficiently at run-time, or just provide vertex buffer data for your own rendering engine. At its highest level, the SpeedTree SDK can be used to manage the rendering of forests composed of millions of trees, complex wind effects, level-of-detail, advanced lighting & shadows, terrain and grass. Because the SDK is broken up into several libraries, you are in control of the level of integration, using as much or as little as you need.

This compartmentalization of the SDK has sprung out of feedback from hundreds of development teams around the world, each with a unique need and perspective for the how the SDK can help them.

1. Export meshes from the SpeedTree Modeler or Compiler, bypassing the SDK entirely.

• Pros: It's the easiest level of integration, very quick and supremely simple. This is the first choice of those with a strong NIH bent.

• Cons: It bypasses the run-time LOD scheme, wind, 360-degree billboard matching scheme, forest management, culling engine, ambient occlusion hints, and optimized rendering code. Clients that opt for this often struggle to keep consistency between how trees render in the Modeler versus their engine (that is, the Modeler cannot perform as a WYSIWYG editor wrt/ the final in-engine rendering).

2. Read the geometry using the Core Library.

• Pros: By using this approach, the client application will have access to all of the data generated by the SpeedTree modeler, including LOD data, wind values, bone data, and ambient occlusion hints. It will help generate a rendering that more closely matches what's previewed in the Modeler.

• Cons: It bypasses the 360-degree billboard matching scheme, forest management, culling engine, automatic LOD computations, and optimized rendering code.

3. Use the Forest Library to manage at a forest level.

• Pros: The Forest library provides extremely efficient culling algorithms and can handle forests of 10M trees or more. It also provides all of the data necessary for rendering the trees in full 3D LOD all the way down to a single billboard (which are batched together with billboards of the same type). The Forest library also has a serviceable terrain engine that may be useful for rapid prototyping.

• Cons: While a great deal is handled by this library, it is missing the actual render calls which are key for getting efficient vertex shader-based wind, correct lighting, smooth 3D LOD transitions, and seamless 3D-to-360-degree-billboard transitions.

4. Use the Render Interface & Platform Specific Renderer libraries to render the entire forest.

• Pros: Uses the full SpeedTree capability, including portability to a number of platforms.

• Cons: While it is understandable that a full integration can be uncomfortable for some developers, we advise at least starting with this level of integration to get a system up and running quickly. There is no doubt that clients will want to remove some graphical features and add others. These types of tweaks are facilitated by having access to the full source code for the entire SDK.