Here is a weird one, I have a fully rigged armature with 30 animations and i realized that my armature is not scaled to 1. So I did the Scale and Rotation to ObData (ctrl+a) function to my armature to reset the scale to 1. So before my armature was scale of 0.7 and now it is at 1 where it should be.
Problem is, now all animations are much too big for my armature. The scale does not match. So how can I fix this? I have 30+ animations so I do NOT want to go into my IPO curve editor and hand scale each bone for all of my animations.
There must be some way to get the scale of my armature and animations to match.
right, well i need to have it a scale of 1 because I am importing it to Panda and everything is calibrated to a certain scale.
I guess I just need to scale up my armature until it matches the keyframes and then do ctrl+a again – then take care of any scale issues within Panda (or wherever one might export to from blender).
At first I thought it was a poorly developed function of blender for this to happen, but on second thought i guess it makes sense for a scale mismatch in this case.
Actually, on second thought, this IS a bug. The animation keyframes scale when the armature is scaled, as it should. But when you apply the Scale to ObData, the operation is only applied to the armature and not the animation keyframes as well – but they should be.
So if Blender does not automatically reset the scale of BOTH the armature and keyframes, there should at least be a similar operation as Scale to ObData that will do this for keyframes.
To me this is a bug… does anybody agree? Or does anybody know a workaround?
After looking into this (also in 2.49b) I don’t think it’s actually a bug as much as an unfortunate consequence of certain operations and relationships, maybe resulting from weak design, maybe not.
In any case, I found that keyframe values (Y-axis) are not directly scaled by scaling an Armature. Instead, it seems that the scaling introduces a factor in the Armature space configuration that is used to modulate the keyframe data when the Armature is scaled. All bone keyframe data is relative to Armature space, so if that space is scaled, the keyframe data is also effectively scaled by the proper factor. I say “effectively” because actual values in the IPO curves are not changed, which can be seen by monitoring those values while doing the Armature scaling.
Say you have an Armature with a bone that translates over 1.0 units during an animation. Scale the Armature by 1.5x and the bone now translates 1.5 units. But the IPO curve data still shows the 1.0 unit translation. Conclusion: Scaling the Armature introduces a factor that modulates the IPO curve data for the scaled Armature, rather than changing it directly.
Now, applying the new scale with CTRL+A does two things: first it resets the Object scale to 1.0 (and thus resets the Armature space configuration), but also preserves the scaled bone sizes in relation to world space – the Armature is still 1.5x bigger. But the keyframe data is no longer being modulated by the Armature scaling factor, so it does not “fit” the newly resized Armature space any longer.
This is all based on observation of a rig I have on hand for experimenting with, so it may not be 100% accurate in the details of my conclusions, but it does describe the situation in terms of functionality as I’ve observed it so far.
Unfortunately, this also seems to indicate there are no practical workarounds, because the IPO data stays constant, meaning there’s no way to know exactly how the scaling factor is applied. Rotations should be unaffected because they are scale-independent. Translation and Scale must be modulated but by what process/algorithm is not exposed to a casual user, though it may be amenable to scripting – that’d take quite a research process, though, imo.
Not much help, I know, but maybe clarifying the situation will provide some new avenues for investigation. Also, does Panda provide some sort of scaling operation on its end? That seems a pretty common capability for almost all 3D apps and game engines. Might be a simpler solution all around.