WeakMap error on updateTexture

[Makio64]

Description

I got on a production using a lot of Textures with load / unload a bug with material.map, sadly i didnt understand exactly the exact part of the bug so i cant put reproduction step and the error in console dont allow me to trace it to the source. ( see below screenshot )

The bug disapear when i replaced material.map = txt by material.colorNode = texture( txt ).rgb & same with opacityNode.

regardless, i was wondering if I should do a PR changing :

if ( binding.isSampledTexture ) {

				this.textures.updateTexture( binding.texture );

} 

To

if ( binding.isSampledTexture && binding.texture ) {

				this.textures.updateTexture( binding.texture );

} 

In case the binding.texture was delete in between, i guess this condition race is happening in my scenario ?

Reproduction steps

1. Coudnt find out whats exactly happening to create what i suspect is a race condition on the gpu.

Version

r179.1

Device

No response

Browser

No response

OS

No response

[Mugen87]

Do you call dispose() on your textures? If so, happens the runtime error after a disposal? Maybe the renderers ends up for some reason in an invalid state where a disposed texture is tried to be updated under wrong assumptions.

[Makio64]

I do called dispose(), a solution I though would be to delayed the dispose by a reasonable amount of time.

But i wanted to report the bug as I think a texture shoudn't be able to be push to update if its not ready / disposed already.

[Mugen87]

That's correct. The renderer should handle such use cases more gracefully. I hope we can figure out a reproduction test case.

I'll try a few things out in our sandbox example but it would be great if you can try to pinpoint the issue on your side.

[Mugen87]

There is definitely one bug:

WebGPURenderer: https://jsfiddle.net/qgh4a3jc/1/
WebGLRenderer: https://jsfiddle.net/qgh4a3jc/2/

When you call dispose() on a texture and trying to use it in a render call, the renderer should automatically allocate GPU resource from scratch. That does not happen with WebGPURenderer. The rendering breaks and a warning is logged:

Destroyed texture [Texture (unlabeled 256x256 px, TextureFormat::RGBA8UnormSrgb)] used in a submit.
While calling [Queue].Submit([[CommandBuffer from CommandEncoder "renderContext_0"]])

This also happens in the WebGL backend, just with a different warning.

Maybe your bug is related to this issue.

[Mugen87]

@sunag I'm afraid the changes added in #31497 do not work as expected. The below code sections ends up wrongly executed in the case a dispose happens:

three.js/src/renderers/common/Bindings.js

Lines 247 to 272 in d47d1d8

	} else if ( binding.isSampledTexture ) {
	const updated = binding.update();
	// get the texture data after the update, to sync the texture reference from node
	const texture = binding.texture;
	const texturesTextureData = this.textures.get( texture );
	if ( updated ) {
	// version: update the texture data or create a new one
	this.textures.updateTexture( texture );
	// generation: update the bindings if a new texture has been created
	if ( binding.generation !== texturesTextureData.generation ) {
	binding.generation = texturesTextureData.generation;
	needsBindingsUpdate = true;
	}
	}

One of the root causes is below line:

three.js/src/renderers/common/nodes/NodeBuilderState.js

Line 134 in d47d1d8

bindingsGroup.bindings.push( instanceBinding.clone() );

Non-shared bindings are cloned when they are requested over the node builder state. That clone breaks the management introduced in #31497 because the dispose handlers in Sampler do not operate on the correct instances (the clones). I'll try to provide a hotfix but I have the feeling this needs more refactoring.

[Mugen87]

I suggest you give r180 a try which should be released this week. Please let us now if you still encounter the bug.