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.

suanLoBeach Therefore, I wanted to use ZWrite to make the frontmost object block the transparent objects behind it while remaining transparent to other non-transparent objects

Note that ZWrite alone is not sufficient when the triangles of a Spine Skeleton are rendered back to front (as is needed for normal transparency). If frontmost attachments in your skeleton shall block attachments behind it, you need to render the frontmost first, or ensure that the zbuffer is already set to the frontmost z value. Note that inverting the triangle vertex z position of a Mesh does not change the order in which the triangles are rendered.

You have two options here:

• a ) You need to ensure either by modifying the draw order (Skeleton.DrawOrder) of the skeleton's attachments to the reverse, or modify the source code to reverse draw order in MeshGenerator. This would allow transparency to other objects while occluding triangles in the same Mesh (in the same skeleton).
• b) You can use a depth pre pass as suggested above to render the skeleton to the ZBuffer first and then only draw the front-most object. From your second paragraph, that seems to be what you want. If however you want to blend between multiple semi-transparent skeleton objects normally, you would need to add a SortingGroup component (or perhaps it works also by using different Sorting Layers) to group pass1 and pass2 of the same skeleton together. Otherwise only the top-most skeleton's topmost attachment will "win".

From your text I assume that you want the frontmost attachments of all skeleton objects to block transparent attachments behind them. So a depth-pre pass should do what you need, as described. Note that all depth-pre-passes need to be executed before all normal skeleton passes:

skel1.depthPre
skel2.depthPre
skel3.depthPre

skel1.normal
skel2.normal
skel3.normal

And not

skel1.depthPre
skel1.normal
skel2.depthPre
skel2.normal
skel3.depthPre
skel3.normal

So you should not add e.g. a SortingGroup component then or do anything else that groups render passes of a single object. If you set a Sorting Layer, that should perhaps not affect the grouping, but you should not need Sorting Layer anyway. In any case, test the actual order in which things are drawn with the frame debugger to see if what happens is what you want.

suanLoBeach However, what I really wanted to achieve was for one to completely block the other. I discovered that implementing this effect required a strange combination: Spine Boy (background) needed to be closer to the camera than the raptor (foreground), meaning Spine Boy's Z-axis had to be closer to the camera. This gave me the effect I needed. But obviously, this is incorrect, because Spine Boy is in the background and shouldn't be closer to the camera - it should be further away than the raptor. This is the problem I'm currently facing.

Your desired effect is incorrect ordering, so it's logical that the means seem incorrect. Normally no-one wants transparent objects block transparent objects behind them.

Also another way to change the ordering of objects is to change the render queue of your shader or material. Render Queue Transparent orders your objects back to front and other queues front to back.

Queue                        Typical Shader Type      Sorting Behavior  
Opaque (<= 2500)            Opaque Surfaces         Front-to-Back
AlphaTest (Cutout) (2450)   Cutout Shaders         Front-to-Back  
Transparent (>= 3000)       Blended/Transparent    Back-to-Front (Manual Sorting)  
Overlay (4000+)            UI, Effects            Always on top  

All you should need is a depth pre pass though.

suanLoBeach I'm not skilled with shaders

If you are not yet skilled with what you want to do, you need to learn it. Learn how render pipelines work, what the depth buffer does, etc. Or choose an easier task which you can accomplish with your skills.

suanLoBeach so I'm not sure if this is a Unity issue or a problem with the Spine shader.

This is neither an issue with Unity nor with Spine shaders. You want special behaviour which is considered incorrect rendering. Both Unity and the spine-unity shaders do what they are expected to do.