I am doing extensive tests to isolate the conditions that result in a rig “frame lagging.” My goal is to become a more advanced rigger and to make a tutorial since I couldn’t find an existing thorough guide on the subject. While trying to test how the depsgraph works, I ran across something that looks odd.
I created a chain of 4 bones using 3 extrudes, resulting in a parent structure of:
Bone->Bone.001->Bone.002->Bone.003
I animated the last child bone (Bone.003) to rotate from 0 to 10 degrees and back to 0. I setup the following constraints:
Bone.002 CopyRot Bone.003 (local space)
Bone.001 CopyRot Bone.002 (local space)
Bone CopyRot Bone.001 (local space)
I set this up twice in a new Blend file and tested it in Blender 2.71, 2.69, and 2.66 - all with the same result. I would expect all the bones to have the same local rotation, as if the constraints were inverted. However, it does not. It spins around as though I was using world/pose space with CopyRot. I apologize for not posting a link; I am a new member.
Is this a bug in Blender, or am I missing something?
I have finished my studies of constraint and driver execution order, but I still haven’t found if this is buggy behavior. I would expect the described setup to merely suffer from frame lag, but it’s not.
When you rotate any bone, the children of that bone inherits that rotation. By having the parent copy the child’s rotation, you’re compounding the rotation of the child. It goes kind of like this:
the child rotates, which…
rotates the parent, which…
rotates the child, which…
rotates the parent.
If you follow the chain of logic, it’s easy to see how–after a very short time–the rotation of the child gets way out of hand, especially when you compound the compounding by having the grandparent copy the parent who is copying the child, and the child inherits from both.
So, no. This isn’t a bug. It’s a run-away rotational dependency.
Try it the other way around. Rotate Bone and have Bone.001 copy Bone’s rotation, have Bone.002 copy Bone.001’s rotation, etc. That, I believe, is what you were expecting. No?
That’s the way I would expect it to work in world or pose space, but it works that way even in local space? Driver variables show local space to be independent of parents. Thus, it works when using drivers with local space (granted with frame lag).
Changing from local to global space (or whatever) doesn’t change the fact that you’re compounding the rotation by starting at the child end. It’s the compounding of the rotation that’s the main point here, not which space you’re in.