WebGPURenderer: Allow specifying texture index for MRT in readRenderTargetPixelsAsync().

[Spiri0]

Related: #22403

The readRenderTargetAsync function accepts a renderTarget, but so far has no option to choose between the different textures of a renderTarget if it has more than just one texture. That's why I added an index = 0 so that everyone who has used the function so far has no disadvantages because the first texture is always selected by default.

[Mugen87]

Does this code...actually work? At least the WebGL backend won't work until gl.readBuffer() is used in WebGLTextureUtils.copyTextureToBuffer().

I'm not sure about required workflow in WebGPU. Do you mind demonstrating the updated method with an example? E.g. you could use the code from https://threejs.org/examples/webgpu_multiple_rendertargets but instead of rendering to the screen, you extract (color and normal) values via readRenderTargetPixelsAsync().

[Spiri0]

I made an example. Since this is my first one I must have missed something in the PR. It works for me. #28198

readback wood from gpu

readback normal from gpu

The textures read back from the GPU were created with a smaller render target. Users have to be careful with readRenderPixelsAsync because the CPU is not intended to receive large amounts of data from the GPU. Maybe a size selection button in the GUI would be nice for different readback sizes?

[Mugen87]

Okay, then it seems to work for WebGPU but not WebGL. However, that can be fixed at a later point as well.

@aardgoose Does this change look good to you?

[aardgoose]

Okay, then it seems to work for WebGPU but not WebGL. However, that can be fixed at a later point as well.

@aardgoose Does this change look good to you?

It looks fine, actually it works with WebGL. The texture copied is always mapped to color attachment 0 so no need for readBuffer() changes.

[Mugen87]

The texture copied is always mapped to color attachment 0 so no need for readBuffer() changes.

But that means it's not possible to read subsequent color attachments, just 0, right? So in the demo it should not be possible to extract normal values.

[aardgoose]

The texture copied is always mapped to color attachment 0 so no need for readBuffer() changes.

But that means it's not possible to read subsequent color attachments, just 0, right? So in the demo it should not be possible to extract normal values.

It works for both, it maps the chosen texture to a temporary framebuffer as attachment 0, I've tested the path and demo to check.

[Spiri0]

@Mugen87 In the third screenshot you can see the normal texture read back. In this case, index 0 is then set to 1 (line 218 reads back the normal ones). I now see that it would be better if the respective readback were in the respective selector, then both would not always be read back but only the selected one.
I can improve that later, as well as the option to select the readback resolution.
But the PR in the example didn't work. What did I forget to take into account?

[Mugen87]

But the PR in the example didn't work. What did I forget to take into account?

Not sure what you mean by that. Do you mind rephrasing?

[Spiri0]

Doesn't seem like anything important. In the details it says that screenshots could not be created.

[Mugen87]

Let's talk about this issue in #28198.