Sign in to follow this  

Scene graphs verses physics, some confusion

This topic is 3290 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

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?

Share this post


Link to post
Share on other sites
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.








Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.


Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by deadstar
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.

It's your choice really. Scene graphs were originally for just that, the 'scene', but people start extending things to suit their own applications. The graph structure is arbitrary, and you can introduce whichever nodes you want to make your life easier. But as soon as you start introducing nodes that exist to aid your rendering, you're introducing nodes that get in the way of your physics, or your AI, or whatever. The real world is not arranged in a simple hierarchy. If I'm in a vehicle, I travel at the vehicle's speed, and can therefore trivially be transformed relative to the vehicle, but if I lean out of the vehicle, I still travel at that same speed, but I'm also affected by the physics outside of the vehicle. And if I fire a projectile from the roof of a moving train, it starts off moving relative to the train but eventually it'll be moving relative to the earth... etc. It starts getting messy because the hierarchy you're using to help your rendering only loosely resembles the way the actual world works. Personally I think the scene graph just gets in the way for everything but rendering.

Share this post


Link to post
Share on other sites

This topic is 3290 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