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.

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.

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?

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.

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.

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.

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?