Does anyone know what dictates the draw call order of the Depth Pass?

I'm using the Frame Debugger, and I've noticed that when objects are rendered using the MeshRenderer, the draw call in the depth pass if from front to back. However, when using the SpriteRenderer with a shader which contains a ShadowPass and has a Geometry render queue, the order in which the draw calls occur is quite random.

 

Yes!























I don't, but I'm sure someone must.






Seriously though, generally speaking Unity's draw order during depth passes is inscrutable. There's a lot of hand-wavy behind the scenes stuff to try to reduce the overdraw, the material swaps, and increase batching performance. For something like sprites which may or not be a single batched mesh it may be rendering objects in order that they are within their batch per material, then sorting those by distance ... or not. There have been several threads on the forum on similar topics even for the main forward or deferred passes where some very large object close to the screen gets rendered out of the order people expect. The answers from Unity have always been something along the lines of "no idea, the sorting code is complicated".

 

Thanks for your answer @bgolus. Would you know if there's any way to create the depth texture ourselves instead, and by doing so, have more control over the way things are rendered?
I wonder if that could be achieved with CommandBuffers for example.

 

Certainly. You could setup a render texture and render the objects in the scene manually using DrawMesh / DrawRenderer commands. Some old shadow related assets on the store do this, or at least used to as none of those assets appear to be available anymore. I believe the now dead Sunshine! volumetric sun shafts and soft shadow asset handled their custom shadow map generation this way, though most assets just use a replacement shader which would not afford you the same control. I don't know of anyone who's done this for sprites, but it should work just as well either way.

This kind of level of control is kind of what the Scriptable Render Pipeline excels at. It has the option to use no sorting when rendering and simply render the objects in the order supplied (presumably the order of the culled renderers list, though I don't know for sure).