#####################################
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 HOOPS Luminate 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
======================================

HOOPS Luminate uses a "heavyweight" scene graph. Each shape has a number of attributes (see :doc:`/book/subjects/bk_sgo/bk_sg_shape_attributes`), 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. HOOPS Luminate 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 in the doc :doc:`/book/subjects/bk_re/bk_re_rendering_2d_datasets` under the **2D Data Organization for an Efficient Rendering** section. 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 HOOPS Luminate, context callbacks can help in reducing the overall rendering workload. The :doc:`/tutorials/workflows/wf_realtime/wf_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 HOOPS Luminate to reduce the rendering workload for a frame.


Using Bounding Spheres
======================

This is basic but still effective. As detailed in the doc :doc:`/book/subjects/bk_sgo/bk_sg_shape_attributes` under the **Bounding Spheres** section, 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.
