OS: Blender 2.66a, Windows Vista 32bit, nvidia
--- Short description of error ---
I want one skeleton to be in same pose as another. I use "Copy Transform" (or "Copy Scale", "Copy Rotation" and "Copy Translation") Constraint on the bones.
Copy Scale does not seem to work as I expect it to work. I expect a bone with "Copy Transform" and "World Space" setting to be the same as its target bone. But scale seems to be ignored (I assume scaling is not relative to rest pose with "World Space" setting, at least for the other constraints this seems to be true).
--- Steps for others to reproduce the error (preferably based on attached .blend file) ---
See attached file:
- 2 armatures with different rest pose (Note: "Armature.001" is in rest pose at the moment, press "Pose Position" to see the effect of the constraints)
- "Armature.001" bones are constraint to bones of "Armature", with "Copy Transform" and to be sure with "Copy Scale" too
- While rotation is copied, scale and because of that position do not match
Description
Event Timeline
Hi,
Unfortunately, after some investigation, it appears that this isn't really a bug, though admittedly this situation is a bit confusing. (See 267-scale_constraint-noBug.blend)
Copy Scale constraint only really takes the "scaling factor" - a measure relative to how much the size of an item has changed relative to its "rest" state. This is not quite the same as absolute size/dimensions.
In your particular case, it might be easier to just tweak the bone lengths so that they are the same in both chains. Alternatively, you could try using StretchTo constraints instead (with Head/Tail set to 1.0 for all of these, and with manually tweaked "rest length" values to get a reasonable fit between the two). At least in my tests here, it seems to work ok, though the middle bone does end up getting a bit "fat" as it does need to be truncated the most to fit.
Thanks for looking at the issue.
I understand that it works as designed now. But I still find it not logical. Translation and rotation are handled by absolute world space values. It is strange that scale is handled differently.
Have now solved my issue with a script, with StretchTo I was not able to get a perfect match.