Since I switched over to URP for my turn-based tactics game, I’ve experienced some strange draw order issues relating to meshes.
For instance: I have numerous tiles (plane meshes) that appear just above the ground when taking an action with a character, denoting spaces a character can (for e.g.) move to or attack. These tiles, in turn, display text upon mouseover; the text is tied to a different layer so it is always visible in full no matter what might technically be “in front of it” according to the z-order. Since I switched over to URP, the layer ceased to determine draw order for TextMesh objects–however, it works as intended for TextMeshPro objects.
Another example: I have animated 3D banners that I created in Blender and imported to Unity as fbx files. These drape over the top of various menus in-game; or at least, they used to before I switched to URP. Now, however, no matter what I do, they seem to always render behind the menu.
It is probably a render queue issue.
The naming for the render queue property has changed in the inspector. You probably have lesser control over the render queue if you are using the shader provided by URP.
If you are using the default shaders provided by URP, the render queue is now hidden and can only be determined via setting Opaque/Transparent and Priority. The material editor script forces you to do so.
I would suggest you duplicate a copy of the shaders and remove the CustomEditor declaration in the shader for full exposure of the values controllable.
It’s odd, though–the Render Queue property actually appears in the inspector for the banners. It’s just that changing the value in its field fails to make any difference.
There is the part where the RenderPass for Transparents is separate from that of Opaques and occurs after Opaques.
And for Opaques, the rendering is down in a forward direction as compared to the reverse for Transparents.
There is no option in the inspector for such. The sorting is hard-coded into ScriptableRenderers implementation and DrawObjectsPass. It is less of a bug but more of a user-design flaw to prevent unknowing users to shoot themselves in the foot.
For your use-case, you might want to duplicate the DrawObjectsPass and customize it for your own needs.
