Page MenuHome

Problem with the copy constraint for bones
Closed, ArchivedPublic

Description

System Information
Operating system: Windows 7 64-bit SP1

Blender Version
Broken: any 2.80 beta build
Worked: Only in 2.79 (which is obviously the stable version)

Short description of error

It appears that the coding for the copy rotation constraint is not complete. its also missing some useful features for making animations.
The following bug I noticed is the fact that copy rotation constraint (and probably the other copy constraints) don't seem to do their job while the animation is being rendered only if the bone has a child as target instead of a parent. If target is a parent then everything is working fine

Exact steps for others to reproduce the error

  1. create a bone armature, and extrude a number of bones (not too many)
  2. give it a copy rotation constraint (or the other two)
  3. make sure the target is the child bone, and not the parent
  4. make a simple animation test for it by transforming the bone that uses the constraint.

As you can see the constraint seems to be doing its job completely fine on viewport, but when you will render the animation, only the bone with the constraint will rotate, the target will do nothing.

And btw, about the "useful features". If you choose the make a child bone as target in the bone constraint, the behaviour will be different. Instead of the constraint transforming the bone in linear style, it transforms it dynamically. And by that I mean that the bone with the constraint will copy the target's transformation more dynamically.
So, I was thinking if there would be a possibility if there was a option that could change the constraints behaviour to control the bone more smoothly/dynamically.

Details

Type
Bug

Event Timeline

Sebastian Parborg (zeddb) triaged this task as Needs Information from User priority.

Please attach minimal example file.

Anoca (Maker26) added a comment.EditedThu, Jun 13, 9:51 AM

It is recommended to open it with the latest 2.8 build
all you have to do is to render the animation.

Sebastian Parborg (zeddb) claimed this task.

Your setup has three dependency cycles:

Dependency cycle detected:
  OBArmature/Bone/BONE_CONSTRAINTS() depends on
  OBArmature/Bone.001/BONE_DONE() via 'Copy Rotation'
  OBArmature/Bone.001/BONE_READY() via 'Ready -> Done'
  OBArmature/Bone.001/BONE_CONSTRAINTS() via 'Constraints -> Ready'
  OBArmature/Bone.001/BONE_POSE_PARENT() via 'Pose -> Constraints Stack'
  OBArmature/Bone/BONE_DONE() via 'Parent Bone -> Child Bone'
  OBArmature/Bone/BONE_READY() via 'Ready -> Done'
  OBArmature/Bone/BONE_CONSTRAINTS() via 'Constraints -> Ready'
Dependency cycle detected:
  OBArmature/Bone.001/BONE_CONSTRAINTS() depends on
  OBArmature/Bone.002/BONE_DONE() via 'Copy Rotation'
  OBArmature/Bone.002/BONE_READY() via 'Ready -> Done'
  OBArmature/Bone.002/BONE_CONSTRAINTS() via 'Constraints -> Ready'
  OBArmature/Bone.002/BONE_POSE_PARENT() via 'Pose -> Constraints Stack'
  OBArmature/Bone.001/BONE_DONE() via 'Parent Bone -> Child Bone'
  OBArmature/Bone.001/BONE_READY() via 'Ready -> Done'
  OBArmature/Bone.001/BONE_CONSTRAINTS() via 'Constraints -> Ready'
Dependency cycle detected:
  OBArmature/Bone.002/BONE_CONSTRAINTS() depends on
  OBArmature/Bone.003/BONE_DONE() via 'Copy Rotation'
  OBArmature/Bone.003/BONE_READY() via 'Ready -> Done'
  OBArmature/Bone.003/BONE_POSE_PARENT() via 'Pose -> Ready'
  OBArmature/Bone.002/BONE_DONE() via 'Parent Bone -> Child Bone'
  OBArmature/Bone.002/BONE_READY() via 'Ready -> Done'
  OBArmature/Bone.002/BONE_CONSTRAINTS() via 'Constraints -> Ready'
Detected 3 dependency cycles

We do not support dependency cycles in 2.8

is this the reason why this type of animation constraint doesn't render in 2.8? Then how come it renders fine in 2.79?

Yes, that is the reason.

In 2.8 we updated the evaluation system to handle more advanced setups. However, this means that we can't handle cycles like these.

A cycle is when two values depend on each other. So for example say that you have two bones that will add each others X location to the final transform.

If you move Bone 1, then it will move Bone 2. But because Bone 2 moved, Bone 1 will be moved again and thus Bone 2 will be moved and so on.
It will be an endless loop.

Anoca (Maker26) added a comment.EditedThu, Jun 13, 12:07 PM

I see... but will there ever be a possibility to make bones move more dynamically? like a delay where the child bone responds to the parent bone a bit later.
Also, what is the alternative way of making the parent bone follow rotation of the child bone without getting any cycle dependencies?

The might be a solution, but I'm not good enough with rigging to help you, sorry.

A child should never affect its parent, since a parent always affects its child, if a child in turn affected its parent, it would always be an infinite loop of maths.

If you find yourself in a situation where you need behaviour like that, you can add a layer of control above your parent (let's call it master) and have it control your child and parent at the same time.

So in times where originally you would've controlled child, and cause it to control its parent, instead you would control master, which will control both of them, for the same result. Your setup of a chain of bones with Copy Rotation constraints reminds me of a simple rolling finger rig, so here's what that would look like with the solution described above:

If you want, you could even use the custom shape settings to display this master control at the location of your child(Bone Viewport Display->Custom Object->Custom Shape Transform). This would give the appearance of a child affecting its parent, even though that's not what's happening under the hood. This can actually help you make really intuitive controllers in many cases, where the child affecting its parents is intuitive. Totally valid for a finger roll control imo. In fact you just gave me a cool idea for my own rigs. :P

A child should never affect its parent, since a parent always affects its child, if a child in turn affected its parent, it would always be an infinite loop of maths.
If you find yourself in a situation where you need behaviour like that, you can add a layer of control above your parent (let's call it master) and have it control your child and parent at the same time.
So in times where originally you would've controlled child, and cause it to control its parent, instead you would control master, which will control both of them, for the same result. Your setup of a chain of bones with Copy Rotation constraints reminds me of a simple rolling finger rig, so here's what that would look like with the solution described above:


If you want, you could even use the custom shape settings to display this master control at the location of your child(Bone Viewport Display->Custom Object->Custom Shape Transform). This would give the appearance of a child affecting its parent, even though that's not what's happening under the hood. This can actually help you make really intuitive controllers in many cases, where the child affecting its parents is intuitive. Totally valid for a finger roll control imo. In fact you just gave me a cool idea for my own rigs. :P

well, anyone could've thought this simple rig idea, but I was thinking to use this kind of method I found myself on a shoulder from a character rig
when the arm rotates, the shoulder should rotate aswell, giving the character movement more realism, and saving time when animating
and btw, the shoulder bone is the parent of the arm.
We're talking about a smart IK system here to get the character movement in animation more realism without the need of giving too much effort.

I gave it a shot real quick, what I came up with was to derive the "raised-ness" of the arm using a helper bone at the original location of the shoulder, and point it toward the hand, then look at its rotation. Then just use that value to control the clavicle. The helper bone is parented to the spine, so no dependency cycles here.

It's probably not perfect but it's the first thing that came to my mind and seemed easiest to implement.

that attempt is almost perfect.
Maybe I'll figure out some stuff of how to get this one done perfectly.
ok I'll stop sending comments in here.