Sign in to follow this  
madRenEGadE

Scene Management

Recommended Posts

Sneftel    1788
A scene graph is a fairly nice structure for managing a static scene. It's easy to come up with a good hierarchical structure, and then that structure helps you maintain the scene.

It's not so great for games, for a few reasons. First of all, hierarchy isn't always static, consider: you've got a character who jumps onto a skateboard and starts skating around on it. Previously to that, of course, the skateboard and the character were siblings in the hierarchy. Now, one is the parent of the other. Which one? How does the reparenting affect the scene? Is the relative offset from the skateboard to the player an important quantity? And what if the child (taken to be the character) needs to interact with scenery-- how does it interact with objects which are in a different coordinate system than it is?

The more serious reason is bookkeeping. Maintaining a scene graph as a parallel structure to the state of the world involves a lot of bookkeeping. When a new entity is created, you need to remember to add it to the scene graph too. When it's removed, you need to remember to remove it. Whenever it moves, you need to update the scene graph's representation. It's an almost completely redundant data structure which you have to spend time keeping up-to-date.

There are other reasons too, relating to efficiency, rendering order, etc., but to my mind these are the main two.

So what's the alternative? Immediate mode. Suppose my game is a simple driving game, consisting of cars and a track and the occasional flying hubcap. In the retained mode (scene graph) representation, I would keep scene graph nodes for each of the cars and each of the hubcaps, mirroring their game-space representations. Instead, in the immediate mode, during rendering I simply iterate through the list of cars--in the game representation--and draw them. The linkage between game state and rendering is moved from during the update stage to during the render stage; a serious change, but not one with a major impact on encapsulation.

Share this post


Link to post
Share on other sites
smitty1276    560
Quote:
Original post by Sneftel
In the retained mode (scene graph) representation, I would keep scene graph nodes for each of the cars and each of the hubcaps, mirroring their game-space representations. Instead, in the immediate mode, during rendering I simply iterate through the list of cars--in the game representation--and draw them.

It's worth noting that there is a fine line between the two... as a scene graph becomes more "flat" (fewer hierarchical relationships between nodes) it basically degenerates into a list of nodes to render, like the "immediate mode" example Sneftel mentions here.

You can work with a scene graph as part of a rendering engine like Ogre, but choose to only employ hierarchical relationships where appropriate.

Share this post


Link to post
Share on other sites
Gage64    1235
Quote:
Original post by Sneftel
during rendering I simply iterate through the list of cars--in the game representation--and draw them.


That sounds very oversimplified. What about spatial partitioning?

Please note that I'm not trying to be a smart-ass with that question. It's just that the difference between scene graphs and spatial trees is a little unclear to me. Can you give an example of how you would handle the character on a skateboard example without using a scene graph?

Share this post


Link to post
Share on other sites
madRenEGadE    190
ok this sounds like a simple octree or so should also give good results?

The main thing why I don't like a scene graph for a complete scene is that
in reality it does not make sense that a chair is a childobject of a house or so...

Share this post


Link to post
Share on other sites
memento_mori    100
i think i read a post by Yann somewhere on this forum that you should have both a scenegraph and an hierarchical scene representation (octree for example) and neither could replace the other and not we're not supposed to mix those two ... i'll find the link... is that wrong?

Share this post


Link to post
Share on other sites
smitty1276    560
Octrees and that sort of thing are ideally suited to static geometry--things that are relatively fixed in space, like terrain and buildings. Scene graphs are ideally suited for things that move around.

What you will often find is that nodes in scene graphs hold geometry that is static within its own frame of reference, and which can therefore be stored in a hierarchical volume like an octree. For example, a car may move and may have a node in a scenegraph, and it may have child nodes for wheels,etc. But those wheels themselves are "leaf nodes" on the scene graph and can have an associated octree representation that makes it easy to do collisions and that sort of thing.

Terrain in a scene--an arbitrarily large terrain mesh--may have its own node in a scenegraph.

Share this post


Link to post
Share on other sites
Sneftel    1788
Quote:
Original post by Gage64
That sounds very oversimplified. What about spatial partitioning?

Oh, it is very oversimplified. But so is the scene graph version. Scene graphs aren't really any better at doing spatial partition than immediate mode rendering. One can define hierarchies of bounding volumes on the scene graph, of course, but (a) they're a pain in the ass to maintain, and (b) their ad-hoc granularity makes them more or less useless for visibility culling.

As for how to implement it, spatial partitioning can be put on entities along with all the other components. In that situation, rather than iterating over all entities, the renderer would iterate over all potentially visible entities reported by the spatial culling structure. So the BSP (or whatever) itself would be retained to some degree, but would only be updated when and where necessary.

Share this post


Link to post
Share on other sites
Sneftel    1788
Quote:
Original post by madRenEGadE
The main thing why I don't like a scene graph for a complete scene is that
in reality it does not make sense that a chair is a childobject of a house or so...

Really? If you move the house, do you expect the chairs to stay behind, floating in mid-air?

Share this post


Link to post
Share on other sites
madRenEGadE    190
no but that is not the point I mean.

it is the object-oriented point of view from which it does not make sense that a chair is a child of a house.

to understand what I mean: http://home.comcast.net/~tom_forsyth/blog.wiki.html#%5B%5BScene%20Graphs%20-%20just%20say%20no%5D%5D

Share this post


Link to post
Share on other sites
Crazyfool    307
Quote:
Original post by Sneftel
Quote:
Original post by madRenEGadE
The main thing why I don't like a scene graph for a complete scene is that
in reality it does not make sense that a chair is a childobject of a house or so...

Really? If you move the house, do you expect the chairs to stay behind, floating in mid-air?


"Contains ____" isnt "is _____"

Share this post


Link to post
Share on other sites
smitty1276    560
Quote:
Original post by madRenEGadE
it is the object-oriented point of view from which it does not make sense that a chair is a child of a house.


It has little, if anything, to do with an "object-oriented point of view". The relationships are related to things that are integral to the rendering process--things like spatial frames of reference, render states etc... Structuring a scene graph based on object types would be ostensibly useless for this.

A scene graph is just a directed graph. It is a directed graph that is built to logically group geometry in a ways that improve rendering performance or simplify the process. If its purpose is anything else, it would be hard to justify calling it a "scene graph".

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this