teleport constraints

[pico]

Hi,

to teleport a body we use remove/add rigid body which works nicely.
However, when constraints are attached to the body they of course don't know about this teleport and snap back with lotsa momentum when the body is added again.

Is there any easy solution how to handle such a situation without also removing all constraints and adding them again?

thanks

[robtherich]

Hello. i was dealing with the same problem.
i've found that by executing the following code in my physics_tick routine *twice*, fixes my problems, with no need to remove constraints.
this is pretty much taken directly from DemoApplication::clientResetScene, except, as i mentioned, i perform it for two steps.
if i only perform this code for one step, my ragdolls spin out of control.
mOffsets contains each bodies btTransform.

Code: Select all

for(int i=0; i<mBodyCount; i++)
{
	mBodies[i]->setWorldTransform(mOffsets[i]);				
	mBodies[i]->setInterpolationWorldTransform(mOffsets[i]);
	mBodies[i]->activate();
	mWorld->getBroadphase()->getOverlappingPairCache()->cleanProxyFromPairs(mBodies[i]->getBroadphaseHandle(),mWorld->getDispatcher());
	mBodies[i]->setLinearVelocity(btVector3(0,0,0));
	mBodies[i]->setAngularVelocity(btVector3(0,0,0));
}

i tried several different combinations of things before arriving at this solution.
hope it helps.
-rob

[pico]

hi rob,

thanks a lot for pointing on this!

[sparkprime]

Just to clarify, the bodies in question are the ones being teleported that are linked by constraints, e.g., the bodyparts of a ragdoll?

Setting the world transform is the actual teleport part. Presumably the next line is only important if you are actually intending to render a few more frames before the next actual internal step, otherwise predictUnconstraintMotion will override it immediately anyway. This only prevents rendering errors, then. I'm not even sure how severe they would be -- wouldn't the object simply persist at its old location until the next internal step?

Calling activate() takes all the teleported objects out of any sleep state they may be in, otherwise if you teleport them into the air, they won't fall.

I'm not sure if the broadphase proxy stuff is needed since not performing that step will only cause additional pairs which will later be rejected during the narrowphase, right? Maybe just as an efficiency thing it's a good idea.

I assume setting the linear and angular velocities is presumably just part of the teleportation effect you want to achieve. I think it would be OK to transform the velocities according to the rotation part of the teleportation transformation? It should even be ok to add more velocity to "throw" bodies out of the teleport.

I have no idea why you needed to run it twice!

Possibly they are in the wrong order or the steps need to be refactored. I'm not sure which of those calls are independent and which are not.