CustomPass RenderDepthFromCamera

In HDRP 8.2 I was using a custom pass to render a depth map from a 2nd, inactive camera (which is at a different location than the main cam). Unfortunately this no longer works in 10.2.2 (Unity 2020.2.0f1). The docs tell me that it's apparently no longer possible in 10.2 to set global shader variables on the command buffer, instead new methods like "RenderDepthFromCamera()" were added.

I've tried using this new method and it seems to work, but it looks like the 2nd camera is using the same culling results as my main camera (so the 2nd camera is unable to see objects culled by the main camera) :hushed:

I'm pretty sure I've missed something :sweat_smile: I can't find a way to pass custom culling results to the RenderDepthFromCamera() method... what's the proper way to render depth-only from a different camera in 10.2? I appreciate any help :)

Culling like occlusion/frustum culling? Theres a checkbox on the camera component wether or not it should use (influence?) the occlusion culling

Maybe this helps?

Thanks @John_Leorid but I'm afraid that's not the solution. I'm not using occlusion culling, I'm talking about frustum culling: In 8.2 it was possible to pass the camera matrices (of the 2nd cam) via global variables to the command buffer (within a custom pass). In 10.2 this doesn't seem to be possible anymore due to the introduction of the constant buffer API.

Instead new methods like RenderDepthFromCamera() were added, but as described above, it seems to be using the culling results of the main cam (so if something is culled by the main cam, it doesn't get rendered by the 2nd cam).

Under the hood this method seems to be just updating the ShaderVariablesGlobal struct, but the required methods are internal and therefore inaccessible.

What exact game mechanic are you talking about?
I had a monitor screen, with a render texture from another camera and because objects would get culled / LODd, I just disabled DynamicOccludee & StaticOccludee (and LODs) on the GameObjects in the second camera view - so they are always rendered and frustum/occlusion culling didn't affect these GameObjects.

Another solution might be, to have your second camera not inactive? enabling it for one frame, writing to a custom (depht)buffer and then refering to this one?

I need a depth texture from a different view position for handling collision detection on the GPU.

I’m using a procedural scene, so there is no occlusion data available. This issue is solely caused by frustum culling. Having an active 2nd camera has too much overhead unfortunately.

However, I’ve found the “solution” in the meantime: Apparently the only way to change culling results is via reflection. I’ve found this extremely helpful repository which does exactly what I was looking for:

Thanks @antoinel_unity for this repository! :slight_smile:

Still a pity that reflection is the only way now to override the culling results (in fact the biggest issue is that we now have limited control over rendering from a different camera since 2020.2). Are there any plans for HDRP to change that?

//Edit: In fact there are still some limitations when using IL2CPP, since IL2CPP does not support TypedReferences :face_with_spiral_eyes: It works though by boxing the CustomPassContext struct manually, but a proper, public API would be so much better!


Yeah, that’s something that we didn’t think about while adding the new API, and when we found our this issue it was too late to push it for HDRP 10 (2020.2) because it’s a breaking change, sorry bout that :confused:

So the fix will come with HDRP 11, as you can see here: the fix is already in master.

I guess you say that because of the CBUFFER changes we made that prevent any built-in HDRP properties to be overwritten in shaders (like camera matrices for example?)

If that’s the case would the OverrideCameraRendering API help? currently, it’s internal but this one can safely be moved to public now.

1 Like

Thank you so much for your reply @antoinel_unity :) It's reassuring to know that this will change in HDRP 11.

About the CBUFFER changes: Yes indeed, this is basically what I was referring to. Making OverrideCameraRendering public would be definitely a step in the right direction, however, it seems that some things are still out of our control (e.g. the aspect ratio, which seems to be always using the main camera?)...
Tbh, a perfect solution would be if the ShaderVariablesGlobal struct would be accessible :smile: The ConstantBuffer is already public, so we could push our own values this way.

If the ShaderVariablesGlobal struct was public, you could maybe also enable us to get a ref to the m_ShaderVariablesGlobalCB struct in HDRenderPipeline.
To complete the whole thing, the HDCamera.UpdateShaderVariablesGlobalCB() method could also become public.