0
$\begingroup$

I have created an ostrich and this is the armature. The feather bones, 5 left, 5 right and one centre are controlled by an IK bone. Bone naming is done view from the back of the ostrich, so left and right are correct. The whole armature is controlled by the MAIN bone. Every feather bone has a copy rotation constraint for the ‘X’ axis. The 5 left ones have a copy rotation constraint for the ‘Z’ axis with and influence of: 0.2, 0.4, …, 1.0. The 5 right ones are like the left one with the ‘Z’ axis inverted.

Picture 1 : The feather bones, 5 left, 5 right and one centre are controlled by an IK bone. Bone naming is done view from the back of the ostrich, so left and right are correct. The whole armature is controlled by the MAIN bone. Every feather bone has a copy rotation constraint for the ‘X’ axis. The 5 left ones have a copy rotation constraint for the ‘Z’ axis with and influence of: 0.2, 0.4, …, 1.0. The 5 right ones are like the left one plus the ‘Z’ axis inverted.

Picture 2: the IK ‘Z’ axis is rotated clockwise and the feather bones tilt correctly.

Picture 3 & 4: now we rotate the MAIN bone CCW or CW and the left feather bones are still OK. But the right ones are not correct anymore. I have the same issue with the wings. In the case of the wings, it is the right side that does not work. What did I do wrong? How can I correct this? I have the same issue in Blender 2.79 and 2.8. Many thanks for your help. enter image description here

$\endgroup$
0
$\begingroup$

It always works correctly. It does not always work like you'd expect. The differences are basically down to how Euler angles operate, especially in conjunction with constraints.

So when you copy rotation, here's what it does:

  1. It decomposes your target bone's orientation into XYZ Euler triplets. These are not necessarily or even likely to be the same XYZ triplets you keyframed for that bone. That is because Euler angles are aliased: there is more than one set of Euler angles that corresponds to any particular orientation. But in order to accommodate space-switching, we have to get only a single set of numbers out, so there's some information that's lost.

If you want to see what these anti-aliased (not a good thing in this case) numbers are, you can duplicate the control bone, give it a copy transforms constraint targeting the original, and then apply visual transform (or bake animation.) You will see that the transforms you get are probably not the ones you expected.

  1. We multiply the components of that triplet by the influence of the constraint, and then rotate the constrained bone with it. Changing influence does not give you rotation along a plane-- rotation in a single axis. That is, there's torque. That's because Euler angle rotation doesn't interpolate in a straight line.

Those two things combined mean that copy rotation, particularly at influence <1.0, particularly for 2-axis copy rotation, doesn't work like people intuit it ought to. Copy rotation is part of a set (with limit rotation) of the least intuitive constraints, because of how people think about 3D angles working, and the differences between that and how they actually work.

If only the first thing is a problem, you could consider using a driver instead of a constraint. If you don't need space switching, drivers can let you work on raw, no-lost-data f-curve numbers.

However, what I'd generally say is, try to find a different way to do what you want. Copying rotation of 3 axes, at influence 1.0, is perfectly safe. Damped tracking and locked tracking with influence less than 1.0 is safe, and operates in the "swing angle" (smallest rotation) rather than with any torque. One way that should get you what you want is to copy all rotation fully, and then restore a part of it by damped and locked tracking non-deforming marker bones. That may be more complicated than what you actually need though.

$\endgroup$
0
$\begingroup$

Nathan, thanks for your reply. In order to make simpler for investigation I have created two new bones. One bone for controlling the feathers on the right and the centre one. The other for the feathers on the left. The bone on the right is the “master” and the one on the left the “slave”. The “slave” has a copy rotation constraint, one for “X” and “Z” of the “master”. “Y” is not needed in this project. It still did not work as I expected. All this was done in Blender 2.8. After much researches, I decided to open a copy of the blender project with version 2.91. I have noticed that the Copy Rotation Constraint panel has change. When using Local Space for Target and Owner it works like I was expecting it. I have saved the file in 2.91 and reopened it in 2.8 and now it also works in 2.8. It is beyond my skill to now why it works after that. I will do the same for the wings.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.