They are, mostly. See the in progress task "Non-axis aligned scaling (skew)"? That has been an absolute quagmire! We've worked through most of the issues. All of the tools have changed under the covers. Disabling rotation and scale has changed, it actually had to be removed. In it's place we will have "transform constraints", which let you copy scale, rotation, and/or translation from one bone to another.

The biggest issue has been with how IK works with the new scaling. This required a lot of R&D and completely different IK solution, which in turn had a number of issues. They are almost all resolved and integration into the editor is partially done. Still to do is porting the new IK, transform constraints, and any other changes needed to all the runtimes.

The old IK had limitations, though you may not have noticed. Eg, the child IK bone could not scaled on X or translated. Unfortunately the new IK imposes some new limitations. Currently those are: 1) no intermediary bones, ie there can no longer be other bones between the parent and child IK bones, and 2) the child IK bone local Y position must be zero. It's unfortunate we can't support IK the exact same way that it used to work, because any differences mean the potential for projects to not work the same way. There is no way around it though, not without making the IK solution even crazier.

I apologize for not being able to give better progress reports. I hate that we haven't been able to do our typical releases every few days for a long time. All of this new stuff will get wrapped up as Spine version 3.x.xx. That will be a big release, then we will go back to a much shorter release cycle and tackle some of the issues and important features that we haven't been able to get to.

On the bright side, the new scaling does fix all the flip issues, which I know you have reported and personally suffered from!

I like the idea of Transform Constraints as a solution for achieving the old scaling behavior.

It also smells like the way Creature does things; transform values calculated from other sources.

There was one interesting and kinda-related feature I learned about in Anime Studio Pro.

Basically, if it were in Spine, it would work like this:
First, you define a variable: it's some kind of switch (a boolean, or trigger) or a slider (a float or int).
Then, based on the keys of that switch or slider, you can affect the transform or values of other bones or items in the skeleton.

You can scale or rotate a bunch of bones in their individual pivots based on one slider.
More practically, you can easily tell a group of slots to hide their attachments, or switch to a different set of attachments. (great for switching between front and side view image parts, or facial expressions or whatever.)
Also interpolating back and forth between the two extremes of a fake-3D-effect face rotating thing with a slider.

Just a thought.

More importantly, when is the pizza coming?

Pharan, if anything it smells like how SoftImage does it.

I agree, more powerful controls like you mention can make a complex rig a lot easier to work with.

BinaryCats ：

will the pose tool still use ik calculations?

will we be able to have more than 2 bones per ik with this new system?

The pose tool currently freaks out a little when using extreme scale in only one direction, but in general it works pretty well. It is a bit different than the correct IK solution, but suitable for posing. By this I mean that the pose tool will point the bones at a target out of range, whereas the correct IK solution may not. Consider that nonuniform scale makes a bone's length change depending on its rotation. If pointing the bone at the target made the bone shorter, the correct solution would be to have the bone bent so the tip is closest to the target. This is how the new IK constraints work and is required for the skeleton to behave as you expect, especially when transitioning to and from nonuniform scale.

I expect not a lot of people will scale their skeleton in only one direction and then do a lot of manipulation with the tools. This actually breaks many tools, such as SoftImage, Lightwave, and I believe even Maya. They tools will behave strangely, or worse IK will choose the wrong solution. The tools breaking aren't such a big deal, but in the runtime the IK and transforms have to be rock solid. Our transforms are good and we've got an IK solution that works for all situations, with the limitations mentioned.

One thing I'm considering is when to impose the limitations for IK. If you aren't doing nonuniform scale, then intermediary bones are fine (I agree they aren't a crucial feature) and translating the IK child bone on Y is fine. I'm ok not supporting intermediary bones. The IK child Y could be handled a few ways.

1) There could be some sort of setting which enables it, but I (ironically) dislike esoteric settings because going down that road leads to dozens of settings which almost no one understands and ease of use is out the window.

2) We could just allow it and people would have to learn that nonuniform scale breaks IK unless the IK child bone Y is zero. Maybe they aren't doing nonuniform scale and would prefer not to be limited. Maybe the breakage isn't a big deal for some situations, such as some minor squash and stretch on the whole skeleton. I think I'm partial to this solution. It means existing projects will probably not break, since people didn't generally use scale across multiple bones, since it wasn't all that useful.

3) We could set the IK child bone Y to zero when the IK constraint is created and never allow it to be changed. This ensures IK never breaks, but breaks existing projects more and doesn't allow an option to translate the child Y when using uniform scale.

No, IK will still be limited to 1 or 2 bones. A 3 bone solution would be quite complicated.

Pizza is in the works!

SoftImage is dead, long live Spine!