WebGLRenderer.copyTextureToTexture3D() support Texture and CompressedTexture

[mbredif]

Description

copyTextureToTexture3D currently assumes that srcTexture is a THREE.DataTexture.

Bug

The bug may be reproduced using the webgl2_materials_texture2darray.html example of this PR against r128 or dev.
It fails because srcTexture.image is undefined.

Workaround

Without this PR, a THREE.Texture may be passed to copyTextureToTexture3D after the following workaround (so that it mimicks a THREE.DataTexture)
texture.image.data = texture.image;

Fix
This PR enables passing a THREE.Texture or a THREE.CompressedTexture as a source to copyTextureToTexture3D using an approach similar to the implementation of copyTextureToTexture .
It has not been thoroughly tested on compressed textures though.

Alternative/temporary fix
Change the docs to state that srcTexture should be a DataTexture rather than a Texture.

This contribution is funded by the ALEGORIA ANR project.

[mrdoob]

@DavidPeicho Looks good?

[DavidPeicho]

Sounds good to me!

[mbredif]

@DavidPeicho , thanks for your feedback
Have you tested it with compressed textures ? I did not test it much. But if you have, we could remove the warning !

[DavidPeicho]

I haven't. I use it for medical texture 3D and and most of the texture I use as sources are slices I generated.
I think we can try with any compressed texture just see if it works

[mbredif]

Maybe it should be discussed in another PR, but I find it weird that the UNPACK parameters come from the dstTexture rather than the srcTexture, especially for FLIPY. What do you think ?

[DavidPeicho]

It's a bit of both to be honest. You need to unpack based on the source and dest texture. For the FLIP_Y that's a really good question, I am pretty sure the current version will fail with force instance if source is flipped and dest is flipped as well.
I don't really know what should be the value, but by intuition I would say it should also be based on both source flipY and dest flipY?

[mbredif]

I was wanting to propose either _gl.pixelStorei( _gl.UNPACK_FLIP_Y_WEBGL, srcTexture.flipY != dstTexture.flipY ); (as you propose) or _gl.pixelStorei( _gl.UNPACK_FLIP_Y_WEBGL, srcTexture.flipY); (considering that flipping only affects the data loading and has no effect afterward)

• should the box and positions be affected by the flipY values ?
• what about UNPACK_PREMULTIPLY_ALPHA_WEBGL and UNPACK_ALIGNMENT ?

(copyTextureToTexture and copyTextureToTexture3D are equally affected btw)

[DavidPeicho]

Maybe let's open another issue for those concerns! I think if we change the current behavior we might break some code for people already expecting it to work in the way it currently is.

[mbredif]

Agreed, let's merge it now and open 2 follow up issues (one for unpacking parameters, notably FLIPY, one for compressed texture support).
@mrdoob, can you remove the changes in the example during the merge or do I have to revert it first ?

[mrdoob]

@mrdoob, can you remove the changes in the example during the merge or do I have to revert it first ?

@mbredif it'll be cleaner if you do it 🙏

[mrdoob]

Thanks!