Here’s an interesting point of view by Tom Forsyth, a game developper working at Rad Game Tools, entitled “Scene Graphs – just say no”.
“The world is not a big tree – a coffee mug on a desk is not a child of the desk, or a sibling of any other mug, or a child of the house it’s in or the parent of the coffee it contains or anything – it’s just a mug. It sits there, bolted to nothing. (…) Fundamentally of course you do have to resolve a traversal order somehow – the objects need rendering, and there’s some sort of mostly-optimal way to do it. But you’re just never going to get that ordering by just traversing a single tree/graph according to some rules.
(..)
1. Typically, a graphics-card driver will try to take the entire state of the rendering pipeline and optimise it like crazy in a sort of “compilation” step. In the same way that changing a single line of C can produce radically different code, (…)
2. Because of this, the number of state changes you make between rendering calls is not all that relevant any more. (…)
3. On a platform like the PC, you often have no idea what sort of card the user is running on. (…)
This article is an amount of stupidity.
Athor says “as you don’t need scenegraph for z ordering, don’t use it because working is tooo hard and these structures are not generic so it’s bad and blah blah blah”
what he says is true for RENDERING only, but about gameplay it’s entierely wrong, any fast game engine need a division structure to optimize collision, shadow/bone/physic/occlusion culling, characters, ia, pathfinds, etc…
the complain about the uncompatibility between octree / bsp / etc is just silly, generic division structure exists and are called hand-modeled sector / portal.