WebGLRenderTarget.copy Bug: Copying from render target results in targets sharing .texture.image

[gkjohnson]

Here's a snippet to reproduce the issue:

const x = new THREE.WebGLRenderTarget();
const y = new THREE.WebGLRenderTarget();

console.log( x.texture.image === y.texture.image ); // false

x.copy( y );

console.log( x.texture.image === y.texture.image ); // true

What this means is that when x.setSize is called the object at y.texture.image is inadvertently modified but and is now out of sync with the true dimensions of render target y.

This line is the problem in Texture.copy:

this.image = source.image;

I assume this was originally intended to handle moving over an <img> tag without duplicating it -- maybe it makes sense to duplicate the image tag? Or maybe it should clone the object in some cases:

this.image = source.image instanceof Image ? source.image : { ...source.image };

I imagine copy would behave a bit confusingly for DataTexture, as well.

Edit: I see now that retaining the image data reference is important for dealing with cloning textures before they've been fully loaded and is valuable for minimizing data duplication.

[Mugen87]

WebGLRenderTarget.copy() and WebGLRenderTarget.clone() are problematic mainly because of #19598. I wonder if it's not better to remove copy() and clone() from WebGLRenderTarget.

[gkjohnson]

I mean I think it's a useful feature -- the docs specify that only the settings of the render target are copied, which is all I'm expecting:

Adopts the settings of the given render target.

[gkjohnson]

And this is an issue with DataTexture, as well:

x = new THREE.DataTexture( [ 1, 2, 3 ], 3, 1 );
y = new THREE.DataTexture( [], 0, 0 );

console.log( x.image === y.image ); // false

y.copy( x );

console.log( x.image === y.image ); // true

EDIT: See #21719 (comment). I think #17766 might be a better solution for this problem.

[Mugen87]

I mean I think it's a useful feature -- the docs specify that only the settings of the render target are copied, which is all I'm expecting:

Maybe. But nevertheless the methods are problematic. As soon as a render target was processed by WebGLRenderer, they do not produce the result users might expect. Meaning a deep copy of the custom frame/renderbuffers. I have the feeling it's a more consistent if such a "half-working" API does not exist.

[gkjohnson]

Maybe it's because I'm more familiar with graphics but I've never expected copy to copy the contents but clearly there's been some confusion before. Perhaps it's better in the render target case to change the copy function name to something more specific like copySettings or copyParameters:

x.copyParameters( y );

[ankhzet]

@mrdoob Now cloning WebGLRenderTarget breaks (?) it's texture, as far as I understand.
In the constructor texture receives this flag:

  this.texture.isRenderTargetTexture = true;

If you don't add it during/after cloning, f.e. like this:

  this.texture = source.texture.clone();
  this.texture.isRenderTargetTexture = true;

then, if texture then is used in shader, setTexture2D() will try to upload the texture, resulting in gl.texSubImage2D throwing an error, as it can't find the correct method overload to load the image

Struggled with this issue when tried to implement outline effect using postprocessing@6.25.0 + three@0.138.3. postprocessing modules use code like this to create internally used textures for shaders:

    this.renderTargetMask.texture.name = "Outline.Mask";
    this.uniforms.get("maskTexture").value = this.renderTargetMask.texture;
    this.renderTargetOutline = this.renderTargetMask.clone(); // <= .clone() here
    this.renderTargetOutline.texture.name = "Outline.Edges";
    this.renderTargetOutline.depthBuffer = false;
    this.uniforms.get("edgeTexture").value = this.renderTargetOutline.texture; // <= texture without 'isRenderTargetTexture' flag is used in a shader texture uniform

Worth mentioning, the lacking flag wasn't breaking my code per se, but it generated dubious error message, which I believed was the reason, why my code didn't work, leading me in a completely wrong direction from actual solution %).
Don't know, if it's an issue with cloning, or such usage of WebGLRenderTarget should be discouraged in a consumer code.

[Mugen87]

Good catch. Let me fix this with a PR.