Animation Sorting Issue: Spine-Editor v. Unity

jonhollowa

Hello Esoteric,
We're currently having an issue with the Spine runtimes for Unity. Our animators animations sorting order is not working appropriately inside of Unity, in comparison to the editor. Example of what the issue is: Let's say there is a side rendering of a character. This characters right arm starts the frame rendering in front of them then the animation moves it away from the body then behind the character, to scratch it's back. On the frame when the arm is away from the character the forearm and hand set their sorting layer to behind the body, this way when it reaches it's final frame it will render behind the character. In this situation everything appears fine in the Spine editor. However, when exported to Unity the sorting layers pop or, occasionally, don't work at all.
We've tried many things

both in code and through the animation itself

to attempt to alleviate the issue and have come up with nothing. Do you have any recommendations as to what could be effecting this or any way to resolve this issue?

Mitch

Are you using the Spine/Skeleton shader?

jonhollowa

Yes, we're using the Spine/Skeleton shader on all things using a Spine animation.

We've made some modifications to the Spine/Skeleton shader, for specific rendering reasons, so just to be safe I reverted to the latest version on your GitHub repository. The issue still occurs using that version, as well.

Mitch

SkeletonAnimation or SkeletonAnimator?

jonhollowa

Skeleton Animation.

Pharan

Does calling skeleton.SetSlotsToSetupPose() before playing a new animation fix the draw order for you?
Does doing this change the results at all?

jonhollowa

That doesn't appear to fix the issue.
Sadly, even if it did, calling that function also re-enables specific slots on the character's mesh that have been disabled

as they're special case for different items

causing more rendering issues to occur. :S

Pharan

That's okay. That's still informative.
It wasn't a real fix. It was just the quickest way to tell the skeleton to reset its draworder.
'cause the API doesn't have skeleton.SetDrawOrderToSetupPose() yet— you could easily add that yourself though. It's a matter of copying a few lines from SetSlotsToSetupPose to a new method.
And, apparently, it didn't fix it?

Can you make a gif of it or something? Or share the exported files? (with solid-colored images if you're worried about it being stolen)
This is really hard to diagnose.

Did you also do some programmatic things like create new slots at runtime?

jonhollowa

Sorry for the delayed response, a couple of other priorities on the project came up. We're creating a texture at runtime for the animation but that's it. No slots are created at runtime. Here is a gif of the issue; if you need more

the animation file and what not

I'll see what I am allowed to share.

http://i.imgur.com/kMJ7GwO.gifv

Mitch

This looks like a case of your draw order key to push the hand into the foreground is happening during a transition mix to another animation in which case only the next animation's draw order, attachment, and other non-transform keys are used.

jonhollowa

All animations start and end on the same draw order and we wait until the animation has completed to startup a new animation, using the appropriate callback.