Jump to content

  • Log In with Google      Sign In   
  • Create Account


Alternatives to a scene graph?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
8 replies to this topic

#1 KaiserJohan   Members   -  Reputation: 1085

Like
0Likes
Like

Posted 21 December 2012 - 05:08 PM

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



Sponsor:

#2 Morphex   Members   -  Reputation: 298

Like
0Likes
Like

Posted 21 December 2012 - 05:24 PM

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 


#3 L. Spiro   Crossbones+   -  Reputation: 12784

Like
3Likes
Like

Posted 21 December 2012 - 06:33 PM

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


It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

#4 KaiserJohan   Members   -  Reputation: 1085

Like
0Likes
Like

Posted 22 December 2012 - 07:45 AM

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, 22 December 2012 - 08:15 AM.


#5 Madhed   Crossbones+   -  Reputation: 2647

Like
0Likes
Like

Posted 22 December 2012 - 08:07 AM

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, 22 December 2012 - 08:07 AM.


#6 KaiserJohan   Members   -  Reputation: 1085

Like
0Likes
Like

Posted 22 December 2012 - 03:52 PM

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



#7 Madhed   Crossbones+   -  Reputation: 2647

Like
-1Likes
Like

Posted 22 December 2012 - 05:48 PM

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
}



#8 KaiserJohan   Members   -  Reputation: 1085

Like
0Likes
Like

Posted 23 December 2012 - 12:03 PM

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?



#9 EWClay   Members   -  Reputation: 659

Like
1Likes
Like

Posted 26 December 2012 - 08:00 AM

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.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS