Updating editor and runtimes from 2.1.7 to 3.5.x

Maltakreuz

I am going to update my whole game to new spine. I am using Spine 2 for a year, but my new animator wants to use Spine 3.

In runtime description everything looks fine.
spine-runtimes/spine-unity at master

spine-unity works with data exported from Spine 3.5.xx.
spine-unity supports all Spine features.
Unity's physics components do not support dynamically assigned vertices so they cannot be used to mirror bone-weighted and deformed BoundingBoxAttachments. However, BoundingBoxAttachment vertices at runtime will still deform correctly and can be used to perform manual hit detection.

But the project it pretty big, so i am just want to know is there any known issues for such updates? I will be woundered if it "just works".

Pharan

The jump from Spine 2.x to Spine 3.x involved fundamental changes to how bones inherit scale and rotation.
It's likely that your animations that have any type of scaling will break.
Because of the new scale and rotation inheritance, Spine 3 also no longer has bone flip, since it can be achieved using the new negative scale behavior, but with different rules.
This means animations that had any bone flip will need to be modified.

If neither of these things apply to your animations and skeletons, things should "just work".

Maltakreuz

Pharan wrote
The jump from Spine 2.x to Spine 3.x involved fundamental changes to how bones inherit scale and rotation.
It's likely that your animations that have any type of scaling will break.
Because of the new scale and rotation inheritance, Spine 3 also no longer has bone flip, since it can be achieved using the new negative scale behavior, but with different rules.
This means animations that had any bone flip will need to be modified.

If neither of these things apply to your animations and skeletons, things should "just work".

Thank you for info. I am not really using scale, and flip skeletons somehow by runtime. Now i should just commit code and try🙂

Pharan

Oh, again, inherit scale/rotation behavior changed, so if you disabled scale/rotation inheritance, that might also break some things in some cases. Not all. But you should definitely test in the editor before you do anything to your runtime.

Or back everything up, of course.

Maltakreuz

It looks like that some behaviors are changed in runtime. In "old" runtime after playing some not looping animation, it was NULL after animation is done. So i need change my code like this

skeletonAnim.state.GetCurrent(LEFT_WEAPON_TRACK) != null
skeletonAnim.state.GetCurrent(LEFT_WEAPON_TRACK).IsComplete

Although it works, i have another problem. Such animations sometimes affect other anims, making them incorrect. It there any way to make anims NULL, as it was in Spine2, after they are finished?

25 Dez 2016, 23:17

upd
Found quick and dirty bugfix for my problem, just calling this in Update().

void ClearCompleteNonLoopAnims() {
    int MAX_TRACK = 6;
    for (int i = 0; i < MAX_TRACK; i++) {
        TrackEntry te = mySkeletonAnimation.state.GetCurrent(i);
        if (te != null && !te.Loop && te.IsComplete) {
            mySkeletonAnimation.state.ClearTrack(i);
        }
    }
}

Still a little bit unsure, why i did not need such code in older Spine, but at least i am not blocked by this issue anymore.

Nate

If I understand correctly, to get the old behavior:

TrackEntry entry = state.setAnimation(0, "run", false);
entry.trackEnd = entry.animation.duration;

In 3.5, by default TrackEntry trackEnd is set to max float (essentially forever) for both looping and non-looping animations. It used to be set to the animation duration for non-looping animations.

Pharan

That's right. Setting trackEnd mean you don't need to check all the TrackEntries every frame.

Alternatively, you can also change the default behavior to the old one by changing this line: spine-runtimes/AnimationState.cs at master
The old value is commented out.