Body positioning / orientation

dabear

12-03-2007 21:27:24

I have a question that I am unsure how to answer properly yet - any feedback is greatly appreciated.

It seems like OgreOde is written such that all physical objects in Ogre need to be in the global coordinate system. None of the functions in Body seem to translate things to world coordinates and such.

My problem is that I have a group of blocks (derived from OgreOdeBody) that are joined by joints. They work very well if they are in global coordinate system in Ogre (because ODE uses global coordinates). Now the problems happen when I want to encapsulate those blocks into one grouping and provide it with own scene graph for position/orientation of the grouping in the world. Then, OgreOde doesn't work because the position/orientation of each block is now relative to the parent node. How to fix this properly?

Thanks!

Game_Ender

12-03-2007 23:54:12

Its usually an all or nothing afair. You either position scene nodes based on there proxy in the simulation or you position them with a scene node hierarchy. You want to be able to both, why? Moving objects around with Ogre commands will break the simulation.

EDIT: Small update for clarity and typos.

dabear

13-03-2007 00:13:37

Thanks for the reply. Can you explain what you mean by your answer? My question was how can I have a scene node hierarchy (in terms of Ogre) and at the same time use OgreOde (which uses the fact that ode uses flat global coordinate system).

Game_Ender

13-03-2007 01:17:07

Sorry this is what I meant: Why do you want a scene node hierarchy? You should not be moving around scene nodes controlled by ODE. So it doesnt matter how nice it would be to give them all a common parent node or in what frame ODE positions the nodes.

dabear

13-03-2007 03:27:41

Why do you want a scene node hierarchy?

Many reasons for this. Main reason being the ability to encapsulate a group of nodes that depend on each other to form one unit (think of this as a recursive data structure of the nodes). Thus, being able to translate/rotate them as a group instead of writing functions to calculate each node's relative translation and doing it all manually. Say for instance you have a car made up of many nodes or a ragdoll character or a special tree. Wouldn't you want to provide the ability to "move a car" instead of writing a recursive node traversal keeping track of ancestor translations and rotations?

You should not be moving around scene nodes controlled by ODE

And why not? I see nothing wrong with this if the ODE positions/rotations are updated appropriately. I could modify OgreOde to add this functionality - I am just under time constraints and want to treat OgreOde as a library only. If some of the functions like Body::setPosition were virtual, I could overwrite them in my derived classes but the way they are now (and especially since they are being called within OgreOde), it will not work.

Game_Ender

13-03-2007 03:36:44

The way most Ogre and Physics integration systems are done is by handing over management of the Ogre scene nodes for objects which the physics engine simulates. So the best way to move objects around would be through ODE's functions.

This is not a bad thing because ODE already maintains the needed organization you speak of. I believe a car or ragdoll is made up of several ODE bodies jointed together, each of which controls a scene node who's parent is the root node. If you wish to move them as a unit move the central ODE body.

So in a nut shell: You have handed over management of some scene nodes to OgreODE, don't fight, work with it.

dabear

13-03-2007 04:05:11

Can you clarify how I can do this?

I have my structures created as bodies in ODE joined through joints. When I move either one of them using ODE functions, only that node is moved. I'm not sure what you classify as a "central ODE body" but I don't see a way through ODE to organize the ODE bodies such that I can move them all at once.

If you are talking about OgreOde doing the organization, please point me to a sample/reference/tutorial. I've looked in the code and could not find anything that would work.

Game_Ender

13-03-2007 04:53:29

Now I see the problem: "Moving a single ODE body will not move bodies that are joined to it". I think the way to solve this problem would be to create a custom kind of OgreODE bodies that maintains this for you. It would be easier and cleaner than bending Ogre's scene graph to your will.

Here is little code for the a changed setPosition method:

void MyBody::setPosition(const Ogre::Vector3& position)
{
// Call super class postition method to position this node
OgreOde::Body::setPosition(position);

int count = getJointCount();
for (int i = 0; i < count; ++i)
{
Joint* joint = getJoint(i);
Body* childBody = joint->getFirstBody()
if (this == childBody)
childBody = joint->getSecondBody()

// Set Position and orientation of body relative to current body
}
}


You could accomplish this easily through making the setPosition method virtual in OgreODE and recompiling it. Then you could just accomplish this through a custom sub class much like you described above. Or you could at runtime use a dynamic cast to down cast to your custom body from the OgreODE:Body*.