SDK Organization

This section describes the overall organization of the SpeedTree SDK and assumes no prior knowledge of SpeedTree. It is recommended that you read the How to Use This SDK section to gain an understanding of the purpose of the SDK as well as the level of application integration that will best suit your needs.

There are four libraries in the SDK, each representing a different level of integration (the cyan boxes below):

• Core: Reads the SRT file format, providing coordinates, texcoords, tangents, billboard data, LOD data, materials & texture filenames, and collision objects. Also provides run-time wind management, coordinate system conversions, an allocator interface, error reporting, and licensing. Core is a portable class, compilable with most C++ compilers.

• Forest: Dependent on Core, the Forest library handles management of dynamic forests containing potentially millions of trees. It houses highly optimized culling & LOD systems in addition to dynamic grass and terrain systems great for rapid prototyping. It also provides systems to manage forest-level wind. Like Core, Forest is portable with no graphics-API dependencies.

• Render Interface: Dependent on Forest, the Render Interface library makes abstract graphics calls to efficiently render the forest, complete with shader loads, state changes, efficient vertex buffer rendering, shadows, lighting, and more. The Render Interface makes calls to empty graphics wrappers, making it portable.

• Rendering Classes: Dependent on Render Interface, the rendering classes contain platform-specific graphics implementations, filling out the graphics interfaces defined by the Render Interface library. Filling out the abstract interface is all that is required to adopt a new graphics API. Interface classes include classes that manage texture, shaders, shader constants, vertex/index buffer objects, and render state changes.

The SDK ships with a demonstration application called the Reference Application. More on the Reference Application, but it's a complete standalone program that shows how a deep integration might be handled, though every user's integration will vary according to their goals and requirements.

At its most basic level, the SpeedTree SDK is organized like any other SDK or middleware offering. You'll need to be able to include the SDK header files, link to its libraries and, in the case of DLLs, make sure that the correct DLL(s) are in your binary path or copied next to your application's executable. Static libraries are also included.

In a default installation (notated here as “[SDK]/”), the key SDK files needed for an integration are located as noted below:

• Include Files: Modify your include path to contain [SDK]/Include/.

• Library Files: Modify your library path to contain [SDK]/Lib/[PLATFORM]. [PLATFORM] may be anything from Windows/VS2012.x64/ to Orbis/ or 360/.

• Binary Files: To harness the SpeedTree binaries (unless you're using the static libraries), under Windows you should either add [SDK]/Bin/[PLATFORM] to your path variable or copy the needed DLLs into the same folder as your application's executable. Which DLLs you'll need depends on your level of integration.

Each LIB and DLL file is named descriptively to avoid mixing up the wrong versions. The naming structure is as follows:

SpeedTree<lib base name>_<version>_<build type>_<runtime library>[_Static][_d]

This results in names such as “SpeedTreeCore_Windows_v7.0_VS2012_MT64_Static”, or “SpeedTreeCore_PS3_v7.0_Static_d.a”, etc. There are quite a few libraries and DLLs to chose from in the SDK, but hopefully this naming policy will prevent headaches in finding the correct version for your needs.

The SpeedTree SDK includes versioning hints to help runtime configuration and usage. The ST_VERSION_STRING macro contains a string version number (e.g. “7.0.0”), and ST_VERSION_MAJOR, ST_VERSION_MINOR, and ST_VERSION_SUBMINOR contain the numerical values 7, 0, and 0 respectively. These macros can be checked at any point to determine the version of the SpeedTree SDK being used.

To avoid mismatches between header files and libraries, the static CCore::Version() function can be used. CCore::Version() returns a long descriptive string about the build type, platform, and version used when building the library. Or, passing true in the bShort parameter to CCore::Version() returns a string that can be directly compared to the ST_VERSION_STRING define to determine if the header and library match.

All of the source code contained in the SDK libraries is housed in the SpeedTree namespace. Use this namespace to resolve any conflicts between SDK types and your own.