Unexpected result of two "Child Of" or "Copy Transform" constraints #29100

Closed
opened 2011-10-30 17:36:47 +01:00 by Anna Celarek · 11 comments

%%%In the file, the small green bone "middle" is constrainted to the small bones "top" and "bottom" with Child Of constraints (right setup), or Copy Transform (left setup, names with .001 suffix). Both constraints have 0.5 influence, so they should add up to influence 1.
"bottom" and "top" are children of the big bone "main" (parenting in edit mode, no constraints).

  1. Child Of:
    When I move or rotate "top" or "bottom", then "middle" always positions itself between the two, as expected.
    But when I move them not directly, but by rotating "main", then "middle" moves more than it should, leaving the expected in-between position.

  2. Copy Transform:
    More or less the same happens as with Child Of.
    If Copy Transform is in Pose or World space, the same as with Child Of happens except the local rotation is not right too. If Copy Transform is in Local with Parent space, it messes up even more by reversing the direction.

Sounds confusing so I attach also a drawing of what I would expect to happen.

Blender svn r41295M
Blender svn r41386M

OpenSuse 11.4, Gnome 2.32.1%%%

%%%In the file, the small green bone "middle" is constrainted to the small bones "top" and "bottom" with Child Of constraints (right setup), or Copy Transform (left setup, names with .001 suffix). Both constraints have 0.5 influence, so they should add up to influence 1. "bottom" and "top" are children of the big bone "main" (parenting in edit mode, no constraints). 1. Child Of: When I move or rotate "top" or "bottom", then "middle" always positions itself between the two, as expected. But when I move them not directly, but by rotating "main", then "middle" moves more than it should, leaving the expected in-between position. 2. Copy Transform: More or less the same happens as with Child Of. If Copy Transform is in Pose or World space, the same as with Child Of happens except the local rotation is not right too. If Copy Transform is in Local with Parent space, it messes up even more by reversing the direction. Sounds confusing so I attach also a drawing of what I would expect to happen. Blender svn r41295M Blender svn r41386M OpenSuse 11.4, Gnome 2.32.1%%%
Author

Changed status to: 'Open'

Changed status to: 'Open'
Member

%%%When blending the influence of constraints, the first one should always be full strength. This is because the constraints are applied in top to bottom fashion, with each one taking the output of the previous one, and blending itself on top of that (in other words, "last one wins").

  1. Copy Transform (Left Armature).
    After fixing the influence, you'll need to tweak the head/tail value of the second constraint (0.5 looks like what you want I think).

  2. Child Of (Right Armature).
    I suspect that it's probably just a combination of double-transforms and non-linear behaviour. Probably there's very little we can do about this.%%%

%%%When blending the influence of constraints, the first one should always be full strength. This is because the constraints are applied in top to bottom fashion, with each one taking the output of the previous one, and blending itself on top of that (in other words, "last one wins"). 2) Copy Transform (Left Armature). After fixing the influence, you'll need to tweak the head/tail value of the second constraint (0.5 looks like what you want I think). 1) Child Of (Right Armature). I suspect that it's probably just a combination of double-transforms and non-linear behaviour. Probably there's very little we can do about this.%%%
Author

%%%2) Copy Transform
Works, thanks!
It becomes complicated when it comes to 3 or more such constraints, but I've noticed that the weight distribution is divided moreless equally if I take half the influence for every next constraint (1, 0.5, 0.25), and so far this seems to work in the big rig too (Transforming 9 insect eyes between 3 control bones)

1.) Child Of:
What I do not understand:
If I put influence 1 to the top, and influence 0.5 to the bottom, then moving the top bone results in a behaviour as if the middle bone was its only child (so the last one doesn't win), while moving the bottom bone results in distributing the weight over both parents (so the last one wins by adding its 50%, as you said).
So are Child Of influences summed up differently than Copy Transform influences?

%%%

%%%2) Copy Transform Works, thanks! It becomes complicated when it comes to 3 or more such constraints, but I've noticed that the weight distribution is divided moreless equally if I take half the influence for every next constraint (1, 0.5, 0.25), and so far this seems to work in the big rig too (Transforming 9 insect eyes between 3 control bones) 1.) Child Of: What I do not understand: If I put influence 1 to the top, and influence 0.5 to the bottom, then moving the top bone results in a behaviour as if the middle bone was its only child (so the last one doesn't win), while moving the bottom bone results in distributing the weight over both parents (so the last one wins by adding its 50%, as you said). So are Child Of influences summed up differently than Copy Transform influences? %%%

%%%There is still some problem with nested childof constraints. I recently added an armature with the "base" bone constrained to another armatures bones via childof. Inside the same armature i used childof for bones deeper down the chain, which reference are the children of the "base" bone. The result is strange, since if only the "base" bone rotates, the childof constraint of the children leads to movement that isn't accurate.

To illustrate this issue, which seams to be related, i appended an simple example file.

The "base"-Bone of the armature is constrained to the empty and has two not connected children. In this case the distance between both bones should be constant if the empty is rotated. However this changes if one of the children is constrained to the other child with childof. In theory the second childof constrained should be useless and have no effect. In Blender it leads to an additional movement, which shouldn't be there. If implemented correctly the tip of the horizontal bone should stay at the tip of the constrained bone.

see attachment: child-of-influence-bug.blend (It is wrong, even if the influence is 0.0 or 1.0)%%%

%%%There is still some problem with nested childof constraints. I recently added an armature with the "base" bone constrained to another armatures bones via childof. Inside the same armature i used childof for bones deeper down the chain, which reference are the children of the "base" bone. The result is strange, since if only the "base" bone rotates, the childof constraint of the children leads to movement that isn't accurate. To illustrate this issue, which seams to be related, i appended an simple example file. The "base"-Bone of the armature is constrained to the empty and has two not connected children. In this case the distance between both bones should be constant if the empty is rotated. However this changes if one of the children is constrained to the other child with childof. In theory the second childof constrained should be useless and have no effect. In Blender it leads to an additional movement, which shouldn't be there. If implemented correctly the tip of the horizontal bone should stay at the tip of the constrained bone. see attachment: child-of-influence-bug.blend (It is wrong, even if the influence is 0.0 or 1.0)%%%

%%%PS: The file includes a short animation of the empty. If you rotate it around the z-axis manually you should see that the constrained bone (Bone.003) is rotated twice. It inherits the rotation of it's parent (correct) and inherits the same rotation from the constraint (incorrect), which effectively doubles the amount of rotation.%%%

%%%PS: The file includes a short animation of the empty. If you rotate it around the z-axis manually you should see that the constrained bone (Bone.003) is rotated twice. It inherits the rotation of it's parent (correct) and inherits the same rotation from the constraint (incorrect), which effectively doubles the amount of rotation.%%%
Member

%%%Just committed some attempted tweaks. These still don't seem to solve these problems here yet, though please check to see whether they cause any new problems.

Cheers,
Aligorith%%%

%%%Just committed some attempted tweaks. These still don't seem to solve these problems here yet, though please check to see whether they cause any new problems. Cheers, Aligorith%%%

%%%Just compiled r42086 and tested it with "child-of-influence-bug.blend" in the attachements. Nothing changed. It still behaves in the same wrong way.%%%

%%%Just compiled r42086 and tested it with "child-of-influence-bug.blend" in the attachements. Nothing changed. It still behaves in the same wrong way.%%%

%%%I appended another example "child-of-influence-bug2.blend". If you go there to frame 100 and look at bone.008, you will see that it suddenly flipps it's direction. This wasn't the case in older versions like r39294, in which the bone kept it's direction. Note that the scale-options of the constraint are disabled. (Maybe a dead center case)%%%

%%%I appended another example "child-of-influence-bug2.blend". If you go there to frame 100 and look at bone.008, you will see that it suddenly flipps it's direction. This wasn't the case in older versions like r39294, in which the bone kept it's direction. Note that the scale-options of the constraint are disabled. (Maybe a dead center case)%%%
Author

%%%I noticed that with parent constraints, the child also rotates around the wrong center if influence is <1. The child bone rotates around a center between the parent pivot and its own pivot (exactly half between them if influence is set to 0.5).
Logical behaviour would be this:

  • if there's only a "real" parent (ctrl P in edit mode) -> rotate around parent's pivot (proper behaviour currently).
  • if there's only a constraint parent target with influence 1 -> rotate around the target's pivot (proper behaviour too).
  • if there's a "real" parent and a constraint parent target with influence 0.5, rotate around the middle between the two parents, NOT around child's pivot. (currently: rotates around the middle between child and "real" parent, ignoring the target parent). %%%
%%%I noticed that with parent constraints, the child also rotates around the wrong center if influence is <1. The child bone rotates around a center between the parent pivot and its own pivot (exactly half between them if influence is set to 0.5). Logical behaviour would be this: - if there's only a "real" parent (ctrl P in edit mode) -> rotate around parent's pivot (proper behaviour currently). - if there's only a constraint parent target with influence 1 -> rotate around the target's pivot (proper behaviour too). - if there's a "real" parent and a constraint parent target with influence 0.5, rotate around the middle between the two parents, NOT around child's pivot. (currently: rotates around the middle between child and "real" parent, ignoring the target parent). %%%
Member

%%%Both constraints are imperfect and have given numerous issues in this tracker already.
I will collect all of these in the wiki now. For the time being you should consider them to function "as is".

Note: usage of child-of constraint works best for cases when bone isn't parented itself.

http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/Animation#Constraints%%%

%%%Both constraints are imperfect and have given numerous issues in this tracker already. I will collect all of these in the wiki now. For the time being you should consider them to function "as is". Note: usage of child-of constraint works best for cases when bone isn't parented itself. http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/Animation#Constraints%%%
Member

Changed status from 'Open' to: 'Archived'

Changed status from 'Open' to: 'Archived'
Sign in to join this conversation.
4 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: blender/blender#29100
No description provided.