- Изменено
Unity runtime element drawing order BUG
Hi,
we have recently updated both the spine software and runtime but we have encountered an annoying bug when playing the animations ingame.
The elements seems not to be drawn in the order set in Spine.
For example during the same animation on the same frame, in the Spine software it renders: http://puu.sh/7m74V.jpg , wheras in Unity it renders: http://puu.sh/7m6VD.jpg
So in Unity, the character looks like some of his parts are blinking...
Are we missing something ?
Note: We first noticed this problem on a 2-month old Spine-generated animation. I thought that maybe the animations generated by the older Spine Software were not compatible with the new Unity runtime, but I've tried to re-export the animation using the latest version of the Spine Software, and still the same issue !
I've been using Spine-Unity for months. I've never seen this happen.
I wonder what's causing it.
You say you've updated to latest Spine editor and Spine runtimes?
Yes
Updating the runtimes often requires exporting again. Be sure to update both spine-csharp and spine-unity. Maybe there is a bug with multiple atlas pages or something other users aren't doing. Can you email a Unity scene that shows the problem? contact@esotericsoftware.com
6 дней спустя
Mail sent.
Any news Nate ?
4 дня спустя
Sorry for the delay, I've been getting buried with stuff to do. 
Your project looks awesome BTW. 
After some digging I found it was a problem with how the submeshes are reused for multi page atlases. I've committed a fix. Thanks for making the example project, I don't know I could have found the issue without that!
Would you know if the culprit was the index zeroing or "submesh.indexCount = submeshIndexCount;"?
My Unity-FFD fork already moved the latter higher in the code but not the former.
Hi !
Thanks Nate, I've updated the runtime and I no longer have the issue !
However it seems that it introduced a new one :/ . On some animations, some parts are disappearing sometimes...
I'm sending you an email with an updated project showing the problem
Pharan, not sure what you mean? I don't see the code you quoted. The index zeroing was happening after submesh.indexCount was set, so it was never happening.
Leoss, gah so close. I'll take a look.
Ok, got that fixed too. It was a problem with the same code, it looks like it is right now.
Ah, never mind. I'll look into it when I get to it. I've completely forgotten how this method works. 
Works perfectly now , thanks !