WebGPURenderer: Introduce CanvasRenderTarget

[sunag]

Closes #27628

Description

@aardgoose did a great job on PR #27628; this PR is a reinterpretation with a focus on simplification given the renderer’s current times.

With CanvasRenderTarget it’s possible to use multiple canvases sharing existing resources—such as the cache—from the same Renderer. Since the previous process, like webgpu_multiple_elements, can bring other difficulties—because it is a whole canvas on the screen rendering only the scissor—or creating a new Renderer with a new canvas does not reuse the previous renderer’s caches, this feature becomes the most recommended for this application, given that the focus is only the WebGPU backend; at least in this PR it will be used exclusively for this backend.

Usage

// -- setup --
const canvas = document.querySelector( '#mycanvas'  );
const canvasRenderTarget  = new THREE.CanvasRenderTarget( canvas );

// -- loop --
renderer.setOutputRenderTarget( canvasRenderTarget );
renderer.render( scene, camera );

Note that renderer.setOutputRenderTarget() must respect the renderer.outputColorSpace.

[github-actions]

📦 Bundle size

Full ESM build, minified and gzipped.

	Before	After	Diff
WebGL	338.24 79.14	338.24 79.14	+0 B +0 B
WebGPU	584.78 161.56	586.03 161.89	+1.25 kB +332 B
WebGPU Nodes	583.39 161.32	584.64 161.64	+1.25 kB +325 B

🌳 Bundle size after tree-shaking

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

	Before	After	Diff
WebGL	469.7 113.74	469.7 113.74	+0 B +0 B
WebGPU	654.13 177.06	655.1 177.29	+963 B +227 B
WebGPU Nodes	608.25 166.24	609.21 166.47	+963 B +230 B

[Mugen87]

Do you mind explaining why you have added this line?

We should check if this addition does not break XR.

[sunag]

After setting setRenderTarget() as outputRenderTarget it does not restore the previous state, making the current getRenderTarget() the same as getOutputRenderTarget() after the render, thus being a bug.

[Mugen87]

I try to make a test with a Quest 2 tomorrorw. Just to be on the safe side since r180 is released next week.

[Mugen87]

Would it be possible to keep updating the options object as before?

options is not only used in createTexture() but also in subsequent code like updateTexture(). To avoid side effects, it would be beneficial if options does not loose any information with these changes.

[Mugen87]

Could you please also temporarily update the builds? I can then build a rawgit URL for WebXR testing.

[sunag]

I'm checking an issue with anti aliasing, I think it would be better to wait a bit for final testing.

[sunag]

@Mugen87 Interestingly, the AA problem is not related to this PR but in WebGPU / WebGPUBackend. I haven't
discovered the origin yet, if you have any suggestions? I went back a few releases to test and the problem remains.

WebGPUBackend	WebGLBackend
https://jsfiddle.net/8oxjL7y1/1/	https://jsfiddle.net/8oxjL7y1/2/

[Mugen87]

Um, is this issue related to flat shading? When comparing without AA the WebGL and WebGPU backend, I can see rendering differences at the edges. WebGLRenderer matches with the WebGL backend, btw.

The MSAA is just emphasizing the issue in WebGPU.

[Mugen87]

For comparison two screenshots without MSAA:

WebGL backend:

WebGPU backend:

Something isn't right on the WebGPU side. It shouldn't look that soft.

[mrdoob]

What do you think about renaming it to CanvasTarget?

// -- setup --
const canvas = document.querySelector( '#mycanvas'  );
const canvasTarget = new THREE.CanvasTarget( canvas );

// -- loop --
renderer.setCanvasTarget( canvasTarget );
renderer.render( scene, camera );

[sunag]

renderer.setCanvasTarget( canvasTarget );

The idea of ​​having .setOutputRenderTarget() is to define a final output, the one that will be displayed to the user. Currently, it would be XRRenderTarget or CanvasRenderTarget.

I'll do some experiments to create a CanvasTarget class that relates to the renderer.domElement instead of RenderTarget. This seems to make more sense with this proposal instead of using RenderTarget as in this PR.