WebGPURenderer: Support for multiple render targets

[aardgoose]

First attempt at getting multiple render targets working in WebGPU/Nodes using WebGLMultipleRenderTargets, lots of cleanup work required if this looks like the right direction. Probably cleaner to use renderTargets.textures[] though, rather than special cases for multiple targets.

In the nodes material the returned outputStruct( outputColor1, outputColor2....) writes to the attached textures.

Example from webgl2 ported and working (you need to move the mouse around to get the first render. related to another async problem I have a patch for).

[sunag]

Very good, I just think that we can use NodeMaterial.outputNode instead of a new material:

const material = new NodeMaterial();
material.outputNode = outputStruct( [ diffuseNode, normalNode ] );

So users also use GBuffer to create masks for post processing preserving the mainly material, without having to create other render-pass.

import { materialOutput } = 'three/nodes'

const standardMaterial = new MeshStandardNodeMaterial();
standardMaterial.outputNode = outputStruct( [ materialOutput, maskNode ] );

And for Deferred Shading internally approach as:

material.outputNode = outputStruct( [ materialPosition, materialDiffuse, materialNormal, ... ] );

--

I will create materialOutput I think it can help for this design.

[aardgoose]

Using material.outputNode to avoid hacking nodeMaterial internals, ( that was only intended as a workaround).

[aardgoose]

@sunag

Updated to handle antialiasing. Do you want this reworked to handle all RTT cases with the same path, that is a textures array, and avoid all the special casing of Array.isArray()? This would agree with the approach taken in #26427.

[sunag]

Do you want this reworked to handle all RTT cases with the same path, that is a textures array, and avoid all the special casing of Array.isArray()?

Sounds good for me 👍

[sunag]

@aardgoose What would be missing here? It would be very good if we could merge this PR in this r156.

[aardgoose]

The only thing I see as significant are the changes required if #26427. was accepted. Otherwise it should be fine.

[sunag]

The only thing I see as significant are the changes required if #26427. was accepted. Otherwise it should be fine.

Thank you, I thought it was a great job, about the changes required in the #26427 I think we can wait, it will be backwards compatible, and we will need to rename WebGLMultipleRenderTargets to MultipleRenderTargets soon too, I think we can merge it now, this PR will be important for planning new features of the architecture.

[Mugen87]

and we will need to rename WebGLMultipleRenderTargets to MultipleRenderTargets soon too

Maybe we should consider #26427 before doing this. If @mrdoob approves the general direction of the PR, we don't need a MultipleRenderTargets class.