Spine layer order glitch in WebGL build

CarrotPie

We've been observing a glitch which happens only in webGL builds. Layers somehow forget their order. We use Sorting Group component on our Spine skeletons to group up layers (without it, they keep blinking and constantly changing order...).

This is how it looks in editor (Game view). Pay attention to the big 'King' unit.:

This is how it looks in WebGL build. Same King unit:

Any help/fix would be appreciated. Do we need to change some settings on the Skeleton?

CarrotPie

Harald

Since I'm not familiar with your game, I fail to see the problem in your videos, could you please describe that in more detail? In general, please always describe what you expect to see and what you actually see instead.

CarrotPie

Well, I dunno what is actually happening, so it's difficult to describe... As I said, you have to look at the 'king' unit, to be more exact - his walking right animation.

First video is how it's supposed to look - it correctly displays in Game view inside Unity Editor when the project is run.
Second video is how it actually looks when built in WebGL. Layers of the 'king' unit are all in bad order: his item hides behind the hand, some under-textures pop up to front (thus the color of his belly disappears)..
simply pause the second video at 0.5sec, he's in the pose then.

Both videos are of the same setup, same unit, nothing changed, but one is within editor the other is a build. IMO, it shouldn't change...

Harald

CarrotPie schrieb
Well, I dunno what is actually happening, so it's difficult to describe

We just need to know what you expect to be displayed, not why it is not displayed.

CarrotPie schrieb
his item hides behind the hand, some under-textures pop up to front (thus the color of his belly disappears)..
simply pause the second video at 0.5sec, he's in the pose then.

This is the information that we required, thanks for adding it. Without knowing what exactly you expect to be different, we might pick the wrong things or have to go through a "find the 3 differences" picture puzzle without knowing where in a video it occurs (screenshots are easier to spot the differences in this regard).

Does the king use multiple atlas page textures (multiple materials at your Skeleton GameObject), or just a single one?
Are you using the Universal Render Pipeline? If so, it could be due to too agressive batching. Have you tried enabling the parameter Advanced - Fix draw order at the SkeletonAnimation or SkeletonMecanim component?

CarrotPie

Yeah, sorry for the cryptic intro...
So to follow up:
the king uses two-page textures and it creates total of three material instances:

Tried the Advanced - Fix draw order but it does not seem to affect it.
Tried different materials with appropriate spine exports: Sprite/Default and Spine/Skeleton (with bleed=true and Straight Alpha Texture = True). Both act the same.
Yes we are using URP, though we can switch if needed, it is not required. It just defaulted in our project...

I realised that we are actually using URP for some shader graphs in environment elements... so switching is a no-no ;(

Harald

No worries, thanks for providing the additional info!

CarrotPie schrieb
Tried different materials with appropriate spine exports: Sprite/Default and Spine/Skeleton (with bleed=true and Straight Alpha Texture = True). Both act the same.

As you said you are using URP, are you using a 2D Render or normal 3D workflow?
Which shaders are you using? Are you using Universal Render Pipeline/Spine or Universal Render Pipeline/2D/Spine shaders? Please note that normal non-URP Spine/* shaders are not compatible with URP.

Please see the shader documentation section here:
spine-unity Runtime Documentation: URP Shaders Extension UPM Package

CarrotPie

Thanks for the suggestions.
Yes, we are using URP 2D. Everything is unlit.
I've just tried out many available shaders from Spine package for URP and default ones, one by one (takes time, because it needs to be built for reach test).
However every shader acts the same, making me thing this it not a problem with the shader... again - they all look fine within the editor.
Now I've just recognized that not only 'right' walk animation is bugged like this, but also 'up'. Moreover, their attachments keep changing their order within other animations (weapon covering hand in 'idle' / behind the hand in 'walk' anims) as well.

Universal Render Pipeline/2D/Spine/Sprite with Unlit and Standard Alpha
Universal Render Pipeline/Spine/Skeleton - doesn't show at all
Universal Render Pipeline/Spine/Sprite with Unlit and Standard Alpha

Don't really know what to do at this point..

Below is a capture from a build with Universal Render Pipeline/2D/Spine/Sprite shader:

00:13 king unit starts animating 'walk up' but layers are in wrong order and it looks as if it walks right, all broken..
00:27 you can see the weapon blimp back to correct layer order after walk animation ended.
00:10 king unit is walking right, but weapon is behind him and some belly layer can be also seen in front, covering what actually should be seen..

Harald

Thanks for following up, sorry to hear that it didn't help. Could you please send us a minimal Unity project that still shows the error, as a zip package to contact@esotericsoftware.com (mentioning the url of this forum thread for reference please)? Then we can have a look at it.

CarrotPie

Sure. I will have to build a new specific project with the asset in question for that, so guess I'll plan to do that during the weekend.

Update:
Our animator had this idea, to check animation mixes inside Spine and she found out, that the problematic animations, which seem that have their layers wrong, look like a couple anims mixed together (right+up). This could mean, that perhaps in WebGL build, the animator incorrectly runs the blend tree? I will first test if variables passed to it are correct though.

Harald

Thanks for the additional info! I would rather guess that it's a timing (and switching weights between animations instead of restarting animations) issue that surfaces on the WebGL build that did not occor in the Unity Editor, rather than the Animator component running incorrectly.

If you say that your animations modify the draworder, it would make perfect sense that such an issue can occur: Let's say you set layer order only on frame 1, and in the game you switch blend weights of the BlendTree node multiple times between animation up and down animations (within the duration of a single animation loop), then this draworder key will not be executed again (since it has already been applied in this loop). Please let me know if this explanation makes sense to you.

The solution would then be to either
a) not use a BlendTree node and instead play directional animations from the start all the time (via separate nodes for each direction), or
b) set multiple draworder keys instead of one.

CarrotPie

Your explanation makes sense, in a way.
However, that does not explain why it behaves differently in editor and in build.

I doubt this is the case in our project though, reason is simple: in between walk animations there is always at least a single 'transition' animation, which turns unit clockwise or c-clock (unless it's the same animation as was played before).

I think (though not sure) option "Ordered Interruption" means they are not kept playing in the background, but instead interrupted. As far as I've seen, each time a new animation plays, it does not continue, but instead restarts from the beginning.

Also, I've confirmed that actual vectors which I supply for the blend tree are correct precise values:

Harald

Your described situation seems very strange indeed. Thanks for sending the reproduction package, we received everything and could reproduce the issue. We will let you know once we've figured out what's going wrong.

After digging a bit deeper into the provided source code, I unfortunately noticed that the provided project is not really minimal, but instead contains too much game logic, animation triggering abstraction layers and so on. This prevents it from being analyzed efficiently.Could you please strip the project down to a single script that only issues the necessary Mecanim triggers to make the problem occur?

Thanks for sending the shrinked reproduction project, we received everything!

We just fixed the isse (it was a numerical problem, only surfacing on WebGL), new spine-unity 3.8 and 4.0-beta unitypackage are available for download here as usual:
Spine Unity Download
Thanks again for reporting!

CarrotPie

Thank you for resolving the issue. We've tested and it seems the issue if fixed. Thank you!

Harald

Very glad to hear, thanks for getting back to us!