Hi all, I'm diving into the world of scene management, and a paragraph from the book 'Ultimate 3D Game Engine Design & Architecture' has got me confused. Here's the offender, talking about a geometry node:

Quote: This [geometry] node references a dynamic model of type DynamicModel. Inside the process function of this class, the dynamic model's transformation is applied before the model is drawn. The reason dynamic models have their own transformation is because it is an easy way to apply a dynamic model's physics calculated information in it. If not, the transformation node that parents the GeometryNode would have to be altered for every physics-based object.

Whilst traversing the scene graph tree, the Process() function is called on every node. If this happens to be a TransformationNode, the transformation is applied to the renderer, and then any child GeometryNodes get rendered. If the physics system changed a DynamicModel's position/orientation, its node and in turn any children would not be aware and would remain where they were. If I attached a Player geometry node to a Vehicle geometry node, I would expect the character to follow inside the vehicle, which would be transformed using physics. Also, I plan to have my Octree system make use of the scene graph, and any physics-moved models would be incorrectly placed in the octree. So, surely a better way is to have the physics system alter these transformation nodes instead (the DynamicModel contains a member pointer to the node it belongs to)? Am I missing something?

A while ago I decide to also take a look at scene management, and also ran into the same problem when I wanted to add physics to my engine.
After some thinking I decided to get completely rid of the scenegraph concept.
My most basic object is called SceneObject, and it has virtual functions to access it's position/orientation.
SceneObjects also have RenderData available to them, including bounding parameters.
My SceneObjects know absolutely nothing about parent nodes or child nodes.
If I want such a relationship I use Contraint controller objects, which define how moving/rotating SceneObjects have influence on other SceneObjects.
For example, a RigidContraint simply takes SceneObject A's position/orientation and moves object B's position/orientation relative to it, whereas a SpringConstriant takes physical attributes like mass/velocity/string stiffness etc. to calculate object B's position/orientation.
These Constraint objects are grouped/ordered/updated in a Constraints Tree.

For other scene management functions (like Octree), I create a new tree, and use SceneObject bounds.
Same goes for AI (new game logic tree with scripts, for example npc owns object b).

I'm pretty sure I've overlooked plenty things,but so far I like this approach way better.

There's a point I hadn't even realised - if Player was a child of Vehicle, it would need translating using force/torque and not with standard matrix stuff. well that just makes the whole damn thing even more complicated!

I suppose joints are the way to go then. Shame, I've got several books that explain scene graphs and I had a lot of beneficial uses in mind for it.

Has anyone else overcome the scene graph + physics battle?

It's probably a better approach to have a CEntity class, which has a member for physics and a member which is a scene node. This way you can let the logic functions of the entity handle whether and where/how to display the scene node by setting a few options or its location which can then be retrieved by the physics object.

Quote:Original post by stupid_programmer

Quote:Original post by PinguinDude
It's probably a better approach to have a CEntity class, which has a member for physics and a member which is a scene node. This way you can let the logic functions of the entity handle whether and where/how to display the scene node by setting a few options or its location which can then be retrieved by the physics object.

This is how I'm doing it. I'm using Bullet for physics, and after it does its thing every tick each physics object has a world transform. When I render my objects I use that transform.

Now that you mention it, Newton has an OnTransform callback for every body, which passes the final matrix after each tick, I could alter the scene nodes this way.

I'm not 100% convinced scene graphs are just for rendering though. I had a few ideas about what I'd use one for before I started reading up, and everything seemed to fit into place on paper until I started introducing physics. I'll see how it goes, if anything I'll learn something.