I''ve been working on putting together a simple 3D engine using C# and MDX and I''ve gotten to the point where I need to make some decisions on how I''ll be implementing scene management and rendering functionality. Based on articles/tutorials I''ve read, what other open-source engines have done, and on my own intuition, I plan on implementing the following scheme... There are two graphs that maintain references to a shared pool of world entities. One graph is a typical spatial/containment-based graph, i.e. transformations are local to each node and are "inherited" by its children. The second graph is what I call the render graph, which arranges renderables according to an optimal arrangement of state changes. The render graph would be arranged with the most expensive state changes being at the top of the graph, such that a depth first traversal of the tree would render the scene with the minimal number of the most expensive state change. The actual priority for each state change would be flexible to account for differences in hardware. The game loop would visit each node in the scene graph, calling an update function. Changes to its transformation matrix would be made here and passed on in visiting its children. This is also when the scene node can add a node to the render graph dependent on culling tests (the results of which would be passed on to children to avoid uneccesary testing in children). A node is placed in the render tree according to the render states it employs, utilizing hashcodes to do so quickly (mostly needed for arranging by texture). After the scene graph has been visited, the render graph would be visited to render the scene. Has anyone implemented a scheme similar to this? Or know of an engine that does it this way? Is this technique going to be inefficient and overly complicated? Do capabilities of graphics cards vary enough to warrant flexibility in the ordering of state changes? Comments, warnings, references would be greatly appreciated.

That sounds like a well worked out solution. I particularly like the flexibility in ordering of state changes as this indeed does vary between hardware. You might even be able to get it to dynamically adjust based on cpu/gpu power ratio since a slow cpu will have different bottlenecks than a fast one.