The 6.0 release represents a fairly major jump in performance and functionality, but remains conceptually very similar to the 5.x releases. Some changes will be required to port 5.x source, but no where near the jump that 4.x-to-5.x required. A short 5.2 to 6.0 porting guide has been included in this help system. While not comprehensive, it covers the biggest SDK changes since 5.2.
1. Support for DX11 added.
2. Support for PSVita added.
3. Support for Mac/OSX added (note that the SpeedTree Modeler has also been ported to the Mac).
4. On Windows, support for VC8/Visual Studio 2005 removed. Support for VC9/Visual Studio 2008 and VC10/Visual Studio 2010 remains.
5. Overall rendering speed has improved by ~40% due to a few major changes:
6. The shader system has been completey redesigned:
7. The SDK no longer distinguishes geometry types. That is, there are no longer funcions and structures that have “branch” or “frond” in their names. Each draw call has an associated render state and vertex declaration that might be unique, and that draw call may render one geometry type or four, depending on how successful the Compiler was at merging the geometry. This is largely under artist control.
8. For those projects that use only the Core library to access tree geometry, there is a new set of classes and functions that facilitate easily working through the various vertex declarations (e.g. there are no more SBranchGeometry-type structures).
9. Tree, grass, and billboard instances can now be arbitrarily oriented (as opposed to rotated around the up axis only, as was the restriction in 5.x). Each instance now requires up and right vectors to describe orientation.
10. 5.x added arbitrary 3d leaf meshes (as opposed to always forcing the use of camera-facing leaf quads). 6.0 adds arbitrary camera-facing geometry, of which camera-facing quads is a subset.
11. Vertex sizes have dropped dramatically on average and are no longer constant. LOD and optional shader effects determine the vertex declaration per draw call. Half-floats also supported on most platforms, further reducing all vertex sizes.
12.SPEEDTREE_HEAP_FRIENDLY_MODE has been removed. The SDK now uses a series of heap reserves to prevent render-time allocations. It will adjust if a limit is exceeded by growing the resource on the fly and issuing a warning to the client app about which limit was exceeded and its new value. This allows developers to tune limit values per-level/world to keep allocations to a minimum and ouside of the render loop. 13. File system interface added, such that as file assets are accessed, the client application can have a callback invoked that returns a memory block associated with the given filename.
14. Grass system completely overhauled:
15. Wind algorithm largely redone, now allows different levels of detail as well as smooth LOD transitions. Note that it scales very high, so use all effects with caution.
16. Dynamic tree culling and population system internals have changed considerably to improve speed, but the principle is the same. See the culling/population section for details. The CVisibleInstances class now houses most of the population/culling functions. Tree instances are now streamed from the application to the SDK as the viewport moves, as opposed to 5.x where the entire population was fed into the SDK during init.
17. Added a shallow integration with Intel's GPA profiling tool. The profiling class, CScopeTrace will provide rudimentary timing data without GPA enabled, but will not have the same accuracy or resolution.
18. Branch seam blending mode available during shader compilation.
19. Graphics caps class added, relevant mostly for the Windows and Mac libraries.
20. SPEEDTREE_WORLD_TRANSLATE mode from 5.x is now always on in 6.0.
21. Shader uniform constants are addressed very differently, no longer requiring that they are queried by name from the source. Each constant is defined in ShaderConstants.h in the RenderInterface library, which contains platform-specific definitions which hold constant locations, sizes, and update frequencies.
22. A new instancing manager class handles all of the instanced rendering of trees, billboards, and grass models. Platforms that do not support instancing still use this class and provide an non-instanced implementation in the policy class.
23. Bone data from the Modeler application can be optional written into the SRT files. Vertex data will have bone IDs when this option is used.
24. The SDK namespace now contains a version number. Previous version used simple “namespace SpeedTree”, but 6.0 will be “namepace SpeedTree60”.
1. All of the reference application's source files are prefixed as “My*.cpp/h” to indicate that there are merely example implementations of application-side functionality and are not part of the SpeedTree SDK.
2. A new reference application launching application houses a source editor for a new mini-language called SFC (SpeedTree Forest Config), used to define entire forests that are fed into the application. Changing parameters in the example SFCs that come in our installer is a good way to learn about the flexibility of the SDK.
3. Unlike 5.x, the example shadow system is housed in the reference application source code and are not part of the SDK (although the generated shaders will contain some example shadow code).
4. The sky and terrain systems:
1. The PSVita release is in beta. Performance has not yet been optimized and our example shadow system has not been ported. Our development team is working with the Sony Vita team on suitable optimizations.
2. The Mac release is in beta, and not yet running optimally:
3. On the Xbox 360, there is a problem with getting the depth pre-pass shaders to match the depth of the lit shaders in some situations. The problem manifests itself as white geometry bleeding through the lit rendering of a tree, but only when the depth pre-pass is enabled.
4. There is a “shimmer defeat” option for the function CForest::ComputeLightView(), defined in Forest.cpp. Its purpose is to keep shadow map flickering to a minimum using a technique outlined in Wolfgang Engel's ShaderX7, but in our current implementation, the shadow map will sometimes distort from certain light positions. The shimmer defeat options is hard-coded off within the function.