In Maya, we have joint orientations that rotate joints in their parent space so that when the joint’s “rotation” values are set to 0, the joint is pointed in its reference or bindpose.
But when I import properly-oriented joints from Maya to UE4 in reference pose, the “Local rotation” values for the joints are almost always non-zero. They seem to be relative to their parent bone’s space.
For example, if I have a joint hierarchy Clavicle -> Shoulder -> Elbow, the Clavicle is “pointing” sideways toward the Shoulder, and the “Shoulder” is pointing downwards at the Elbow, in reference pose. This is the pose I should get if all rotations are set to zero.
But in UE4, the Clavicle seems to have non-zero rotation values in rest pose that make it point sideways, and the Shoulder has non-zero rotations that make it point down.
If I want to read or modify the rotation of a joint relative to its reference pose, is the main solution to this to include extra joints that never rotate, so that I can subtract their rotations/locations from the main joint’s current rotations to get a “true” local rotation?
Wow, really? I thought it was fairly common - I haven’t rigged in Max, but for example this video seems to show local rotations are zero at reference pose: https://youtu.be/l2OrSEIhWys?t=60
It’s not so much about transforms directly to joints, it’s about reading and modifying transformations relative to some arbitarily-transformed other joint. That seems pretty inconvenient. Thanks for the info.
Max does things in a very different way from Maya. The values you see as you manipulate things is dependent on what coordinate system you use. What you see in that video you linked to, is that the rotate manipulator is set to “Local” coordinate system. The values always start at 0,0,0 and any new values are added to whatever already exists. You see value changes as you rotate, but then as soon as you let go of the manipulator, the values go back to zero. If you want to see values that are similar to Maya, then you need to set your manipulator to “Parent” coordinate system.
In Unreal, you might also check out Copy Bone and Copy Bone Delta
Old school wise when the rigging part was done as far as the bind pose goes the animator as best practice would zero out the bone rotation so that it matches with the motion capture requirements as well one can always restore the bind pose by setting all of the joints rotations back to zero by making use of any of the animations generated off of the original position. These days the bones don’t need to be zero out as all that is needed is the original rig as constructed in the original pose.
Motion Builder for example to set the rig up to match the animations the requirement to “characterize” the rig is to position the rotations so that the figure is facing in the Z direction in the t-pose position which once the characterize button is pressed the relative rotation is zeroed out. To retarget the animations from a different source one would only need to repeat the same process to the imported animation and in this manner the animations match the characterized rig and not the bind pose.
The bigger problem use to be it was a pain to have to set up the requirements based on a design that had no standards between the two most common bind pose positions of the A-pose versus the T-pose.
So
The retargeting process is not about changing the naming convention being used but rather to process the animation data via a process that matches the requirements of the tool being used.
These days though there is a mix of the old way versus the better way and most pros, as well as AAA studios, make use of tools that manages the animation data as a layer of a much more productive process. Kind of like Web design where one does not need to know HTML code.
As is zeroing out joint rotations has become a victim of obsolescence by design.
