In this presentation SceneGraph and SceneTree are presented.
ST (SceneTree) is essentially an unfolded synchronized copy of SG (SceneGraph).
Since you are going to need ST anyway because:
it offers instance, where you need to save attributes
you need to traverse ST anyway for updating transformation and other cascading variables, such as visibility
even if SG offers less redundancy, what is the point to have SG in the first place?
To quote Markus Tavenrath, the guy who gave that presentation, who was asked the same question: http://pastebin.com/SRpnbBEj (as a result of a discussion on IRC (starts ~9:30))
[my emphasis]
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 ;-).
So first reason is that people are already used to using a scenegraph and many custom implementations exist.
Other than that the scenetree is really a pruned scenegraph where only the necessary components which means that a scenegraph is more useful to the artists and modelers as it better abstracts the scene. A complex property may for example be a RNG seed that affect the look of each person in a crowd.
In a scenegraph that root Person node would just have a single property seed. Its children would select the exact mesh and color based on that seed. But in the expanded tree the unused meshes for alternate hairstyles, clothing and such will already have been pruned.
