WebGLTextures: Fix multisampled rendering for non-Quest VR browsers.

[cabanier]

When the WEBGL_multisampled_render_to_texture extension is not available, three.js falls back to using renderbuffers to get support for multisampled rendering.
However, there was a change that forces the renderbuffer to sRGB. This result in a GL error when it tries to copy the MSAA renderbuffer into the WebXR texture.

The fix now correctly flags the getInternalFormat call to not choose sRGBA.

This contribution is funded by Meta

[cabanier]

The title is a bit confusing. Three is currently broken for:

• non-quest browser that support layers (I don't know if any exist)
• quest browsers were the WebXR Layers feature was disabled.
• browsers that run experiences that use the webxr layers polyfill

This error was found by developers that are trying to use the polyfill so their layers code works on other browser.

[Mugen87]

I've tested the PR in more detail on dev and encounter the following problem on dev (tested with Chrome on macOS): When you change the render target's encoding in webgl2_multisampled_renderbuffers to THREE.sRGBEncoding, the right side of the example is not rendered anymore and the following is logged.

GL_INVALID_OPERATION: Attempt to blit from a multisampled framebuffer and the bounds or format of the color buffer don't match with the draw framebuffer.

The render target creation is just changed from

three.js/examples/webgl2_multisampled_renderbuffers.html

Line 131 in 68dacce

const renderTarget = new THREE.WebGLRenderTarget( size.width, size.height, { samples: 4 } );

to

const renderTarget = new THREE.WebGLRenderTarget( size.width, size.height, { samples: 4, encoding: THREE.sRGBEncoding } );

This is a regression since having multisampled sRGB render targets should work as before.

[Mugen87]

Maybe we need a separate code path (or additional checks) to differentiate between WebXR and non-WebXR?

[Mugen87]

I've reverted the PR for now since r145 will be released this Wednesday. Planing this change for r146 so it's more time to test and verify.

[cabanier]

Maybe we need a separate code path (or additional checks) to differentiate between WebXR and non-WebXR?

I'm looking at this code for depth buffers and it seems there is a lot of confusion in this area.
I agree that we might need different code paths.

[cabanier]

@Mugen87 I special cased WebXR and created #24698