Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I was wondering why most game and graphics engines prefer to make geometry/mesh class only as a leaf in the scene hierarchy; more precisely they are not allowed to have children. So what are the pros. and cons of making it able to have children from performance and software design point of view?

share|improve this question
    
can you give examples of engines with this feature? –  momboco Mar 11 '11 at 22:13
    
well ya .. Cinema4D permits geometry to have children,, unity3D permits game object which include a geometry to have children, but thats only what happens in the front end, I don't what is the real implementation. OpenSceneGraph doesn't allow geometry to have children (so if you want a geometry to have child you need to make an extra transform node maybe thats what happens in unity3D for example but in the background .. am not sure about this ) –  concept3d Mar 11 '11 at 22:18
add comment

2 Answers

up vote 4 down vote accepted

I quote the Ogre justification, from the book "Pro Ogre 3D Programming"

The decision to decouple the scene graph from the scene contents was probably one of the most brilliant, yet underappreciated, design features in the entire Ogre project. This is such a simple design to understand, yet one of the hardest to comprehend for those used to more “traditional” scene graph designs. Traditional designs (as used in many commercial and open source 3D engines) typically couple the scene contents and the scene graph in an inheritance hierarchy that forces the subclassing of content classes as types of scene nodes. This turns out to be an incredibly poor design decision in the long run, as it makes it virtually impossible to change graph algorithms later, without forcing a lot of code changes at the leaf-node level if the base node interfaces change at all (and they usually do). Furthermore, this “all nodes derive from a common node type” design is, in the long run, inherently inflexible and nonextensible (at least from a main- tenance standpoint): functionality invariably is forced up the inheritance hierarchy to the root nodes, and myriad subclasses are required, and typically end up as minor adjustments to base functionality. This is, at the very least, a poor object-oriented design practice, and those who adopt this design philosophy almost always end up wishing they had done it a different way in the beginning. Ogre did. First of all, Ogre operates on its scene graph(s) at an interface level; Ogre makes no assumption as to what sort of graph algorithm is implemented. Instead, Ogre operates on the scene graph only through its signature (its methods, in other words) and is completely igno- rant of the underlying graph algorithm implementation. Second, Ogre’s scene graph interface is concerned only with the graph structure. Nodes do not contain any inherent content access or management functionality.

share|improve this answer
add comment

It really depends the heirarchy is the only structure you're using. I often use a tree-like structure for logical seperation of scene elements but I use other structures, such as BSP trees, quad trees and the like to store instance batches. That's the important bit for performance: How quickly can you determine which batches of instances to render together. If you've got some logical heirachy someplace else it won't have any impact on performance (other than extra memory use) but it's important to have quick access to potentially visible sets of data in a form that is graphics card and cache friendly.

share|improve this answer
    
just thinking if you can mix between BSP tree and scene hierarchy for example a typical Node ,can be extended to be a BSP tree node, and have a modified way of tree traversal. to clarify what I mean a Node will traverse the scene in a specific way, a BSP node will traverse its children based on separating plane so its kinda mixing two types of trees , is that good from a scene graph design and performance point of view ? –  concept3d Mar 11 '11 at 23:02
    
I'm not entirely sure that it is - it may work for your game though. The way I go about these things these days is to keep the two seperate. This allows me to have a logical grouping editing and an accelerated visibility structure for rendering quickly. That's what works for me right now although this may change if my requirements change. There is no one-size fits all solution, you have to be pragmatic and go with whatever is optimal (or convenient) for the sort of game you are writing right now. –  Luther Mar 11 '11 at 23:11
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.