Stretch To constraint breaks scaling in Transform constraint #29940

New Issue

Anna Celarek · 2012-01-20T22:40:54+01:00

Anna Celarek commented

2012-01-20 22:40:54 +01:00

%%%See attached file. Rotate Master2 (small bone on top) and watch how Child1 (left green bone) illegaly elongates.

Master2 (small bone on the top) is used to control Child1 (left green bone) as Transform source (1st) and StretchTo target (2nd).
The Transform constraint tansforms the X-rotation of Master2 to Z-scale of Child1. This works well as long as there is no StretchTo constraint below (or is turned off).
When there is a StretchTo, then the X rotation of Master2 causes a Y-scale of Child1 additionaly to the Z-scale. This Y-scale is not linear, it is stronger in the positive rotation direction.

I also tried to switch the constraints and put Transform after StretchTo, see Child2 (right green bone). Now the StretchTo loses its effect on Y-scale of Child2 completely (it behaves like TrackTo). This is somehow logical, as the Y-scale is set to 1 in the Transform constraint and apparently overrides any scaling caused by StretchTo.

But the other way around, with StretchTo after Transform, I see no reason why the Y-scale of Child1 should be affected by rotation of Master2.

Windows 7
2.61.0 r43212
2.61.3 r43565%%%

%%%See attached file. Rotate Master2 (small bone on top) and watch how Child1 (left green bone) illegaly elongates. Master2 (small bone on the top) is used to control Child1 (left green bone) as Transform source (1st) and StretchTo target (2nd). The Transform constraint tansforms the X-rotation of Master2 to Z-scale of Child1. This works well as long as there is no StretchTo constraint below (or is turned off). When there is a StretchTo, then the X rotation of Master2 causes a Y-scale of Child1 additionaly to the Z-scale. This Y-scale is not linear, it is stronger in the positive rotation direction. I also tried to switch the constraints and put Transform after StretchTo, see Child2 (right green bone). Now the StretchTo loses its effect on Y-scale of Child2 completely (it behaves like TrackTo). This is somehow logical, as the Y-scale is set to 1 in the Transform constraint and apparently overrides any scaling caused by StretchTo. But the other way around, with StretchTo after Transform, I see no reason why the Y-scale of Child1 should be affected by rotation of Master2. Windows 7 2.61.0 r43212 2.61.3 r43565%%%

Anna Celarek commented

2012-01-20 22:40:54 +01:00

Changed status to: 'Open'

Bastien Montagne commented

2012-01-21 09:39:00 +01:00

%%%In fact, Transform is not involved in the problem – it’s only Strech To: you will have the same effect by disabling Transform, and scaling up/down along the bone Z axis…

The same goes with objects. I’ll try to have a look at the code, to see whether this is intended or really a bug.%%%

%%%In fact, Transform is not involved in the problem – it’s only Strech To: you will have the same effect by disabling Transform, and scaling up/down along the bone Z axis… The same goes with objects. I’ll try to have a look at the code, to see whether this is intended or really a bug.%%%

Bastien Montagne commented

2012-01-21 10:43:20 +01:00

%%%Yeah, definitively think it was a bug.

Fixed in svn43578, thanks for reporting! :)%%%

%%%Yeah, definitively think it was a bug. Fixed in svn43578, thanks for reporting! :)%%%

Anna Celarek commented

2012-01-24 21:02:03 +01:00

%%%Thanks! It also fixed another of my reported bugs btw. %%%

Ed Halley commented

2012-01-29 00:57:44 +01:00

%%%The fix recently committed breaks other models. I use the popular "Sintel Lite" model for a number of things, but must scale her rig 5x to match other characters and props. The eyelid bones use StretchTo constraints to make a perfect rim of bones along the eyelids.

With the recent patch, the eyelid bones are 5x overlong. Similarly, scaling the armature to 0.2x original size, the eyelid bones have gaps.

There seems to be a bit of matrix stomping going on in this code. For armatures especially, StretchTo length must be considered in local space, not global space. Simply forcing or normalizing scale is not going to work well.%%%

%%%The fix recently committed breaks other models. I use the popular "Sintel Lite" model for a number of things, but must scale her rig 5x to match other characters and props. The eyelid bones use StretchTo constraints to make a perfect rim of bones along the eyelids. With the recent patch, the eyelid bones are 5x overlong. Similarly, scaling the armature to 0.2x original size, the eyelid bones have gaps. There seems to be a bit of matrix stomping going on in this code. For armatures especially, StretchTo length must be considered in local space, not global space. Simply forcing or normalizing scale is not going to work well.%%%

Bastien Montagne commented

2012-01-29 10:12:21 +01:00

%%%Did you try with a build later than rev43662 ? My first fix for this bug was indeed wrong, but the new one should be good ([#29962]).

Previous behavior, as well as current one, is to make the bone/object insensible to scale along its Y axis (it’s just that previous code was wrong, making scaling completely unreliable with rotated objects).

Also, I see no stretch to constraint for eye lid bones, in this rig ?%%%

%%%Did you try with a build later than rev43662 ? My first fix for this bug was indeed wrong, but the new one should be good ([#29962]). Previous behavior, as well as current one, is to make the bone/object insensible to scale along its Y axis (it’s just that previous code was wrong, making scaling completely unreliable with rotated objects). Also, I see no stretch to constraint for eye lid bones, in this rig ?%%%

Ed Halley commented

2012-01-29 17:37:49 +01:00

%%%
Bastien, thanks for the quick reply. I did fetch SVN again last night, and rebuilt when I saw your note. Sintel_Lite looks good at 5x and 0.2x now. I hope Anna Celarek above still finds success.

As for Sintel_Lite, the rig has a lot of hidden bones. It took me a while to find it, and there was a weight-painting error as well. (I am assuming it's all the same as Durian Sintel, but maybe it's been revised.) Enable the second to last armature layer, see bones like MCH-lid.009.%%%

%%% Bastien, thanks for the quick reply. I did fetch SVN again last night, and rebuilt when I saw your note. Sintel_Lite looks good at 5x and 0.2x now. I hope Anna Celarek above still finds success. As for Sintel_Lite, the rig has a lot of hidden bones. It took me a while to find it, and there was a weight-painting error as well. (I am assuming it's all the same as Durian Sintel, but maybe it's been revised.) Enable the second to last armature layer, see bones like MCH-lid.009.%%%

Bastien Montagne commented

2012-01-29 17:49:26 +01:00

%%%Oki, good, then closing again :)

Sorry for that first buggy-fix.

And yes indeed, that’s a rig… Makes me feel small, small… ;)%%%

%%%Oki, good, then closing again :) Sorry for that first buggy-fix. And yes indeed, that’s a rig… Makes me feel small, small… ;)%%%

Bastien Montagne commented

2012-01-29 17:49:28 +01:00

Changed status from 'Open' to: 'Resolved'

Bastien Montagne closed this issue

2012-01-29 17:49:28 +01: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

Stretch To constraint breaks scaling in Transform constraint #29940