Sign in to follow this  

Scenegraph Questions

This topic is 4839 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm at the point in my engine design to start considering the best way for me to implement a flexible scenegraph structure. I have read all of Yann's archived posts regarding this and have a few additional questions (I didnt want to resurrect a thread that has been dead that long :D). 1. From what I understand in your logical scenegraph representation you are considering the scene from a non-spacial view and trying to seperate it out from any spacial relationships, however how does that affect the way in which the nodes in the scenegraph are related? For example, when a man holding a torch moves his torch moves with him, but how do you express where he is holding the torch? Surely this is a spacial relationship, but how do you set/get the position/orientation of an object in your game world without exposing the position and orientation in the common interface? 2. Some objects in the scene graph might be able to be grouped, for example all the dynamic objects can be dropped into an octree for visiblity determination. How do you manage which objects are grouped into which system? Is this done on a per type basis, or on a per instance basis? 3. In regards to physics do you use the HSR method to reduce collision requests? When executing a ray query exactly how do you walk the tree? It seems to me that you will need to walk the entire tree for each collision request (i'm probably missing something pretty fundamental here). 4. Say that a dynamic objects leaves the terrain and enters the village, does the village then become responsible for that object? Would it be wise to use portals to check when an object leaves one area and enters another? To me it seems that you would need to do a lot of tree cascading in order to render and update your scene graph! Could someone help me get my head around this a little more? thanks ;D

Share this post


Link to post
Share on other sites
Quote:
Original post by jonnii
I'm at the point in my engine design to start considering the best way for me to implement a flexible scenegraph structure.

I have read all of Yann's archived posts regarding this and have a few additional questions (I didnt want to resurrect a thread that has been dead that long :D).

1. From what I understand in your logical scenegraph representation you are considering the scene from a non-spacial view and trying to seperate it out from any spacial relationships, however how does that affect the way in which the nodes in the scenegraph are related? For example, when a man holding a torch moves his torch moves with him, but how do you express where he is holding the torch? Surely this is a spacial relationship, but how do you set/get the position/orientation of an object in your game world without exposing the position and orientation in the common interface?

2. Some objects in the scene graph might be able to be grouped, for example all the dynamic objects can be dropped into an octree for visiblity determination. How do you manage which objects are grouped into which system? Is this done on a per type basis, or on a per instance basis?

3. In regards to physics do you use the HSR method to reduce collision requests? When executing a ray query exactly how do you walk the tree? It seems to me that you will need to walk the entire tree for each collision request (i'm probably missing something pretty fundamental here).

4. Say that a dynamic objects leaves the terrain and enters the village, does the village then become responsible for that object? Would it be wise to use portals to check when an object leaves one area and enters another?

To me it seems that you would need to do a lot of tree cascading in order to render and update your scene graph! Could someone help me get my head around this a little more?

thanks ;D

OK, I'm going to do this quick, because I'm running out of notebook battery power.

1. The relations are logical, yet the scenegraph contains a minimum of spatial information. This is needed for animation, physical simulation, as well as for AI. It's stored in the relative matrices from the parent to the child object. When adding a node to the graph, it may have one (or several) attach points. Those are simply 3D position vectors. They are part of the model only, the relationship itself is encoded within the translation part of the local SG matrices.

2. Irrelevant for the SG. The SG doesn't know about frame visibility of dynamic objects, nor about which lowlevel structure you might use for it. It's just a tree containing logical relationships. When adding an instance to the SG, you'll be implicitely calling a method to make the instance visible to the render system (since it is independent of the SG). This call can do anything from simply adding the instance to a linked list, up to complex visibility tree insertion. But all that doesn't really concern the SG (with the exception of a visibility feedback from the lowlevel VSD system, which can be used to avoid costly physical simulation on SG nodes that are currently invisible - a performance optimization).

3. Collision queries use a separate tree structure, which is especially well optimized for fast collision queries. The physics engine operates on the SG, and queries the individual instances for collision. How that query is resolved doesn't concern the SG. Different object types might even use different algorithms or structures. Use the right tool for the job: a structure for rendering, a structure for collision, and a structure for high level organisation. Often, the visibility and collision structures can be combined into one. But it ultimately depends on the intrinsics of your engine.

4. Neither the terrain nor the village are dynamic objects, so they aren't directly part of the SG. But of course it can be useful to take VSD systems such as portals into account - but only for visibility determination. Portals don't really affect the logical relationship between objects, so they shouldn't affect the SG either other than through the feedback I mentioned above. This will implicitely provide the lazy SG traversal you're looking for - whatever VSD system you might be using at a lower level. It's an abstraction, the SG doesn't need to care about lowlevel implementation details.

Quote:

To me it seems that you would need to do a lot of tree cascading in order to render and update your scene graph!

You don't render the scenegraph, that's the job of the spatial VSD structure (which is highly optimized for the job). You'll rarely traverse the entire SG, only the branches that are currently active - in the sense of a dynamic activity: animation, physical simulation, AI, etc...

Share this post


Link to post
Share on other sites
Quote:
Original post by jonnii
1. From what I understand in your logical scenegraph representation you are considering the scene from a non-spacial view and trying to seperate it out from any spacial relationships, however how does that affect the way in which the nodes in the scenegraph are related? For example, when a man holding a torch moves his torch moves with him, but how do you express where he is holding the torch? Surely this is a spacial relationship, but how do you set/get the position/orientation of an object in your game world without exposing the position and orientation in the common interface?


first of all its not spacial its spatial [smile]. Traditional scene graphs are typically a manifestation of the composite design pattern, for scene graph there are three elements involved node, groups, and leafs under a uniform interface (thats what the composite pattern lets you do). Node is the common interface, groups are your composites where you add children of type node and group is a node, leafs are well leafs and are also sub-types of node.

Group types are one of the keys here, you sub-type particular groups such as "transform group" that maintains a transform (that either is or contains a 4-by-4 matrix, or an orientation quaternion & vector position) that would apply to all the transform group's children and there children etc etc, this is state inheritance.

Anyways back to the question about arm & torch its hierarchical relationship, arm would probably be a parent of torch. Torch would be effected by one of the transform groups that belonged to the body of that arms so as soon as the body moves so does the torch.

Quote:
Original post by jonnii
2. Some objects in the scene graph might be able to be grouped, for example all the dynamic objects can be dropped into an octree for visiblity determination. How do you manage which objects are grouped into which system? Is this done on a per type basis, or on a per instance basis?


I think the above may have answered that already. If not let us know.

Share this post


Link to post
Share on other sites
Quote:
Original post by Yann L
You don't render the scenegraph, that's the job of the spatial VSD structure (which is highly optimized for the job). You'll rarely traverse the entire SG, only the branches that are currently active - in the sense of a dynamic activity: animation, physical simulation, AI, etc...


this makes sense but doesn't the renderer need to iterate the scene graph to accumlate transformations so would that mean particular leaf nodes would reference the geomotery that is contained in a spatial data structure?

[Edited by - snk_kid on September 13, 2004 1:38:46 AM]

Share this post


Link to post
Share on other sites
Another thing that i would like to know is whats the best way to integrate physics sub-system into scene graph, say a rigid body type for its position & orientation would it reference the the accumulated/local transform of a leaf node of interest? or would it be like a controller type that is attached to a transform group and manipulates the transform over a period of time?

Share this post


Link to post
Share on other sites

This topic is 4839 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

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