WebGLRenderer: Discard depth after rendering to transmissionRenderTarget

[mrxz]

Related issue: #28078

Description
Only the colour output of the transmission pass is needed, meaning the depth buffer data can be discarded at the end of the pass.

This PR sets the __ignoreDepthValues on the transmissionRenderTarget, ensuring the depth buffer doesn't get resolved. Additionally it adds the relevant logic to invalidate the depth attachment of the framebuffer in case the WEBGL_multisampled_render_to_texture extension is used, as previously this had no effect.

Note: the diff appears quite large due to an increase in indentation level. View the diff with 'hide whitespace' (https://github.com/mrdoob/three.js/pull/28132/files?w=1) to get a clearer view of the actual change.

This contribution is funded by Fern Solutions

[github-actions]

📦 Bundle size

Full ESM build, minified and gzipped.

Filesize dev	Filesize PR	Diff
673.4 kB (166.9 kB)	673.6 kB (166.9 kB)	+293 B

🌳 Bundle size after tree-shaking

Minimal build including a renderer, camera, empty scene, and dependencies.

Filesize dev	Filesize PR	Diff
453.1 kB (109.4 kB)	453.3 kB (109.5 kB)	+294 B

[Mugen87]

@mrxz I did some integration testing and noticed one thing: On my macMini with Chrome it seems the reflections in the mirror produce a flickering/flash approx. each second. This did not happen with my Quest 2.

With this PR: webxr_vr_sandbox
Without: webxr_vr_sandbox

Are you able to reproduce the flicker on your system?

[Mugen87]

Here is a video demonstrating the issue:

video.mov

The glitch does not happen on a Pixel 4a and a Windows device with Nvidia card, btw. Both tested with latest Chrome.

It's also interesting that on the macMini, the glitch only happens with Chrome (and Chrome Canary) but not with Safari of Firefox.

Here is the Chrome GPU report: about-gpu-2024-04-14T09-43-03-471Z.txt

[mrxz]

Are you able to reproduce the flicker on your system?

@Mugen87 Can't reproduce it on my end on desktop (Linux using either FF or Chrome), not on Quest 3, and not on an Android phone (Sony). Not quite sure what would could be causing this.

[Mugen87]

I do some more testing and maybe file a bug at the Chromium bug tracker tomorrow. Right now, the issue seems exclusive to Apple hardware with M processors and Chrome.

In the meanwhile, let's keep the PR in the core. Scenes with transmissive objects but without a reflector are not affected so it's not that severe.

[Mugen87]

I remember I have already filed a bug for a related issue at the Chromium bug tracker: https://issues.chromium.org/issues/40217835

We had issues with gl.invalidateFramebuffer() in the past, see #22967 (comment). That's why we have stopped using it by default and only in Quest browser, see #23692.

The main reason with gl.invalidateFramebuffer() is the behavior is implementation dependent so there might be side effects on certain platforms. I'll try to fix the glitch on our side with a PR.