Sprite attachments shader overlapping

crdmrn

So, I made a spine model and i imported it into Unity and everything went fine.
Since I needed to do some lighting and the SkeletonLit shader is way less luminous than the standard UnityDiffuse one, I wrote my own shader to make Spine models and background shaders match.
The problem is, that on some junctions (and I emphasize some, as it happens only on 2 or three junctions, of all the various skins of the character) there is a weird shader overlapping happening and I don't know how it comes up and what to do to solve it. It looks like, while all the other attachments are on different z-indexes, those two are on the same one, which makes no sense as I didn't touch anything on import, and on the spine project (as far as I know you can't have two attachments on the same draw order layer) everything is set up correctly.

Here is the shader code and below I attached a screenshot of the problem I get (one pic of the error, and one of all the other correct junctions).

Shader "EvilSystem/SpineSkeletonDiffuse"
{
   Properties
   {
      [PerRendererData] _MainTex ("Sprite Texture", 2D) = "white" {}
      _Color ("Tint", Color) = (1,1,1,1)
      _Cutoff ("Shadow alpha cutoff", Range(0,1)) = 0.1
      [MaterialToggle] PixelSnap ("Pixel snap", Float) = 0
   }

   SubShader
   {
      Tags { "Queue"="Transparent" "IgnoreProjector"="True" "RenderType"="Transparent" }
      LOD 100

  Cull Off
  //Lighting Off
  ZWrite Off
  //ZTest LEqual
  Blend One OneMinusSrcAlpha

  Pass {
     Tags { "LightMode"="Vertex" }
     ColorMaterial AmbientAndDiffuse
     Lighting On
     SetTexture [_MainTex] {
        Combine texture * primary DOUBLE, texture * primary
     }
  }

  CGPROGRAM
  #pragma surface surf Lambert vertex:vert nofog keepalpha
  #pragma multi_compile _ PIXELSNAP_ON
  #pragma multi_compile _ ETC1_EXTERNAL_ALPHA

  uniform sampler2D _MainTex;
  fixed4 _Color;
  uniform fixed _Cutoff;

  struct Input
  {
     float2 uv_MainTex;
     fixed4 color;
  };
  
  void vert (inout appdata_full v, out Input o)
  {
     #if defined(PIXELSNAP_ON)
     v.vertex = UnityPixelSnap (v.vertex);
     #endif
     
     UNITY_INITIALIZE_OUTPUT(Input, o);
     o.color = v.color * _Color;
  }

  fixed4 SampleSpriteTexture (float2 uv)
  {
     fixed4 color = tex2D (_MainTex, uv);
     clip(color.a - _Cutoff);
     return color;
  }

  void surf (Input IN, inout SurfaceOutput o)
  {
     fixed4 c = SampleSpriteTexture (IN.uv_MainTex) * IN.color;
     o.Albedo = c.rgb;
     o.Alpha = c.a;
  }
  ENDCG
   }

   // 1 texture stage GPUs
   SubShader {
      Tags { "Queue"="Transparent" "IgnoreProjector"="True" "RenderType"="Transparent" }
      LOD 100

  Cull Off
  ZWrite Off
  Blend One OneMinusSrcAlpha

  Pass {
     Tags { "LightMode"="Vertex" }
     ColorMaterial AmbientAndDiffuse
     Lighting On
     SetTexture [_MainTex] {
        Combine texture * primary DOUBLE, texture * primary
     }
  }
   }
}

nimbling

Have a look at what's going on here
Opacity Fade Question

crdmrn

What does it have to do with it?
My problem is different, I have only a couple of attachments generating overlaps, when all the others are fine.
All the materials used by the spine skeleton are using the same shader, so I can't imagine where the problem is coming from.

Pharan

This isn't specific to Spine. If you use that shader on Unity Sprites, you'll get the same result.

I think you'll find this topic (and shader) helpful. Sprite Shaders for Unity
Make sure you read the first post.

crdmrn

I'm sorry but no, giving that shader to normal sprites will not cause that overlapping thing, as you can see in the image attached in this post. The two squares have the same z axis and the same layer order, and they still don't have that weird multiply or add effect.

Also, in the two screenshots I atteched in my first post, you can clearly see that the overlap happenso only on some junctions (the hand that doesn't have it has a junction on the wrist as well, but it doesn't generate weird overlaps).

Looking at the atlases, it might be that it happens only when two attachments are on the same atlas, though I don't know why that should happen, and in that case I think it does have something to do with how spine manages materials and atlases.

Pharan

Yes, it does.
Loading Image

The point here is that surface shader lighting uses extra passes to add lights, so without correct information from the depth buffer, the light pass doesn't know which pixels to skip over.
Please see the topic I linked where ToddRivers mentions "Pixel Lighting". That's what surface shaders use.

If your shader uses the depth buffer, add a tiny bit of z-spacing on the Spine Skeleton renderer under the Advanced foldout.

crdmrn

But then, why does that happen only on certain junctions and not on others, when all of them are overlapping and have the same shader? :S

And also, I actually have a Skeleton Animation component attached, which also is a Skeleton Render, but in order to add "a tiny bit of Z-spacing" I would need to add slot separators...

Pharan

Open the Advanced foldout. See the Z Spacing slider.

I don't know why it only happens on some joints, but I do highly recommend you try ToddRivers shader and make the comparisons if you have to.

crdmrn

Changing the Z-spacing doesn't affect the overlapping joints, it affects all the rest... is there any possibility that Spine exported those joints in a way that they are always on the same layer order? ToddRivers' shaders are way too complicated for what I need, having a look at that was the first thing I did when I started looking for a more luminous sprite renderer.

Pharan

His shader acts like the Unity Standard shader in that it's only as complicated as you make it. And at runtime, it doesn't compile features you don't use. The inspector just looks a bit scary because it shows everything. But just don't use the stuff you don't know and it'll work fine. See the VertexLit sample.

In Spine, there is no way for two things to be in "the same layer order"; Slots don't store a "layer number". All the slots in the skeleton are just placed in a list and iterated one by one. Animating the draw order changes the slot order in that list. That's the only order that Spine deals with.

crdmrn

Yes, I know, but let's put it like this: I have that shader that only generates the add effect when two sprite renderers are on the same z-index and on the same layer order. My spine character has many joints and only one of them has that problem, they all use the same shader and changing the z-spacing in the skeleton renderer also doesn't work. Couldn't it be that the error is somewhere else?

20 Oct 2016, 13:38

After importing other characters with less complicated atlases I found out that only the attachments that are on the same atlas file (working on an iOS game I'm exporting square 1024x1024 atlases so characters might have more than one) generate this problem... could it have anything to do with how the meshes and materials are handled by Spine runtime in Unity? And in that case, would you have any suggestion on how to change the shader accordingly?