Sorry for bringing up a topic that seems to have been covered a billion times, but I still can't seem to bring everything together in my head in a nice, neat, compact design that incorporates everything that I need the management section of my engine to do. Because this is probably the most important part of my engine, as far as the long range problems that can be introduced with a bad design, I am trying to get this right the first time. I recently completed the basic rendering section of my engine, such as initializing DirectX, setting up windows, etc. I decided to move onto scene management, so I decided to take a search around GameDev to see what others had said on the subject. I very quickly ran into the huge scene graph resource thread, and began reading. And after all that reading, I am still very confused about the use of scene graphs and other scene management constructs. I quickly found that scene graphs should really only be used for logical hierarchies, such as a player that has a rocket launcher child node that has a particle emitter child node, and so on and so forth. That part I could understand quite well. Then I got onto the topic of using scene graphs for some of the other necessary engine features, and I soon found many conflicting tales on what should be done. Many posts, especially by Yann L, say that a scene graph should not be used for hidden surface removal, collision detection, state management, etc. Some other spatial structure should be used. But what this other structure is, how it should be managed, and what it can do are never described, or even mentioned. So I sat down and thought about it for a while. I made a list of the things that I wanted the scene manager of my engine to be able to do, and how the user should go about using it. This almost always works for me, and it easily lets me see what I need to do to accomplish the problem. In this case, however, I am still rather befuddled. I need my scene management, to be dead easy for the user (ie. they only have to add their objects once, and don't have to worry about updating them all over the place whenever they change something). It also has to , in some way, deal with culling and hidden surface removal, be able to facilitate physics and collision calculates, and enable efficient rendering through state management. The question remains, how do I do all of that? The solutions that I could come up with were as follows: 1. Have a seperate "tree" structure for all of the different tasks. This had the downside, however, of having to reconcile changes accross multiple trees, which seemed to be a very bad thing to me. 2. Have the scene graph only contain hierarchal relationships, but mark each renderable object, possibly by deriving from a common IRenderable interface. Then, the renderer could crawl through the tree and make a list of all of the renderable objects. This also seemed no good to me, because it would introduce many inefficiencies. For example, when performing frustum culling, would you check every single renderable object against the frustum? It seems that if everything were organized for rendering, such as with an octree or something else, many nodes could be instantly culled away without having to perform any costly tests. And when I was thinking of those, more questions popped into my head. How do I handle static versus dynamic geometry? The only way I could see handling static geometry would be to have a separate static vertex buffer for every static object. Then, when dynamic objects were to be rendered, the renderer would automatically collect and batch them by effect, texture, transform, etc. so that they would be as efficient as possible. How would this be accomplished with a scene graph? If I add an octree node to the scene graph, with all of my static geometry contained within it, how do I handle collisions between dynamic objects and static geometry? As you can see, I am having a hard time making it all fit together in my head. There are too many things that I need it to do, and I can't see a way to make them all work together. If any of you have any insights, tutorials, links, examples, etc, it would be most appreciated. Finally, sorry for the long post, but I hope I have made my problem crystal clear.

The SceneGraph is often a SceneTree to begin with, and it's mean is to have uniform access to all 'nodes' in your scene, by defining a base interface.

The SceneTree (as it should be [ie not graph]) is often used to represent Hierarchical relationship.

A Game Engine most likely needs more than simple a SceneTree, it would also need a SpatialGraph (Graph for Portals/Sectors...), and likely RenderTree too.

Now the real problem is to make everything stick together in a coherent and useful way.

You'll also have a problem with Lights, which cannot be put inside a usual SceneTree Bounding Volume Hierarchy as they would break it, so you'll need another way to find out what lights are visible.

It's usual to combine SpatialGraph & SceneTree, but I wouldn't recommend it, unless you plan it very carefully.

(I know I'm not providing solutions but rather food for thought, sorry about that...)

I've nothing much to add beyond a simple link: Scene Graphs - just say no. Worth reading (as is pretty much everything else Tom Forsyth writes [grin]) if you haven't already...

hth
Jack

Thanks for all the replys guys, ratings ++ for all of you.

I realize that trying to make it perfect the first time will not work, and that continued refactoring is good. What I meant by my original post was that I wanted to avoid my usual quick design process, which is "design the system while I am typing it." This has a few advantages for me, in that things get done quickly, which is necessary because otherwise I get bored, and I end up refactoring things quite often. With the scene management issue, however, I realize that making bad design choices here could box me in later without my realizing, and that it would take more than a little refactoring to make things work out.

I was already leaning towards the multi-view approach before I posted this, and now I am more certain than ever.

While I have this thread out, I am wondering how people deal with dynamic objects in their engine, ostly in the collision and rendering processes. With static geometry, I know that the standard way to handle things is to throw them into an octree and divide as necessary. For dynamic objects, however, that may move between leaves in the octree, problems are introduced. You could always keep a seperate list, but then you must check for collisions with every other object in the list, which could get expensive. I was thinking of maybe having a sort of cube based manager, similar to an octree, but where all the cubes are the same size, and aligned with the axis. They would be laid end to end in all directions. Then, you can easily update the grid of cubes with the new objects that have moved into them over the previous frame. This allows at least a little optimization. I am still curious to here your thoughts.

Finally, I am wondering how geometry is handled that is static most of the time, but could be deformed, maybe by an explosion for example. Can this still be organized into an octree, even though it could possibly change during the course of the game?