As an author of a scene graph based game engine, I think I might have something to say on the subject…
What most people seem to be saying here and everywhere else is that trying to make all your systems fit into the scene graph paradigm is a bad solution.
So instead you use several data structures to handle various tasks. If you wish to use a spatial partitioning scheme, for example, the engine shouldn’t enforce you to use the scene graph structure to do so.
The way jMonkeyEngine is designed, is somewhat similar to this idea. You have a scene graph, and it is used mostly for just rendering and arranging scene elements into groups by their spatial location. In other words you can create a house node and place props inside the house node by attaching them to it. The transform of the house will be propagated to the underlying nodes and so the props in the house will have their location relative to the house’s origin.
All the props in the house and the house itself have their own “appearance”, this “appearance” is only set on the leaf level, so it doesn’t propagate like the transforms do. Any state change optimizations will occur later (explained below).
When the scene graph is rendered, the culling is done by going down the graph, if a branch is deemed not visible, then all its child nodes will not be visible either. The entire tree is then flattened into several buckets. The opaque bucket is the most commonly used one, and is sorted by material ID, to reduce state changes for shaders and textures.
If you wish to add a spatial partitioning scheme on top of this scene graph, you can make an octree work quite easily with it. If you want to add skeletal animation with a bone hierarchy in the scene graph, you can do that as well. Detecting broadphase collisions for physics will also work. The GUI framework can also take advantage of the tree structure with its containers and panels.
Yet none of those are done like this in jME.
A scene graph node has many properties, but none of the mentioned algorithms really need these properties, so instead we have more efficient trees to work with these features.
Physics broadphase collisions are handled with a DBVT structure in JBullet. Skeletal animation uses a bone tree that is better suited for bone-weight animation and generating appropriate matrices for transforms. An octree uses a very lightweight node structure that doesn’t even need storing transform or bound information since those can be derived just by going down the tree. And Nifty GUI (the GUI library used by jME) also has its own tree with appropriate properties that are used for GUI like alignment, width and height, and so on that are more efficient for such uses.
Hopefully this will shed some light on how a real scene graph engine functions…
