Defining the scene graph architecture

Each application has different constraints in terms of data architecture. We can't review all possible architectures here, so we'll just focus on a few quick guidelines that can help using REDsdk in a more efficient way.

Software rendering ignores the scene graph

Software rendering uses an acceleration structure. This acceleration structure has its own partition of space. The architecture of a scene graph has no influence at all on the contents of the acceleration structure. So the entire discussion below is only valid for hardware rendering needs.

Each shape has a cost in a scene graph

REDsdk uses a "heavyweight" scene graph. Each shape has a number of attributes (see Attributes of a shape), among which we see the parent / children relationship, bounding spheres, layersets, materials, etc...

Therefore, parsing a scene graph AND considering all these attributes has a cost. REDsdk needs to parse the scene graph and to maintain it each frame, taking into consideration all changes that have occurred.

Therefore, scene graphs with more than 100.000 shapes can take a few milliseconds to parse and this can result in a slowdown of the rendering.

As a consequence, it may be worth using groups of primitives for a single shape, if these primitives only have a few elements in them each. This is also discussed here: 2D data organization for an efficient rendering. A well balanced scene graph can be key to good performances.

Using early culling strategies

Whenever possible, use early culling to reject part of the assembly from any further processing. In REDsdk, context callbacks can help in reducing the overall rendering workload. The Using culling callbacks for visibility control tutorial illustrates - on a very simple model - the differences that exist between the context callback and the visibility callback.

Any shape or shape tree that is discarded by the context switch callback will be removed from the entire display. This is the earliest culling entry point that can be used in REDsdk to reduce the rendering workload for a frame.

Using bounding spheres

This is basic but still effective. As detailed here: Bounding spheres, using bounding spheres can speed-up the display, assuming there's enough data to cull in each shape or shape tree that can be discarded, if invisible.

Note that bounding spheres can be only defined at some important level in the scene graph. This may help avoiding wasting time checking bounding spheres of leaves of the tree if some parent node is visible. Therefore, an application may wish to only setup bounding spheres at some levels in its scene graph hierarchy.