• Editor
  • Spine's non-skewing transforms

Related Discussions
...

I think in the case of limbs the old way might be better. I could see wanting to stretch a character's arm or leg and having it extend better the old way, whereas the new way distorts the lower limb into a more unnatural shape. The above image is a character's arm with the upper arm scaled longer and shorter with both the new and old methods.

Or imagine if a character had a whip or something that was made up of a long joint chain, and you wanted to animate it extending in length as it swings. It seems to me the old way would work better for something like that.

edit: although now that I think about it you could just turn off inherit scale on the lower limbs with the new method to avoid the distortion.

But I could also see when you could benefit from the skewed scaling. Could it be possible to decide the type of scaling on a per bone basis?


7 days later

Aye, you can disable scaling (once that works correctly!) and then scale similar to the old way, if that is what you need.

I'd prefer to support only one scaling mechanism if possible.


Everyone has tried the new skewed scaling and will be happy when we replace the old scaling with it? 🙂

Would it be possible to write a tool or a button that would automatically fix the rotations of flipped parts that used the old scaling before? I think the new scaling will be good, but I'm not looking forward to fixing all that stuff.

Just tried it with some old skeletons. Even the ones that were kinda using inherited scaling (for a snappy bulging effect) looked better.
How much more expensive are we talking about when you say disabling inheritance for scale and rotation are expensive?

bcAnim has a point. Will the data format change?
If it doesn't, people can just continue to use the old runtime? I guess it'll make it un-viewable/uneditable though.

bcAnim wrote

Would it be possible to write a tool or a button that would automatically fix the rotations of flipped parts that used the old scaling before? I think the new scaling will be good, but I'm not looking forward to fixing all that stuff.

The new scaling changes the way flipping works (flipping a bone uses the bone's local axis, it used to always use the world axis). Unfortunately, it isn't possible to adjust old projects that use flipping to look the same.

Pharan wrote

How much more expensive are we talking about when you say disabling inheritance for scale and rotation are expensive?

Old code:

if (data.inheritScale) {
   worldScaleX = parent.worldScaleX * scaleX;
   worldScaleY = parent.worldScaleY * scaleY;
} else {
   worldScaleX = scaleX;
   worldScaleY = scaleY;
}
worldRotation = data.inheritRotation ? parent.worldRotation + rotation : rotation;

New code:

if (!data.inheritScale) {
   float psx = sqrt(p00 * p00 + p10 * p10);
   p00 /= psx;
   p10 /= psx;
   float shear = p00 * p01 + p10 * p11; // dot
   p01 -= p00 * shear;
   p11 -= p10 * shear;
   float psy = sqrt(p01 * p01 + p11 * p11);
   p01 /= psy;
   p11 /= psy;
}
if (!data.inheritRotation) {
   rotation -= parent.worldRotation
      * (parent.worldFlipX != parent.worldFlipY ? -1 : 1);
}
// ...
worldRotation = atan2(m10, m00) * radiansToDegrees;
worldScaleX = sqrt(m01 * m01 + m11 * m11); // Never negative!
worldScaleY = sqrt(m00 * m00 + m10 * m10);

The difference isn't much, but it's there. The math is very likely to pale in comparison to the other things an app is doing. sqrt should be an intrinsic.

Pharan wrote

Will the data format change?
If it doesn't, people can just continue to use the old runtime?

The structure of the data format doesn't change, but the interpretation of the data changes. Old exported data should use the old runtimes. If used with the new runtimes, scale will be applied differently and may not look correct (will look the same as if you open an old project with Spine). New exported data should use the new runtimes. If used with the old runtimes, scale will be applied differently and may not look correct.

To be clear, the only bones that are affected by the new scaling are:

  1. Bones that inherit scale from their parent and have a parent that has non-uniform scaling (ie, are scaled a different amount on X and Y). A bone's scale works exactly the same for that bone (even when non-uniform!), it's only when inheriting non-uniform scale that the new scaling is different.

  2. Or, bones that are flipped and are not the root bone.

I don't expect #1 to affect many projects, because inheriting scale with the old scaling wasn't very useful. It's more likely that people have flipped bones, and those projects will need to be fixed up manually.

I'll do a release of 2.1.19 today which should allow inherit scale/rotation to be disabled with the new scaling, so you guys can better test how your projects work with it.


2.1.19 is up.

Hey there,

I also tested the new skewing scale and think this is it!
Finally I can do some nice squash and stretch animation. 🙂

We now need to decide which way we implement in our engine. Is the new skewing scale intended to stay?

I am not sure how hard this would be but here's a suggestion that would make the animators life much nicer:
Can you add like a second scale tool mode, where it maintains the volume. Meaning:
If a bone scales down in one axis 2 times as much as normal, it will have to get 2 times as wide in the other axis to keep its volume.
Basically a "Squash&Stretch Scale tool"?
I would love you for this!! 🙂

Btw: I recently held a presentation about Spine in Munich, Germany at Werk1 in front of 40 indie and professional developers and I got great feedback!
Se keep it up and we hope to get even more cool features (like a nice graph curve view)!

Best
Philipp

6 days later

PLEASE carry the new skewed scaling through to the the final software!

I have animated using 2D parenting systems that use skewed scaling (such as After Effects) for a while now and I've -never- had to work around issues like you described in your top thigh example. I feel that it's a poor example anyway, as I can't think why someone would want to non-uniformly scale the thigh in that position for a side-on run cycle, and more importantly, keep it scaled that way long enough for it to cause skewing problems. In my experience, skewed scaling is used predominantly for squash and stretch, which happens for a handful of frames at the apex of a movement, not all the way through!

I'm currently animating an animal scaling rapidly in X only and I've LOVE to be able to create a simple S&S settle (in X only) with just the root bone. But as the software is now, this causes all the child bones (arms, eyes, ear, head, etc) to squash in the X axis as well, which is not at all the desired result. I have to either disable scale inheritance and apply the scale settle to every individual child bone (NOPE! - and at times impossible if the child bone is not aligned perfectly with the root) or fight the inherited non-uniform scale with a key on each frame (also NOPE!).

Anyway, that's my two cents! Really hope to see this in Spine soon.

Thanks for the feedback tmonash. I think the new scaling will make it in. There's still a small amount of work to be done with the math, plus the tools and bone compensation need some adjustments. We'll likely bump the version to 2.2.x when the new scaling is ready.

Great to hear, Nate!
I would like to use the new scaling in a current game project. We still have couple of month to go, but it would be nice to know when do you think this will happen? The sooner the better, of course 😃
Thanks a lot!

I really can't give an estimate. I'd just be making things up so it's better not to say. I want to do it ASAP, but there's a whole bunch of stuff backlogged from when I was sick, and now Shiu is sick. Flu season sucks!

When you switch to the new scaling, I would like to request the feature to lock a Spine file to a specific version, to make sure an animator doesn't open a 'legacy' character that is only supposed to be animated in an older version and then work all day only to later realize they are working in the wrong version. When you open it, it could say something like 'this file is locked to version 2.1.27. Would you like to unlock it?', I think that would be enough to remind someone to open in the right version if they need to.

It's an interesting idea, but I'm not sure the Spine file is what needs to be set to a specific version. Eg, it is common to freeze the Spine and runtimes version so a team of animators and developers can work without interruption. Periodically a developer would update the runtimes and an animator would check the latest Spine, verify both are working correctly, then move the team to the latest Spine version and freeze it again. If your "version warning" idea was used in this scenario, every time the Spine version was updated this would result in all the Spine files complaining that the Spine version might be wrong.

It's really the project or team that has a Spine version freeze. I think keeping everyone on the correct version of Spine is something that needs to be managed outside of Spine.

9 months later

Just wanted to give my 2 cents as a seasoned animator.
I love the skew! It would definitely be useful and am very glad you implemented it! Wish there would be a way to skew a single sprite/limb, like in flash. I guess that would be another transform under translate, rotate and scale. Either way excellent work!

Thanks janimator0! Since we now support skew we could indeed make it visible like SRT. I'm not sure how often that would be used though and it means slightly more data needs to be applied to the bones. As a workaround, you could scale a parent bone nonuniformly to skew the children.

Do I understand correctly that the skewing and scale and transforms constraint is not made until the end? Since they are not active in the animation mode.

belpetr, sorry I'm not sure what you mean. Can you explain more?

If they're grayed out, you can't animate them.
You have to change them in Setup Mode.