Physics and joints: two problems

I’m currently experimenting with programmatic manipulation of an Actor’s skeleton. My current approach is an attempt at having physics objects, using Bullet, move the various joints, and I’ve hit two issues:

  1. Parenting a NodePath produced by a call to “controlJoint” to a physics object doesn’t seem to result in the relevant bone moving or rotating. Other NodePaths, such as a loaded model, do seem to follow the movements and rotations of the physics object, but joints seem to ignore it entirely. It looks as though I can apply the changes myself by manually setting the joint’s H, P and R values, but that seems clunky to me.

  2. I seem to be struggling to place the physics object in alignment with the relevant joint. I believe that I’ve tried setting the position and H, P and R of the NodePath containing the physics object to values returned by the appropriate “get” methods of the NodePath produced by the call to “controlJoint” as mentioned above, both relative to render and to the Actor, but while they do seem to move the physics object they don’t seem to move it to the desired position. Since the physics object is intended to control the joint, I don’t want to parent it to that joint.

Does anyone have any suggestions?

(1) This is true. The controlJoint mechanism works by copying the local transform on the node into the joint transform each frame. It does not compute the node’s net transform, so it cares nothing for whatever the node is parented it. It simply copies the transform on the node itself. You can work around this by copying the intended transform in a frame using a task, for instance, as you suggest; and yes, this is clumsy. You also might be able to get away with using a CompassEffect to do the same thing automatically, but all this does is hide the clumsiness from you. Ultimately, the non-clumsy way to do this would be to integrate more directly with the joint system, for instance with an AnimChannelMatrixDynamic, or some other AnimChannelMatrix class of your own design, that receives the desired transform directly. Of course there will always be a copy-into-the-joint-hierarchy step at some level.

(2) You do have to be careful that you are assigning the proper transform. It’s important to keep in mind that the joint transform expects to receive the relative transform from the joint’s parent. If you wish to use Panda’s relative scene graph operations to compute the appropriate relative transform, it means you have to be careful which node you assign the controlJoint node to (it has to be a node that represents the joint’s parent). If you are not using Panda’s scene graph operations, it doesn’t matter which node your controlJoint node is parented to, because you’ll be setting only the local transform directly–but it does mean you’re responsible for getting that transform right.


  1. Hmm… Fair enough. I’ll probably do it by hand – I don’t have too many such joints at the moment, thankfully, and am likely to be copying only the rotation values.

  2. Ah, I see.

In both it seems that I was thinking about it in somewhat the wrong way, having forgotten the caveat of the strictness of joints expecting their transforms relative to those of their parent joints.

I think that I see a way forward now.

Thank you very much for your reply. :slight_smile: