Any chance this gets merged before the next release cycle? ❤️

Definitely!

May I ask again for also adding an example of usage though? 😇

I thought I could sneak under the example 🏴‍☠️ Let me add one yes 😄

Okay I went a bit crazy on the example but I am doing a simple shadow volume. It will use the copyFramebufferToTexture3D() method obviously.

Might be a good idea to take the cloud shader out maybe? I am using it here as well and we have like 3 examples with their own version. I need a slight modification here I can hide that beyond some #define maybe

Is this still WIP?

The example isn't ready yet. If we want to merge I should maybe split that into two PRs.

Important note: copyFramebufferToTexture3D doesn't work with ANGLE backend. It's the same bug preventing to render to texture 3D. More info here.

I will add a note in the doc as well concerning that issue.

In this case let's convert it into a draft PR for now.

@DavidPeicho Sorry for pushing this to the next release. I think it'd be good to have some clarity regarding ANGLE.

@kenrussell Is this the same issue as #21893?

@mrdoob sorry for delay replying - no, this is a different problem. It's KhronosGroup/WebGL#2558 , https://crbug.com/1131224 , and https://crbug.com/angleproject/5009 .

It should be possible to work around this by using the same kind of texture everywhere - i.e., TEXTURE_2D_ARRAY for both the color and depth attachments. Is that feasible?

@kenrussell Thanks for replying. The goal of this particular PR was to implement a generic method to copy from a framebuffer attachement with layers, so TEXTURE_3D or TEXTURE_2D_ARRAY . The day the bug is fixed in ANGLE basically we can give this method to users.

On a personal note (not related to Three.js), I can't use TEXTURE_2D_ARRAY. I technically could, but the entire medical pipeline I worked on is based on TEXTURE_3D.

In the meantime, we can keep this PR on stall until the bug is fixed. Otherwise, I guess we could add a disclaimer in the doc saying it doesn't work with the ANGLE backend. I understand though if you don't want to do that @mrdoob and if you prefer to just wait

Just coming across this - with the recent changes to copyTextureToTexture it's not possible to copy data between both 2d and 3d render target textures and normal textures. It seems like it should handle this use case? This line:

renderer.copyFramebufferToTexture3D( srcPos, dstPos, shadowVolume.texture );

would turn into:

renderer.copyTextureToTexture( shadowRenderTarget.texture, shadowVolume.texture, box_bounds_2d, dst_pos_3d );

Looking at FramebufferTexture and copyFramebufferToTexture it seems the use cases basically encompass a subset of what you can do with copyTextureToTexture, now, aside from copying data from the screen buffer (ie setting the active render target to null). I'm wondering if we can remove the FramebufferTexture functions / classes with another change or two?