randall a écrit

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 `

skewcommand line argument. On Windows:Spine.exe

skewOn 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:

 Loading Image

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.

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

skewOn Mac:/Applications/Spine/Spine.app/Contents/MacOs/Spine

skew`

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.

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.

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 a écrit

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 a écrit

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 a écrit

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.