Texture: Set needsUpdate to true in copy().

[Mugen87]

Fixed #23627.

Description

Texture.clone() requires a manual definition of Texture.needsUpdate (see #22718).

[Mugen87]

TextureSettingsTest.glb now renders like so:

[mrdoob]

I think the best solution for this is to do needsUpdare = true inside Texture's copy()...

[Mugen87]

I did not suggested to do that in #22718 because it does not solve the following issue:

const loader = new THREE.TextureLoader();
const texture  = loader.load( 'path/to/my/texture.png' );

const clonedTexture = texture.clone(); // needsUpdate set to true too early

However, modifying Texture.copy() will at least log a warning which makes the error more obvious:

THREE.WebGLRenderer: Texture marked for update but no image data found.

I'll update the PR.

[Mugen87]

webgl2_multiple_rendertargets fails now...

[Mugen87]

Ah the problem is that cloned textures for render targets now have a version greater 0. That will make WebGLTextures triggering a texture upload which is not valid for render targets. Fixing...

[donmccurdy]

@Mugen87 if we have two textures with the same Source, what does texture.needsUpdate = true do now? In the past I've assumed that property causes a re-upload to the GPU... is that still true with a shared Source?

[Mugen87]

No, this does not happen with Source anymore if setting needsUpdate to true happens in the same frame for both textures.

The are a couple of design issues in Texture that prevent the implementation from avoiding any possible overhead. E.g. to make the implementation backwards compatible, setting Texture.needsUpdate also triggers Source.needsUpdate. Besides, properties like Texture.type and Texture.format which are closely coupled to the data are still part of Texture. So depending on how you configure an instance of Texture, there might be additional GPU uploads. But not in the "standard" case.

[mrdoob]

Thanks!

[mrdoob]

Cherry-picked into the master branch and included in 0.138.3.