Integrating Scene Graphs and Physics Engines

Question

For some specific reasons, i will have to use a graphic engine based on Scene Graphics with a Physic Engine without this concept. I was thinking about a clear way to integrate both representation but ... i did not found something that convinces me.

The problem that always appears is that the scene graph is a hierarchical structure and the Physical engine is not. The position of a node in a scene graph depends of its parents, and when the parents changes its location, the son must be updated, but the son can be physically simulated (its position is always in global coordinates) ...

(there are lots of others situations similar to this ... - hard to calculate relative positions/orientations and keep both worlds in sync)

The only way i found is to have all the physically simulated objects as direct sons of the root node of the scene graph (no relative positions at all) In the physically simulated nodes, we dont propagate relative positions/orientations, each of this nodes only store world positions/orientations, not relatives. But this constraint sounds a little to much and probably will kill (a bit =P) some of beneficts of scene graph like cullings. (after all, most of my scene wont follow any hierarchy ... )

how people usually solve this kind of situations ?

Answer 1

I have been in the same situation as you and this is how I solved it.

Before that, some clarification:

• In my SceneGraph each SceneNode keeps track of its own local transform (scale, rotation, translation) and a concatenated transform (world).

• SceneNodes can have multiple components.

• BEPUPhysics is the physics library being used, its entity transforms are in world space

Example)

I have a wrapper component, BoundingVolume, for the Physics entities which can be attached to a SceneNode. When the component is initialized it creates the Physics entity and registers it with the Physics System.

The BoundingVolume component can then calculate transforms in two ways in the update loop:

• Update SceneNode transform (default) - The SceneNode's local transform (Physics entity worldtransform - parentNode.worldtransform) is updated to so its world transform match the Physics entity's World transform
• Update Physics entity transform - The Physics entity's transform is modified to match the SceneNode's world transform

Answer 2

You are approaching the problem from the wrong side. You don't have a scene graph and need to integrate physic engine. You are using a rendering library that uses a scene graph and want to also use a physics library that does not use a scene graph.

How about you step one step back and stop thinking about the solution domain (scene graph) and start thinking about the problem domain?

I don't know what you are simulation and want to represent. But if you look at the real world, there are no scene graphs, only objects. These objects may be connected to each other or not, but any form of hierarchy is totally artificially added.

How about you build you high level logic in the form of a system independent way. You have a "cloud" of objects and these objects then use graphic library and physics library, to actually do something useful. These objects will also arbitrate the data movement from one library into the other (physics -> rendering). The mapping does not have to be 1:1 but can be m:n. One high level object may have an entire subtree in the scene graph and multiple bodies and geometries in the physics simulation.

This also works well when adding additional things like a sound library or a networking library.

You probably even don't need any organisational structure (i.e. Octree) for the high level objects, because their interaction and spacial hierarchy are not such a big deal. But you must see for yourself and apply it to your problem.

Answer 3

after all, most of my scene wont follow any hierarchy ...

Since this is the case, I wouldn't keep using a hierarchical scene graph. I'd break down the world using an octree. The benefits of using an octree are that you get your frustum culling and LOD determination without needing to fit every object into a hierarchy. If you want, of course, you can still have object hierarchies like in a traditional scene graph.

On the flipside, octrees are a little more difficult to maintain, especially considering objects whose bounding volumes may lie inside multiple octants, but they integrate much more easily with physics simulations. Just remember to choose an appropriate maximum subdivision level to avoid having a lot of objects in more than one octant.