- 수정됨
Animation Sorting Issue: Spine-Editor v. Unity
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?
Are you using the Spine/Skeleton shader?
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.
SkeletonAnimation or SkeletonAnimator?
Skeleton Animation.
Does calling skeleton.SetSlotsToSetupPose() before playing a new animation fix the draw order for you?
Does doing this change the results at all?
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
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?
6일 후
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.
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.
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.