The issues you're experiencing with depth occlusion in Unity when using Spine skeletons are likely due to the inherent challenges of rendering semi-transparent objects and the way Unity handles depth sorting. In Unity, transparent objects are typically rendered in a back-to-front order, which can conflict with the Z-buffer's depth sorting, especially when using shaders that write to the depth buffer. This is a common issue with alpha blending, as described in the spine-unity Rendering documentation.

1. Reverse Z-Depth Issue: The reverse relationship you're seeing might be due to the way Unity's transparency sorting works. Unity sorts transparent objects based on their distance from the camera, which can lead to unexpected results if the Z-axis is used for depth sorting. This is compounded by the fact that Spine's rendering order is determined by slot draw order, not Z-depth.

2. Shader Modifications: Your attempts to modify the shader with different ZTest configurations and depth-only passes are valid approaches. However, the fundamental issue is that depth writing with transparency is inherently problematic. The spine-unity Rendering documentation suggests using alpha blending without depth writing for clean semi-transparent transitions.

3. SkeletonMecanim and Z-Ordering: The SkeletonMecanim component itself does not inherently reverse Z-ordering. The issue is more likely related to how Unity handles transparency and depth sorting. You might consider using Unity's SortingGroup component or adjusting the Advanced - Z-Spacing setting to help manage draw order.

4. Performance Concerns: Using complex shaders with multiple passes can impact performance, especially on lower-end devices. Simplifying the shader and avoiding unnecessary depth writes can help maintain performance.

5. Elegant Solution: A more elegant solution might involve using Unity's built-in sorting layers and order in layer settings to manage draw order, combined with careful management of transparency and depth writing in your shaders. You could also explore using a custom component like your SpineZOrderCorrector to adjust draw order dynamically.

In summary, achieving correct occlusion with transparency in Unity requires careful management of draw order and shader settings. Using Unity's sorting layers and avoiding depth writes in transparent shaders can help achieve the desired results.

suanLoBeach Thanks for the detailed explanation. However, it would be most helpful for us to advise you if you could provide us with a minimal Unity project that can reproduce the problem, not just text and screenshots, so could you please create a minimal Unity project and email it to us?: contact@esotericsoftware.com

Below are the required files:

• Assets/
• Packages/
• ProjectSettings/

Excluded Files (To keep the project size minimal, please do not include the following):

• Library/, Logs/, Temp/, obj/
• Builds/
• .git/

Create a new folder and copy only the required files and folders mentioned above, then compress the folder into a .zip or .rar file.

Also, please include the URL of this forum thread in the email so we know the context. Then we can take a look at what's wrong. Thanks for your cooperation!

@suanLoBeach Unfortunately we have not received any email by you. Did you send it to contact@esotericsoftware.com?

suanLoBeach When setting objects closer to the camera as "background" and objects further from camera as "foreground", the occlusion works correctly
This is counter-intuitive and conflicts with the standard Unity rendering pipeline

The SkeletonMecanim component just fills a MeshRenderer's mesh with triangles, in proper back to front order for transparent rendering. The provided spine-shaders also do not magically invert the draw order behind the scene, they use standard Unity render queues, it's all a shader can do. If you modify the shader, you might need to adjust the Render Queue accordingly. SortingOrder in the SkeletonMecanim Inspector is just exposing the MeshRenderer.sortingLayerID (m_SortingLayerID), as the tooltip also shows. If you think that SortingOrder works incorrectly, please file a bug over at Unity, as this feature is not provided by us.

If you are seeing incorrect sorting, your custom shader modifications or other sorting related setup is not doing what you want it to do.

Note that you are repeatedly asking general transparency rendering related questions here on the Spine forum, which are unrelated to Spine and the spine-unity. Normally you would want to ask them on the Unity forums instead:
https://discussions.unity.com/

suanLoBeach I've made multiple modifications to the Spine-Skeleton_custom.shader
Attempted various ZTest configurations (LEqual, GEqual, Less, Greater)
Implemented Z-axis inversion in vertex shaders
Added alpha feathering and threshold effects
Created depth-only passes and simplified the shader
Current State:

The shader now correctly renders with alpha feathering
Depth interactions are still working incorrectly without manually reversing the foreground/background assignments

Please note that you need to get familiar with how rendering, render queues (transparent vs opaque sorting), the z-buffer, ztesting, and so on works in Unity and in general. Trying all different kinds of shader configurations randomly will never lead to the desired effect. You need to understand what you are doing. Please note that this forum is dedicated to Spine and Spine runtimes like the spine-unity runtime.

Unity documentation on rendering and render order:
https://docs.unity3d.com/6000.0/Documentation/Manual/rendering-and-post-processing.html
https://docs.unity3d.com/6000.0/Documentation/Manual/built-in-rendering-order.html

suanLoBeach Created a SpineZOrderCorrector component as a potential solution

What does this component do?
In general your problem is independent of spine-unity components, it is due to your custom shader or sorting layer settings.

suanLoBeach What's causing this reverse relationship between Spine's foreground/background settings and actual Z-depth?
Is there a way to fix this at the shader level without needing a custom component?

Yes.

I saw that you've created a video of your shader code instead of sharing the code as text. Apart from wasting a lot of bandwidth (consider the environment before doing things like this), sharing code as screenshot images is already bad for reading and prevents testing it, but creating a video is even worse and makes it terrible to review. If you want us to look at your code, please always share it in text form. Either enclose it in triple-backticks, or upload the file as attachment to a forum posting.

@suanLoBeach I just checked again, unfortunatley nothing arrived, also not in spam, and search did also not find anything related. Likely it has been blocked for other reasons. You could upload the project somewhere and share a link to the project, either sharing the link at a forum posting or send it by email (best from another email address) and hope that it gets through.

Thanks for your understanding and for your apology.

suanLoBeach The lady asked me to provide a project. Does this mean a Unity project? My understanding is a complete Unity project, so I dare not delete the part that Unity automatically creates, because I am worried that I may not be able to reproduce the problem.

It is important to provide a Unity project which contains no thirdparty assets or otherwise unrelated non-Spine packages. If you can only reproduce the issue with a certain thirdparty asset, then the problem must be with this asset, not with spine-unity. So you need to start from a fresh clean new Unity project and add only the spine-unity runtime and your custom shader and your sorting setup. If you can't reproduce the problem like this, you've just discovered that it must be some special setting or asset which is causing the troubles.

Side note: you should also never start from a template project, this is also not a clean minimal starting point. It has to be a new clean Unity project.

For size and download reasons, certain directories that Misaki mentioned shall be excluded, since they are generated upon import anyway.