Scene graph contains game nodes representing game objects. At a first glance, it might seem practical to use Scene Graph as physical container for in game objects, instead of std::vector<> for example.
My question is, is it practical to use Scene Graph to contain the game objects, or should it be used only to define scene objects/nodes linkages, while keepig the objects stored in separate container, such as std::vector<>?
Answer
Deciding on what type of scene management to use depends very heavily on what type of logic you are trying to run. Consider the different consumers of your scene:
Rendering Consumer
The renderer probably just wants to know what is currently visible to the user at any given point. It wants a bounding volume hierarchy for fast culling (BVH wiki article) so that it can figure out that a chair inside a boat doesn't need to be drawn because the boat's bounds are outside the view frustum. This might be embedded into an octree.
It also might want to have an idea that the chair is on its back inside the boat, and that the boat is rolling up and down on some waves when it finally comes into view. That way to find the final world coordinates of the chair's vertices it can concatenate the chair and boat transforms and be done with it (this also makes your job as a programmer easier).
Yet another way of looking at this problem is that the renderer is probably running a good card, and ultimately just wants a pile of triangles sorted so as to minimize texture, shader, material, lighting, and transform state changes. This last will probably help you more than a BVH, preformance-wise.
Game Logic Consumer
The game logic probably just wants a flat list of things that can talk to each other by a messaging system, so a std::vector is probably fine.
The game might also want a way of keeping track of who is closest to what, so some sort of [nearest-neighbor][3] information might be helpful in that case. This can be provided by a BVH also, but having to up and down the graph might be annoying.
The game might even just want to know that when it moves A, A's item B should move too... in which case we are back to a sort of transform hierarchy.
Physics Consumer
Your game physics might want to have a [special representation][4] of indoor spaces for very fast collision detection. Alternately it might use some sort of octree or [spatial hashing][5] to efficiently find things that might collide.
None of the above physics data structure really looks like a "scene graph" in the Java3D sense.
Audio Consumer
An audio engine just wants geometry, perhaps a potentially visible (audible) set, or some sort of bounding volume hierarchy to calculate sound attenuation and propogation. Again, not really a normal sort of scene graph, though it may well be a graph of geometry in your scene.
Ultimately... ...it really just depends on the exact needs of your application. I'd suggest using a flat list to start with, and seeing where your issues arise. You might even try a flat list with a transform hierarchy, because that is perhaps the one sort of scenegraph useful for reasons other than efficiency.
Good luck!
No comments:
Post a Comment