Wrong depth buffer is submitted to OpenXR

[Rectus]

Looking at a render with RenderDoc, Open Brush is submitting the wrong depth buffer to the OpenXR runtime. Instead of submitting the actual depth buffer, it is submitting one with only the VR occlusion mask drawn.

It also doesn't use the occlusion mask in the main render pass. Instead it is drawn in a separate render pass onto a copy of the finished frame, which is then discarded.

Open Brush version: 2.1.0 Steam release
OS: Windows 10
VR headset: Valve Index

Rendered depth (scaled range)

Submitted depth

[mikeskydev]

Thanks a lot @Rectus! I think this may be a key part of some issues I was experiencing with passthrough on some platforms.

[Rectus]

I was actually working on passthrough depth occlusion, and got confused why it wasn't working in Open Brush even though it submits depthbuffers.

[mikeskydev]

Ohh that'd be sweet! I'll look at getting this fixed then I'd love to give that a shot.

[mikeskydev]

@Rectus is there an app I can use to see in realtime what unity is submitting to the runtime? how did you produce the image showing the occlusion mask?

[Rectus]

I used RenderDoc to capture the frame. It's a bit tricky to use with VR apps, since it doesn't directly capture the VR frame submission functions. It triggers on submitting the desktop window though, so it should still record all the graphics API calls the VR renderer, any OpenXR API layers, and the runtime does on xrEndFrame.

[mikeskydev]

I've finally had time to investigate this properly:

The issue was coming from RenderWrapper.cs, where an offscreen render texture is created so it can be reused and rescaled for performance when using the video recording tools. I'm not entirely sure why this is breaking our XR pipeline, as it appears the render texture is created properly.

As a stopgap, we keep using the normal camera, but switch to the offscreen render during recording.

This may be magically resolved when we upgrade Unity versions, I've left TODOs to that effect. I'll close this issue and create a new one to track a proper fix.

See #685