Esoteric Software

[Nate]

As you probably know, Spine uses non-skewing transforms -- scale is always applied using the bone's local axes. This means the X axis for scaling always points in the direction of the bone's rotation. This is true even for scale inherited from parent bones, which differs from traditional transforms and can be surprising for new Spine users.



Here spineboy's back thigh has been scaled on the X axis which elongates the thigh, shin, and foot. The shin and foot are scaled on their local X axis, which is probably not the desired result. In this case, scale inheritance can be disabled on the shin so it is unaffected by the thigh's scale.

Here is how it would look with skewing transforms (bones are hidden):



The whole leg is stretched in the direction the thigh bone is scaled, instead of using the local axes for each bone. Because they are always scaled in the direction of the thigh, as the shin and foot are rotated in relation to the thigh, they are scaled by the thigh differently:



Skewing transforms can be useful, eg to make multiple bones or a whole character squash and stretch, but when nonuniform scaling skews a bone's coordinate system the X and Y axes are no longer perpendicular and many things become more complicated. Eg, a 360 degree rotation is actually an oval, bone compensation is not possible because the skew can't be represented by SRT, disabling inheritance of rotation and scale is expensive in the runtimes, and more.

It's actually easy to change how Spine computes transforms and I have already done it, but all the loose ends need to be handled before it can be released. Also, we would need to decide whether we change how transforms are applied and potentially break projects that use features that work differently in the new system (scale, flip, inherit scale/rotation, etc), or do we allow either the old or new mode to be chosen for a project. This would prevent existing projects from breaking but mean all the runtimes would have to support both ways, which is a pretty big burden.

Thoughts are welcome!

[Conzeit]

would it be complicated to allow you to select a Skewing transform when selecting multiple bones, but actually not do skewing, and calculate what size each bone would be if it applied skewing transform, and instead get the bones to be those sizes trough non skewing transform? skewing transforms usually arent about precision anyway, and if all you need is a quick squashing or stretching you probably dont need the oval rotations (or I dont imagine why I would)

obviously, I'm not a coder so I hope this doesnt all sound like giberish

[ArtizensAnimator]

Hmmm... this is a tough one.
I would personally love to see the option to use both styles of scaling, but I know that's a big burden, as you say.

Obviously as an animator the ability to squash and stretch the character as a whole would be fantastic, but I also want the ability to control the individual scales of each asset....Having said that I know that there are different methods of achieving this.

I have actually used the non-skewing scale in a few of my animations, and it's worked really well.
I've not really run into any issues and the only thing that it has really stopped me from doing in squash n stretching my entire character, which as I said would be a great feature.

Mainly I use the scaling subtly in the animations, but if there was an option for SnS then I would take it to the extreme.

In Conclusion:

As an animator I would LOVE to see the ability to squash and stretch my characters and have them deform nice and cartoony. This is a very specific style however, and not all devs would want it.
Also as an animator I would LOVE NOT to have to go through and fix all 3000 or so animations I have already done in Spine, or work in an outdated version. I reaaaaallly LOVE the ability to choose whether I inherit scale, rotation or not.

Hope this helps!

[Søren]

Thanks Simon, you input as always is valuable!

[randall]

We do a lot of animation for Disney, Nickelodeon and NickJr HTML5 games, and obsessively use skew in our studio. Not only is it valuable for squash and stretch, but also anticipation, secondary motion and subtle actions. While I think this feature is critical, I don't think the majority will use it, or understand how to use it effectively. How difficult would it be to write a conversion tool to convert older animations to a new format that included Skew? Or build auto-conversion into Spine after Skew is implemented into the new version.

[Nate]

How difficult would it be to write a conversion tool to convert older animations to a new format that included Skew? Or build auto-conversion into Spine after Skew is implemented into the new version.

Scaling using skew is completely different behavior from the current scaling. There's no choice but for runtimes to support both if old animations still need to work (which they probably do). Newer versions of Spine will always open older projects, there is no problem evolving how things work as far the editor, project files, etc go. Spine has already gone through many extensive evolutions and can still open any project file ever saved, back to the very first version.

Note that skew of a single attachment can be achieved using a mesh, since the mesh vertices can be translated independently.

---

We've put some more thought into this. If we were to change how scaling works in Spine so we get rid of the old non-skewing scale and only have skewing scale, what old skeletons and animations would be affected? It would only affect animations that use non-uniform scale that is applied to multiple bones. I have a feeling that no one or very close to no one is relying on this.

If you scale uniformly (ie, the same on X and Y), then it will work the same. If you scale non-uniformly (ie, a different on X and Y) and only affect a single bone, then it will work the same. If you scale non-uniformly and allow a child bone to inherit the scale, only then will it work differently. With the old non-skewing scale, allowing a child bone to inherit the scale means the child bone gets scaled along it's local axes. This is so odd that I really doubt anyone has found a situation where this is the scaling they want. Is that true? Do you use non-uniform, non-skewing scale to affect multiple bones?

As of Spine 2.1.18 you can try out the skewing scale by first downloading and reinstalling Spine to get the latest launcher, then run Spine with the --skew command line argument. On Windows:
Spine.exe --skew
On Mac:
/Applications/Spine/Spine.app/Contents/MacOs/Spine --skew

Please try it with your existing skeletons and report back if anything went wrong. Obviously don't rely on skewing scale since it isn't in the runtimes yet.

Moving to the new scaling is important for a few reasons. First, currently bone flip is always done using the world axes. This can be functional for some types of flipping, but for many cases it is unintuitive. The new scaling allows bone flip to use the local axes. The new scaling also allows for fancy effects using skewed rotation and easy squash/stretch of an entire skeleton:



This is a bit extreme to make it easy to see, but all I did was scale the root bone in order to squash the whole skeleton.

[warmanw]

I assume --skew command is not working thus spine wont load if i add it.

[Pharan]

I wanna try this. I was trying to add --skew to the shortcut. Doesn't load for me too. I probably just don't know how to add arguments in the shortcut properties in Windows. I'll try to run it in actual cmd later.

But loaded it normally and tried out the graph presets. (nice, by the way) I noticed you rephrased the exit confirmation dialog box buttons with "Exit without saving" and "Save and Exit". Still honestly a bit visually vague and not what I would've picked but it's still clearer than what the old buttons said.

Thanks, Nate!

I'm kinda excited about this skewing scale though. Just a bit worried about the other issues it might cause (breaking disable-rotation inheritance?, what were those other things?), if it still causes them.

Skewed rotation is also great for faking rotating 3D circles. and other fun effects like that. Always great.

My opinion on the old behavior is: relying on the old non-uniform scale inheritance was an animation hack, if anyone ever used it. Its behavior is so peculiar.

---
In command prompt.

saying Spine.exe --skew
does nothing.

saying Spine.com --skew results in this:
ERROR: Missing Value for command line parameter: --skew

[madavd]

I think you can imagine the shock when I opened the program.

shock.png

[Søren]

Since it's a command line parameter you will need to download Spine again if I'm not mistaken.

[MartinM]

Sounds great! - How do i run this on a mac?

[Søren]

Actually I'm having some issues with it as well. I'll get back to you as soon as I have some more information, or maybe Nate will

[Nate]

madavd, you should probably explain such a screenshot.

Sorry guys, I forgot Spine's command line arguments are validated by the launcher. I've uploaded a new launcher that supports --skew. You'll need to download and reinstall to get launcher version 2.2.02+. On Windows:
Spine.exe --skew
On Mac:
/Applications/Spine/Spine.app/Contents/MacOs/Spine --skew

[bcAnim]

inheritScaleOff.jpg

I tried out the new skew. Is the inherit scale toggle not working? It seems that anything that had inherit scale turned off is now affected by scale which is not a good thing in my case. The image above would be a character's lower arm, and the hand bone has inherit scale set to 'off'. With animation I might want to scale the arm to create a foreshortened look but keep the hand the same size and shape. And this wouldn't be the only case like this, I can think of many other instances where I would not want an object to inherit scale.

I also noticed that bones that are 'flipped' are now rotated differently, which isn't good for old animations, but I don't think it would be a problem going forward. I like that the flipped bones no longer counter-rotate to their parent's movement, if that makes sense. Thanks!

[Pharan]

Ah. Right, breaking disable-inherit scale is probably the biggest issue. 'cause otherwise, the new system could work with skewing and also like the old system if you wanted to, just with more keys.

Though Nate did say in the first post "[...] In this case, scale inheritance can be disabled on the shin so it is unaffected by the thigh's scale." Maybe it just hasn't been implemented yet?

[madavd]

You see Nate, I use a lot of flip bones and scale on my animations.
The first screenshot was after i put the "--skew" on the spine, and pretty much all the animations were broken.
The second screenshot is from the old system, everything seems fine.
Sorry I didn't explained on the other post.

[Nate]

Yes, there are some issues. For now don't file bugs, just try skewing scale. Disable rotation and scale inheritance will work.

madavd, thanks. Because flip works differently with skewing scale, I can see that breaking some existing animations. The new way flip works is much better, FWIW. I have a feeling your use of scale is probably ok and it is just the flip that is a problem? Unfortunately it's not something I can fix automatically.

[madavd]

Disable rotation and scale inheritance will work.

Well I don't think it work as it should.

bug.png

As you can see i deactivated the rotation and scale inheritance (in SETUP mode), and the result (in ANIMATE mode) was very funny actually. The thing is, I probably made something wrong to end up with this result.

[Nate]

Again, please do not test disabling scale or rotation inheritance right now. It is known it doesn't work right now. Sorry if that makes it hard to test with your existing skeletons.

[bcAnim]

skewScaling1.jpg

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?

---

[Nate]

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?

[bcAnim]

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.

[Pharan]

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.

[Nate]

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.

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.

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.

[PhilippH]

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