Alternatives to a scene graph?

Started by
7 comments, last by EWClay 11 years, 3 months ago

Hello,

I'm looking into a way of managing my objects (right now only meshes but + whatever else comes up later) and the only solution I've come up with is sort-of a scenegraph management; where I have one SceneManager, which has SceneGraphs which has SceneNodes and further subnodes, and then I render one scenegraph which renders all nodes and subnodes etc...

Is there any alternatives to this and if so, the pros and cons? Also anything I should think about if scene graph is the right choice?

Thanks

Advertisement

A Scene Graph is just a structure to hold data about your scene in which transformations are passed down.

You don't actually need a Scene Graph to render a scene, you can just run a list for instance, but I do recommend using Graph, it lets you do some nifty tricks =).

Why are you unsure about the scene graph, is pretty much your best bet for scene management.

You have specific requirements that are "conflicting" with your scene graph implementation (or scene graph in general), maybe you should point them out so we can help you in more detailed way.

Check out my new blog: Morphexe

You don’t need an alternative to scene graphs for rendering, you need to understand what a scene graph is and does.

It is a hierarchical structure of objects that allows parent objects’ transforms to be passed down to their children. It is nothing more and nothing less. Transforms may be related to graphics and physics, but a scene graph is not directly related to either.

It should be implemented within your CActor or CEntity class and be entirely hidden from the scene manager.

The scene manager is free to keep multiple representations of the objects it is managing. The main one will be a simple array of objects. You may also choose to maintain an octree.

When the scene manager is time to be logically updated it runs over the array of objects and tells each one to “un-dirty” itself. This simply means that the object should update its matrices if its position/scale/rotation has changed since the last time it was told to un-dirty itself. At this time it can also trickle down its matrices to its children so that they can update their own matrices appropriately. This is the only thing a scene graph does.

When an object finalizes its transform it can also update itself within an octree if you are using one.

Then it comes time to render the scene graph. Once again you have options. If you wanted to keep things simple for the sake of learning, you could just run over the array of objects and draw them (though you should still perform view culling, at least after your first implementation is working).

Or if you used an octree you could traverse that for more optimal rendering.

In either case, notice how the scene graph was not related to rendering at all, nor does the scene manager even know what it is. It handled internally by the entities themselves. It is never correct to use a scene graph for rendering.

Do not look at existing scene-graph libraries such as OpenSceneGraph for inspiration as to what a scene graph is and does. OpenSceneGraph specifically is the single worst example of the functionality of a scene graph there is. It is one of the largest violations of the single responsibility principle out there. A scene graph has no relationship to graphics or physics. It serves only one purpose: Update objects so that their parents’ transforms affect their own. Once that is done the scene graph leaves the picture. Should those transforms later be used by graphics or not is of no concern to the scene graph.

L. Spiro

I restore Nintendo 64 video-game OST’s into HD! https://www.youtube.com/channel/UCCtX_wedtZ5BoyQBXEhnVZw/playlists?view=1&sort=lad&flow=grid

The way I envisioned it for rendering was to simply expose a method in the scenegraph like Draw() which would take a render device reference which would be passed down to all nodes and subnodes and they would use it to render themselves.

On octrees, I've found some guides on google, but is there any specific that is good for reference?
Like L.Spiro wrote, the scenegraph should only be used as a transformation hierarchy. The general consensus these days also seems to be that a Draw() method does not belong in the entities themselves, rather the entities should provide all information that is needed to draw them to the render system.

This reduces the scenegraph basically to:

class Node {
    Matrix transform;
    Node parent;
}

Ok, just one more thing, how would you tie the Nodes transforms in the Scenegraph to the actual mesh when you render it?

You just reference it from the mesh:

(This is all just pseudocode, not actual c++)

class SceneNode { Matrix transform; SceneNode parent; }; class MeshDrawable { SceneNode transform; MeshData mesh; //The actual mesh data }

Sorry, one more question - I've looked abit at how Ogre 3d does it, and they seem to attach Entities to the actual SceneNodes rather than the other way around (which from what I understand Lspiro and madhed is suggesting). What's the reasoning behind this?

Ogre3D probably never considered any other method. It's easier to manipulate the tree that way. Of course, that isn't what you need a scene graph for in a game (an editor may be different). There's no reason for the renderer to be based on the transformation hierarchy, and a flat list will probably run faster. As for managing objects, that has nothing to do with transformations or rendering. An entity system is ideal for this.

This topic is closed to new replies.

Advertisement