Ok I have read a lot about scene graphs so far and often it is said it is not a good choice for managing a complete scene. So what alternatives do I have?

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.

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.

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...

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?

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.

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.

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?