Sign in to follow this  
KaiserJohan

Alternatives to a scene graph?

Recommended Posts

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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? Edited by KaiserJohan

Share this post


Link to post
Share on other sites
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;
}
Edited by Madhed

Share this post


Link to post
Share on other sites

You just reference it from the mesh:

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

 

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

Share this post


Link to post
Share on other sites
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.

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