When we talk about "Z Efficiency", is it for depth or shadow pass?

[bitinn]

DrawMeshInstanced API doc mentioned the batch won’t sorted for Z efficiency.

I am wondering if it means:

• overwriting Z buffer (basically instances aren’t sorted front-to-back, so z will be overwritten unecessarily?)
• or something related to HiZ (related to shadow mapping, to be honest, I don’t understand how it would be affected…)

This issue matters to me because:

• Imagine a 3d top-down game, if I batch render objects from top layer to bottom layer (so essentially front-to-back), did I overcome this overwriting Z buffer problem?
• Do things like Early-Z Rejection and Hierarchical Z happens automatically on the GPU, regardless of how we call DrawMeshInstanced?

I think these are 2 different concepts of Z buffer:

1. a very high-level understanding of depth buffer.
2. the actual z buffer in the graphic pipeline, which is much more complex and varies by GPU.

I am not sure which one “Z efficiency” refers to…

[bitinn]

TL;DR, from what I can tell, what actually happens in Unity LWRP is:

• do a z pre pass from camera
• do a shadow pass from light
• do a collect pass to get actual screen space shadow
• when rendering opaque, sample the shadow

My question is, when Unity doc talks about “Z Efficiency”, does it mean the pre-pass? or the shadow pass?

Or put it more bluntly, how do you call DrawMeshInstanced that’s more “Z efficiency”?

Also, in a forward rendering settings, how does the pre-pass help depth rejection of fragment shaders (this article is for HDRP but I think the idea applies on LWRP too?)

[bgolus]

@bitinn

overwriting Z buffer (basically instances aren’t sorted front-to-back, so z will be overwritten unecessarily?)

This. If you need or want instances to be sorted, you have to do this to the arrays you pass in manually.

@bitinn

1. a very high-level understanding of depth buffer.
2. the actual z buffer in the graphic pipeline, which is much more complex and varies by GPU.

Irrelevant here. It’s just talking about sorting front to back for opaque objects. Differences between different z buffer representations aren’t really that important. That’s more important for things like alpha testing, fragment shader depth offsets, and depth resolves.

@bitinn

(this article is for HDRP but I think the idea applies on LWRP too?)

It does not. It could, but it does not.

[bitinn]

@bgolus

This. If you need or want instances to be sorted, you have to do this to the arrays you pass in manually.

Irrelevant here. It’s just talking about sorting front to back for opaque objects. Differences between different z buffer representations aren’t really that important. That’s more important for things like alpha testing, fragment shader depth offsets, and depth resolves.

It does not. It could, but it does not.

Thx a lot, so in short, I should just try to sort the instances from front-to-back (in term of the camera view space) when rendering, and that in itself should satisfy the “z efficient sorting” which DrawMesh automatically do (and DrawMeshInstanced doesn’t). True?

[bgolus]

Correct.