Jump to content
  • Advertisement
Sign in to follow this  
jpmcmu

Unity Combining Scenegraph Hierarchy with Physics

This topic is 3286 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 don't see a nice clean method for integrating the scenegraph transformation hierarchy with the physics engine. I found a previous discussion( http://www.gamedev.net/community/forums/topic.asp?topic_id=479621 ) on this. However, in my opinion the problem wasn't resolved with a nice clean solution. This must be a fairly common problem so I would just like to brainstorm and see what solutions have been used to overcome this problem. The Problem: Lets say we have a scenegraph that represents a spaceship. The spaceship has multiple components. Lets assume the scenegraph looks something like this: Root | + World Transformation-- Spaceship's location and orientation in the world. | + Space Ships Hull Graphic Representation | + Left Turret Transformation | | | + Left Turret Graphic Representation | + Right Turrent Transformation | | | + Right Turrent Graphic Representation | + Engine Transformation | + Engine Graphic Representation Lets say I want the turret to recoil when it fires a projectile and I want the physics engine to calculate this for me. This is a pretty easy thing to calculate but how do we hook up the physics engine in a way so that it effectively uses the scenegraph transformation hierarchy of the spaceship? I think the best answer is that the physics representation of the ship has to mirror that of the scenegraph. So how would you go about ensuring that these are effectively mirrored? The physics engine should be able to control any number of mirrored representations. For instance what if you want to create an audiograph that mimicks the scenegraph? This would have to be controlled as well. The only solution that I see to this problem is to have each game entity store a "transformation skeleton" then the graphic representation makes a copy of this skeleton sticks the materials/textures/meshes etc into the leafs that it wants and then sticks this into the scenegraph. This skeleton would be automatically linked to the "controlling skeleton" that the physics engine owns and updates. I am sure someone reading the above "solution" sees some blaring problem that I don't see, I definitely would like to hear it. I would also really like to hear any other possible solutions.

Share this post


Link to post
Share on other sites
Advertisement
Not that I completely agree with TomF, but his article "Scene Graphs - Just Say No" does have an underlying point. There's not really a need to "mirror" your scene graph in your physics system. Your physics system needs to contain data pertaining only to the details of your objects that relate to physics, and contain it in such a way that is optimized to performing calculations quickly rather than being an accurate representation of a visual hierarchy. In my opinion, the short answer to this question is that you don't integrate your scene graph transformation hierarchy into your physics engine, you use two completely separate structures. Hopefully that helps a bit.

Share this post


Link to post
Share on other sites
dudeman21, thanks for your response.

I guess I didn't explain the problem well. I am not trying to use the scenegraph hierarchy as the physics structure, I want to keep the nice scenegraph I am using and allow physics to control it.

For example how do you control the components of the space ship? If you use a normal setup each physically modeled part has to be ripped out of the scenegraph tree and placed into the root of the scenegraph. IE. you have this nice scenegraph with two turrets a hull and an engine all in the root node as completely seperate objects. So if you have to do this for every dynamic object in a game you get this array of objects to render instead of a tree.

So the question is how can you allow the physics engine to control the scenegraph representation without having to break it?

Share this post


Link to post
Share on other sites
You don't - you ignore the scene graph entirely for anything that needs to be affected by physics. In other words, all physically-simulated objects must be top-level scene graph nodes, and you connect them together via joints/constraints in the physics engine.

Share this post


Link to post
Share on other sites
Quote:
Original post by swiftcoder
You don't - you ignore the scene graph entirely for anything that needs to be affected by physics. In other words, all physically-simulated objects must be top-level scene graph nodes, and you connect them together via joints/constraints in the physics engine.


The physics engine most likely works with transformations, bounding volumes, and mesh geometry. It is possible to do so using the objects in a scene graph and without breaking the hierarchy; i.e., you do not have to make the physics objects top-level. I do this using my scene graph management system.

Regarding "Scene Graphs - Just Say No". To quote one of the designers of Java3D (during a casual conversation at dinner about graphics stuff): "A scene graph is just a <bloody> data structure." Well, he did not use <bloody>, but I cannot repeat what he did say :) Like any data structure, you can design it well or you can design it poorly. If something does not work out for you, is it because it was a bad idea? Or is it because it was a bad implementation of a good idea?

Knowing which physics engine you want to use, it is quite possible to design your scene graph data structures to support both graphics and physics.

Share this post


Link to post
Share on other sites
If most of your objects' motion are going to be governed by the result of your solver, then there is no need for an hierarchy. Apart from skeleton or keyframe animation the constrains and joints can clearly dictate other motion for your objects. My implementation never used a scene graph in the first place, but I feel the scene graph can be used just to store the data (objects, materials, etc.) which need not be always spatial.

Share this post


Link to post
Share on other sites
Quote:
Original post by Dave Eberly
The physics engine most likely works with transformations, bounding volumes, and mesh geometry. It is possible to do so using the objects in a scene graph and without breaking the hierarchy; i.e., you do not have to make the physics objects top-level. I do this using my scene graph management system.
Sure, you can do this, and it works just fine. However, I don't see that it actually gains you anything.

Scene graphs typically are used to solve three separate issues: a) as a transform and animate inherently hierarchical data, b) as a BVH to accelerate culling, and c) as a generic way to provide an update() function.

Obviously, (c) is trivial to implement without a scene graph. Equally, with regards to (b), there are several data structures (such as kd-trees, or bounding interval hierarchies) which can provide equal or better culling performance (or you can use a BVH without an explicit scenegraph). And lastly, (a) is now handled by physics for the top-level nodes, so we don't really need it duplicated in the scene graph.

Share this post


Link to post
Share on other sites
Here's a suggestion: take a page from 2D scenegraphs, that is, the CSS positioning model.

In the CSS positioning model, objects may be positioned either relative from where they would have been in the document, or in absolute coordinates, relative only to the screen (they may also be fixed, so that they stay in the same place in the user's view even once the user has scrolled). Extending this to 3D, nodes may be positioned and rotated relative to their parent transformation node, or have their positions set absolutely, relative only to the identity matrix, not the parent transform matrix (to take it further, a "fixed" node appears as a camera HUD element).

Keep in mind that you need not follow the logic of CSS positioning (such as relatively positioned elements putting their absolutely positioned children relative to their own top left corners), simply the principle (child nodes need not be defined in terms of their parents' coordinate spaces).

All of this might seem heretical to the traditional structure of scenegraphs, since it suggests a break in the "spatial" structuring. However, if your scenegraph already handles non-spacial properties such as textures and materials, it is easy to think of the "positioning" flag as simply another attribute that a node switches on when rendering itself and its children.

Share this post


Link to post
Share on other sites
Thanks for all the responses.

Swiftcoder:

I know that you can just rip apart objects into their components and then stick the components in the root of the scenegraph. However, I think this is a very poor solution.

I think it is worth trying to find a way to keep the scenegraph structure for dynamic objects. Not only because scenegraphs are meant for dynamic objects, but because there are many other systems that could benefit from it, for instance skeletal animation.

Obhi:

Your right a scenegraph does not have to be used for dynamic objects. These can simply be connected by joints in the physics engine. But what is a joint? Its a transformation with constraints and limited degrees of freedom. From my viewpoint the transformations in the scenegraph are joints. All the physics engine has to do to treat these as joints is apply conditions to them. I am building my own physics engine so I can easily integrate this idea.

Dave:

Thanks for your response. I am very interested in your implementation. Is this available in one of your books?

Share this post


Link to post
Share on other sites
Quote:
Original post by swiftcoder
Sure, you can do this, and it works just fine. However, I don't see that it actually gains you anything.


I think you meant "I don't see that it actually gains *me* anything". My experience is contrary to yours.

Quote:

Scene graphs typically are used to solve three separate issues: a) as a transform and animate inherently hierarchical data, b) as a BVH to accelerate culling, and c) as a generic way to provide an update() function.


Additional uses: Sharing of objects and resources (geometry, render state, and so on). Interior nodes provide scope (for lighting, for what I call "global effects"). Simplified searching for objects by name. Streaming (both to/from disk and for network transfer). Intermediate data structure that can be passed to a scene graph compiler for optimization on a per-platform basis.

If you have a large collection of objects, you have to manage them in some way. That management typically is a mixture of graph data structures, spatial data structures, bounding hierarchies, and so on.

Quote:

Obviously, (c) is trivial to implement without a scene graph.


Mathematicians get hammered for using "obviously", because when it is said, it usually is *not* obvious. For articulated characters, vehicles, and anything spatial related in a hierarchical manner, (c) is not a trivial step.

Quote:

Equally, with regards to (b), there are several data structures (such as kd-trees, or bounding interval hierarchies) which can provide equal or better culling performance (or you can use a BVH without an explicit scenegraph).


Of course. As mentioned above, you can mix and match lots of systems depending on your requirements.

Quote:

And lastly, (a) is now handled by physics for the top-level nodes, so we don't really need it duplicated in the scene graph.


(a) is handled by the scene graph management system, so we don't need the physics system to duplicate it :)

Your last claim would have been insufficient for the last game I worked on (physics-heavy truck racing with articulated vehicles). All of the vehicle parts were modeled from real data, both graphically and physically. Our physics engine had to deal with such vehicles (each vehicle a scene graph). Breaking them into top-level objects was simply not a reasonable choice.

You said "in the scene graph". A common misconception about scene graph management is that there is only *one* scene graph. It's a fricking data structure. You can have as many instances as necessary. Have a lot of articulated vehicles driving around on a terrain? Have a scene graph for each vehicle. No need to make the "terrain" the parent (that does not make sense anyway).

A graph is a graph is a graph... Just because someone added the modifier "scene" does not mean you don't have graph relationships among your data.


Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!