mrdoob
WebGLRenderer: add copyFramebufferToTexture3D()
Description
This PR adds support to copy from the framebuffer to a 3D texture at a given offset. This is similar to the already existing copyFramebufferToTexture.
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
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.
@DavidPeicho Sorry for pushing this to the next release. I think it'd be good to have some clarity regarding ANGLE.
@mrdoob sorry for delay replying - no, this is a different problem. It's https://github.com/KhronosGroup/WebGL/issues/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