Ein guter Scenegraph dient ihn erster Linie nur zur Verwaltung von Objekten. Es werden Hierarchien aufgestellt, die in vor allem die natürlichen Verhältnisse wiederspiegeln, das heißt, ein Apfel liegt auf einem Teller, welcher sich auf einem Tisch befindet.
Diese Hierarchie ist für die meisten Vorgänge, außer dem Transformieren aber total ungeeignet.
Idealerweise ist es also so, dass es für jeden Fall einen extra Baum gibt, zum Beispiel ein Octree, der die Szene in Gebiete unterteilt, perfekt geeignet zum Cullen und für Kollisionstest, ein Rendergraph, in welchem die Objekte nach Materialien oder Transparenz sortiert sind.
In der Realität ist sowas kaum zu verwirklichen und man verwendet den Scenegraph auch oft zum Cullen oder zum Collisionstest. Dazu verwendet man die eh schon programmierten Node-Klassen, zum Einbau von Quadtrees (Terrain), Octrees (Indoor-Level) oder ähnliche Konstrukte, die dann direkt dem Terrain hinzugefügt werden.
Ein Node im Scenegraph sollte immer nur die Referenz auf das Interface einer Ressource haben, so dass man bei Plattformunabhängigen Engines den Scenegraph universell verwenden kann.
Zum Rendern könnte z.B. ein DXRenderTraverser den Scenegraph durchlaufen, alle Objekte Sortieren und anschließend Rendern. Es gibt hier aber mehrere Konzepte. Zwei gute Tutorials finden sich hier:
(1)
http://www.sir-kimmi.de/tuts/graphics/whats_a_scenegraph.txt
(2)
http://www.sir-kimmi.de/tuts/graphics/re…_scenegraph.txt