Pros and Cons of making geometry not only leaf in scene heirarchy

Question

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?

Answer 1

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.

Answer 2

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.