UILabel often drawing under hard clip sprites

[Matthias]

Hi!

I have the issue where I have UILabels being drawn under UISprites which use the transparent hard clip material, no matter how big I make the Z offset or Depth value. I can't figure out why and it almost seems to have something to do with where the UILabel is in the GameObject hierarchy, but I'm not sure.
Is there a way to ensure UILabels are drawn on top of sprites? Perhaps could I somehow force the UILabels to use the overlay shader?

Thanks,
Matthias

[ArenMook]

You can create a copy of the Unlit / Transparent Colored shader and change its render queue to "Transparent+1" to make it always draw after all transparent objects.

Keep in mind the Z is opposite of depth. You make depth higher to bring something forward, but you bring Z back (negative).

[Matthias]

I had to step back as I realized that I have a similar issue with sprites.

It looks like as soon I am in 3D, the camera angle affects the order the sprites are drawn. So even if the back sprite has a Z of 0 and depth of 0 and the front sprite has Z -1 and depth 1, it could be drawn behind the back sprite if the camera is only a few degrees off.

How can I take the camera angle out of the equation and have a consistent result, no matter in what direction I look at the plane?
What is the mathematical relationship between Z and depth when determining the drawing location?
Does the depth value affect the location of the actual drawn Sprite geometry in 3D space?

[ArenMook]

You can't. This is just how Unity works. It always sorts objects back to front based on the distance from the center of the object to the camera's eye point.

[ArenMook]

You only have two choices here. Either use the same atlas, or make your UI 2D.

[ArenMook]

Btw, as I explained on the old forum a while back, consider the following image, with the camera being located at the bottom corner of the triangle.



Green dot is closer than the Red dot, right? It will be drawn first. Now move the green dot in a negative X direction (left), keeping its depth (Z) until it's at the Blue dot's location. Now which one will be drawn first? The depth of Green and Blue dots happens to be the same, but will the Green/Blue dot still be drawn before the Red dot?

The answer is no, it won't be. Red will now be drawn first. Why? The distance from Red to the camera (bottom of the triangle) is shorter than the distance from the Blue dot to the camera.

[Matthias]

  Ok, i get it, makes sense with that image.

So on to the options:

2D: I spent over a week on rewriting the UI to this magazine concept and this is the last hurdle, so I don't want to give up.

Using one Atlas: Do you mean if I use one atlas it would work because all sprites (using the same shader) are actually passed to Unity as a single mesh being drawn at once? If not, why else would that fix the problem?

I can't really use one atlas since I am displaying sprites which are created and modified on the fly. I would have to change the atlas at runtime and since the number of sprites constantly varies, this sounds like a huge pain if possible at all.

RenderQueue: I am thinking the RenderQueue does remain the best option here (I am not concerned about the performance hit). But for some reason it does not work.

Here is my process:
- Instantiate a Prefab that contains a UITexture
- Set the UITexture.material.renderqueue
Doesn't work

So I figure I need to instantiate the material so I do this:

1.             GameObject clone  = (GameObject)Instantiate( prefab );
2.             UITexture texture = clone.GetComponentInChildren<UITexture>();
3.  
4.             texture.material = new Material( texture.material );
5.             texture.material.renderQueue = customrenderqueuevalue;
6.  

Not working, textures with higher render queue values still appear behind other with lower one. Am I doing this wrong?
Is this logically wrong? Should I check into a mental institution instead?

[ArenMook]

Render queue is specified inside the shader. From Unity's doc:

By default materials use render queue of the shader it uses. You can override the render queue used using this variable. Note that once render queue is set on the material, it stays at that value, even if shader is later changed to be different.

This means that you need a new material for every single object you want to change render queue on.

One atlas does indeed result in a single draw call (provided you used only one panel per window), which effectively eliminates this issue. You can create dynamic atlases at run-time by taking advantage of render textures.

[ArenMook]

P.S. I've never used 'renderQueue' material option, so I don't know if it works. I saw that you instantiate a new material there cloning an existing material, so it theoretically should work, but I don't know enough to tell you why it doesn't.

[Matthias]

Ok, I will look into how to make a dynamic atlas. I think that would be the nicest and hack free option there is.

I used the render queue successfully on transparent 3D objects with default shaders, so I know it works. Might be something specific to the shaders here or the way materials get instantiated in this case.

Thanks for the input.