WebGLRenderer: Add internal MSAA render target with centralized tonemapping

[mrdoob]

Related issue: #32433 #32449

Description

This PR renders scenes to an internal MSAA render target and applies tonemapping, colorspace conversion, and dithering in a single final pass.

The tonemapping/colorspace/dithering includes have been removed from material shaders since they're now handled centrally by WebGLComposite.

Before	After

The watch glass HDR is fixed but the text becomes less readable. I still don't understand why...

Before	After

For testing:
https://raw.githack.com/mrdoob/three.js/webgl-internal-msaa-rt/examples/index.html

[github-actions]

📦 Bundle size

Full ESM build, minified and gzipped.

	Before	After	Diff
WebGL	350.28 83	350.9 83.46	+617 B +459 B
WebGPU	616.03 171	616.03 171	+0 B +0 B
WebGPU Nodes	614.64 170.74	614.64 170.74	+0 B +0 B

🌳 Bundle size after tree-shaking

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

	Before	After	Diff
WebGL	482.33 117.81	482.92 118.28	+586 B +465 B
WebGPU	687.42 186.76	687.42 186.76	+0 B +0 B
WebGPU Nodes	637.26 173.94	637.26 173.94	+0 B +0 B

[mrdoob]

One downside of this approach is that we can no longer render specific materials (like MeshNormalMaterial) without tonemapping.

Edit:
Unless we "detonemap" them... 👀

[Mugen87]

To clarify, this PR would align WebGLRenderer to WebGPURenderer and remove the inline tone mapping and color space conversion.

I suspect this change will produce quite some rejection in the community since there are still serious concerns about the performance of WebGPURenderer on mobile and XR devices. The double pass approach is quite noticeable performance-wise and we haven't finally dismissed a inline approach for performance reasons in WebGPURenderer.

I suggest you make this optional for WebGLRenderer and keep the inline approach as a default. There are definitely users that don't want such a system in WebGLRenderer right now.

/cc @donmccurdy

[mrdoob]

This is only a test PR to see how the renders are supposed to look like.
And also to see how the code would look like.

[Mugen87]

BTW: An optional setup with WebGLRenderer is via EffectComposer. A setup of a render pass + output psass should produce similar results.

[Mugen87]

This is only a test PR to see how the renders are supposed to look like. And also to see how the code would look like.

Ah I understand. I'm all in for aligning the renderers. But given the deep character of this change, we should make clear to retain the inline approach in WebGLRenderer for backwards-compatibility reasons. And even so if the performance differences between one and two passes turn out smaller than expected.

Here is a latest issue about that topic: #32273