Controlled joint: roll always relative to parent?

Scripting Issues
1

I have a joint that I am manipulating via “controlJoint”. I want to place restrictions on how far it may turn relative to the model’s base NodePath, and to that end want to find its current angle relative to the base NodePath. My problem is that the relevant angle seems to always be reported relative to the parent joint, even when another angle does vary dependant on what NodePath I provide to the relevant method (I think that I’ve tried both the HPR methods and “getQuat”).

The joint in question is the last of a contiguous series of four such joints, and all of which are oriented more-or-less vertically in the world – they control the back, neck and head of a character’s skeleton.

As a result of this last (I take it), where I would normally expect to turn the head by altering the joint’s “heading” angle, I find that it instead responds to the “roll” angle (I imagine that it considers the line of the bone to be its “forward”, thus making a turn of the head a “roll” around the axis).

Unfortunately, as I mentioned above, I find that when I attempt to examine the roll of the joint I always get a value that appears to be relative to its parent, no matter whether or not I provide a NodePath to “getR” or “getQuat”, while the results reported for the heading of the joint do seem to change dependant on what NodePath is passed in.

Does anyone know why this is, and what I might do about it?

2

np.getR(otherNP) only works when there is a meaningful relation between the two nodes, ie. when they are in the same scene graph.

I don’t know how to resolve your specific problem, though. Maybe you can wrtReparentTo them to each other explicitly?

3

… Would that work with controlled joints? I’ll give it a shot I think, thank you. :slight_smile:

4

A quick update: In the course of fixing a rather larger issue that I discovered I ended up fixing the issue in another way: instead of setting my joint angles relative to the joints, I keep a set of variables holding the relevant angles, update those (including some checks to prevent their values from going out of the desired range), and then simply apply those to the joints. In my particular case this obviates the problem of getting those relative angles, since it allows me to simply check those numeric variables rather than attempting to get relative angles out of the NodePaths.

Nevertheless, knowing that reparenting of controlled joints might work may yet prove very useful for other joint-related features, so thank you again for mentioning it. :slight_smile: