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

New Issue

Anna Celarek · 2011-10-30T17:36:47+01:00

Anna Celarek commented

2011-10-30 17:36:47 +01:00

%%%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).

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.
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%%%

Anna Celarek commented

2011-10-30 17:36:47 +01:00

Changed status to: 'Open'

Joshua Leung commented

2011-10-31 01:17:25 +01:00

%%%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").

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).
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.%%%

Anna Celarek commented

2011-11-01 00:22:28 +01:00

%%%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? %%%

Tobias Oelgarte commented

2011-11-01 01:18:50 +01:00

%%%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)%%%

Tobias Oelgarte commented

2011-11-01 01:32:47 +01:00

%%%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.%%%

Joshua Leung commented

2011-11-22 12:51:56 +01:00

%%%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%%%

Tobias Oelgarte commented

2011-11-23 15:14:53 +01:00

%%%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.%%%

Tobias Oelgarte commented

2011-11-23 15:29:18 +01:00

%%%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)%%%

Anna Celarek commented

2011-11-23 21:50:45 +01:00

%%%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). %%%

Ton Roosendaal commented

2012-10-21 19:19:22 +02:00

%%%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%%%

Ton Roosendaal commented

2012-10-21 19:19:22 +02:00

Changed status from 'Open' to: 'Archived'

Ton Roosendaal closed this issue

2012-10-21 19:19:22 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

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