Markus SceneGraph vs SceneTree

One argument for a SceneGraph in general is that people have their custom SceneGraphs implementation already and need to keep them for legacy reasons and this SceneGraph is the reason why the CPU is the bottleneck during the rendering phase. The goal of my talks is to show ways to enhance a legacy SceneGraph in a way that the GPU can get the bottleneck. One very interesting experiment would be adding the techniques to OpenSceneGraph…



Besides this a SceneGraph is way more powerful with regards to data manipulation, data access and reuse. I.e. the diamond shape can be really powerful if you want to instantiate complex objects with multiple nodes. Another powerful feature in our SceneGraph is the properties feature which will be used for animation in the future (search for LinkManager).  With the LinkManager you can create a network of connected properties and let data flow along the links in a defined order. What’s missing for the animations are Curve objects which can be used as input for animations. All those features have a certain cost on the per object level with regards to memory size and more memory means more touched cachelines during traversal which means more CPU clocks spend on traversal.



The SceneTree is designed to keep only the hierarchy and the few attributes which have to be propagated along the hierarchy. This way the nodes are very lightweight and thus traversal is, if required, very efficient. This also means that a lot of features provided in the SceneGraph are no longer available in the SceneTree. Though with the knowledge gained by the SceneTree it should be possible to write a SceneGraph which provides most of the performance features of the SceneTree.



Depending on the type of application you’re writing you might even decide that the SceneTree is too big and you could write your application directly on an interface like RiX which doesn’t have the hierarchy anymore and thus eliminating yet another layer ;-).