SpatialGraph, SceneTree, RenderQueue – sound familiar?
January 5th, 2009Development, OGRE 7 CommentsI was quite gratified to read this post on Wolfgang Engel’s blog, in which he refers to some other posts discussing the recommended categorisation & nomenclature for the various stages / structures of scene rendering. If you read it and you’re an OGRE user, you’ll find them all rather familiar concepts, because OGRE has been based around these principles for years 
“SpatialGraph: used for finding out what is visible and should be drawn. Should make culling fast”
That’s our SceneManager and it’s subclasses. One of the core tenets of my design for OGRE from day 1 was that the mechanism for performing fast culling should be customisable based on the scene type independent of the scene content, and therefore be able to be divorced from, but derived from, the primary scene structure (the SceneTree, see below). While other engines either tended to hardcode their culling strategy, or retrofit it into the ‘main’ scene graph as custom node types (which tends to encourage the ‘parallel inheritance hierarchy’ anti-pattern, because you mostly specialise nodes for other reasons too, and also makes macro-level decisions difficult), specialised SceneManagers build separate and derived culling structures which are entirely theirs to own.
“SceneTree: used for hierarchical animations, e.g. skeletal animation or a sword held in a character’s hand”
That’s easy – that’s our Node and all it’s subclasses like Bone and SceneNode. It’s rare for an engine not to have this concept, but too many engines make these nodes do too much IMO – like holding material state, being derived for custom culling routines, etc. I’ve always liked the idea of keeping the focus of a class tight (the principle of cohesion), it tends to work better long-term.
“RenderQueue: is filled by the SpatialGraph. Renders visible stuff fast. It sorts sub arrays per key, each key holding data such as depth, shaderID etc.”
Yep, we have exactly this structure and unsurprisingly it’s called RenderQueue We have the concept of queue groups for user-customisable ‘fire breaks’ between rendered objects, and the ability to sort by pass, by distance, or via a custom RenderQueueInvocationSequence.
It’s nice to read posts like this – makes me think we’ve been doing things the right way
January 5th, 2009 at 10:46 am
Indeed, OGRE is very nicely designed. Thanks for such a great engine, Steve.
January 5th, 2009 at 11:57 am
Nice to continue to learn the underlying design of OGRE even though I have been using it for around 2 years. I based a lot of my current design on Ogre’s. Thanks!
January 5th, 2009 at 12:12 pm
Early last year when I discovered his blog I wondered about this post:
http://diaryofagraphicsprogrammer.blogspot.com/2007/12/porting-open-source-engine-to-iphone.html
Somehow seems he tested a completely different Ogre. One C++ file per Material? oO
January 5th, 2009 at 12:28 pm
@haffax: heh, I never saw this before. And yeah, I’m not sure what engine he looked at, but it doesn’t sound at all like Ogre
One material per C++ file? An inheritance chain from a base class? Wha? We have neither of those things.
January 5th, 2009 at 1:52 pm
Wolfgang has OGRE on his screen for quite a while, but the last time I spoke with him (That’s years ago I must admit), he was very happy about the design, but didn’t recommend to use it due to speed reasons.
January 5th, 2009 at 2:34 pm
Hmm, and he’s a Rockstar developer? Those guys are supposed to be the bees knees – well at least I have plenty first hand experiance to say I think their game engines are superb.
But he then goes on to say he rates the Nebula Engine highly – erk, I hope that was a joke…
January 5th, 2009 at 7:27 pm
I’ll admit I think the name “RenderQueue” is confusing, because the class actually manages a bunch of RenderGroups. For the longest time I was looking for some kind of RenderGroupManager. I think semantically some of Ogre’s classes could be renamed for clarity.
I can’t really comment on the design since I haven’t used other engines, but it sounds logical.