This is a known bug with Unity when your MeshRenderer has more than one material. Sorting breaks when it tries its best to batch materials.
It's been several versions and they still haven't fixed this.

But you have two options as a workaround:
Option a. Make sure your skeleton uses only one texture and material.
Option b. Add a Sorting Group component to each Spine GameObject.

Pharan escribió

This is a known bug with Unity when your MeshRenderer has more than one material. Sorting breaks when it tries its best to batch materials.
It's been several versions and they still haven't fixed this.

But you have two options as a workaround:
Option a. Make sure your skeleton uses only one texture and material.
Option b. Add a Sorting Group component to each Spine GameObject.

I did not know about sorting groups! Very awesome. Thanks @Pharan!

Can anyone explain in a bit more detail how Option b should be carried out? I believe I'm facing the issue described here and I've endeavoured to fix it by using Sorting Groups on all the Spine game objects in my scene. Each object has a distinct order in layer value in its Sorting Group component. And still, in Unity's scene view, I get flickering skeletons when I moved the camera around. Thanks for everyone's help in the thread so far, from what I've seen of these forums so far this a very helpful community.

Are you using LWRP? We have a bug open that sounds like the flicker you experience.

We are using LWRP, yes. I'll try seeing if I can switch to the standard render pipeline and see if anything shakes out. Thanks.

EDIT:

Yeah that seems to stop the flickering. Some more details in case it helps you guys fix the bug:

• The flickering did not occur in the Editor's Game View while in Play Mode.

• The draw order did have an issue in Android builds (and perhaps other builds, untested), but it wouldn't flicker, it would stay statically drawn in the wrong order. This has also been switched by ditching LWRP.

Is there any expectation of when this bug will be resolved? Thanks.

Sorry for the trouble and thanks for the info! This bugfix is scheduled with high priority and will be fixed in the next few days.

Excellent, thanks. Is there somewhere I can subscribe to updates on its status so that I don't have to keep pestering you here?

You can find the related issue on GitHub at [unity] Mix and Match Equip example submesh draw order problem · #1486

This issue has been fixed (via a Fix Draw Order parameter that can now be enabled) and new unitypackages are available for download.

Now providing additional Fix Draw Order parameter at SkeletonRenderer, defaults to disabled (previous behaviour). See spine-unity Runtime Documentation: Setting Advanced Parameters.

Applies only when 3+ submeshes are used (2+ materials with alternating order, e.g. "A B A").
If true, MaterialPropertyBlocks are assigned at each material to prevent aggressive batching of submeshes by e.g. the LWRP renderer, leading to incorrect draw order (e.g. "A1 B A2" changed to "A1A2 B"). You can leave this parameter disabled when everything is drawn correctly to save the additional performance cost.

Thanks for reporting!

Excellent, thanks a bunch guys. I've never had a support issue go so smoothly

Thanks for the kind words, glad it could be resolved rather quickly.

Harald escribió

This issue has been fixed (via a Fix Draw Order parameter that can now be enabled) and new unitypackages are available for download.

Now providing additional Fix Draw Order parameter at SkeletonRenderer, defaults to disabled (previous behaviour). See http://esotericsoftware.com/spine-unity#Setting-Advanced-Parameters.

Applies only when 3+ submeshes are used (2+ materials with alternating order, e.g. "A B A").
If true, MaterialPropertyBlocks are assigned at each material to prevent aggressive batching of submeshes by e.g. the LWRP renderer, leading to incorrect draw order (e.g. "A1 B A2" changed to "A1A2 B"). You can leave this parameter disabled when everything is drawn correctly to save the additional performance cost.

Thanks for reporting!

We are just moving to LWRP and we found this issue.
The problem is: we have updated Spine Runtime to the latest version available (spine-unity 3.8, updated 2019-10-31), but that fix only seem to work when we go to Play Mode from an in-editor scene. It's not working on builds and neither when we change scenes from our initial game scene.
We are using Custom Materials for certain Skeleton slots.

Running standalone scene on Unity editor

Running scene on Unity editor from initial game scene

Edit:
Unity 2019.2.11f1
Lightweight RP v6.9.2

We are sorry to hear that.

Could you send us a minimal reproduction project where the problem still occurs? You can send a zip file to contact@esotericsoftware.com. Then we can have a look at it.

Sure, I'll send it to you as soon as possible.

After many test, I just noticed that disabling GPU Instancing at the material (Meio-Menino_frente_Rig01_Material) solved the problem on my PC. Could you please test if this resolves it on your end as well?

New unitypackages have just been uploaded where the Advanced - Fix Draw Order parameter automatically disables GPU instancing.
You can download it here as usual:
Spine Unity Download