Unrelated TSL Uniforms linked

[DennisSmolek]

Description

I'm working in r3f/vanilla to create reusable objects. I hit the issue first in r3f but replicated it in vanilla three as well.

I have a simple class that holds refs to the uniforms and materials. I create two objects and none of the materials or uniform objects are shared. 100% unique (matches what happened in r3f). However, updating a uniform in one class (lets say the left box) triggers the results in the other. And when the uniforms in the right box are updated both boxes ignore it.

Even though I'm hovering the left box, the material in the right box gets triggered.
Then, if I hover the right box, nothing happens.

Logging everything out shows the uniforms are different nodes and ID's, the materials have different UUID's etc.

This too I've tried ALL SORTS of stuff both inside and out of react, out of memos, functions, classes, etc.

With WebGL its like two ShaderMaterials sharing uniforms unexpectedly even though totally split. Im not sure whats going on.

Reproduction steps

Make two sets of uniforms/materials. Change one, see results in both

Code

class Box {
  uniforms = {
    colorA: uniform(color('orange')),
    colorB: uniform(color('blue')),
    hovered: uniform(false),
  }

  mesh: THREE.Mesh;
  material = new THREE.MeshStandardMaterial();

  setHovered(hovered: boolean) {
    this.uniforms.hovered.value = hovered;
    console.log(`mesh ${this.mesh.uuid} hovered: ${this.uniforms.hovered.value}`)
  }

  constructor(scene: THREE.Scene) {
    this.material.colorNode = select(this.uniforms.hovered, this.uniforms.colorA, this.uniforms.colorB);
    this.mesh = new THREE.Mesh(new THREE.BoxGeometry(), this.material);
    this.mesh.castShadow = true;
    this.mesh.receiveShadow = true;
    scene.add(this.mesh);
  }
}

Live example

(Ignore the planes in the middle, this demo is being used as a control for a r3f issue as well)
https://stackblitz.com/~/github.com/DennisSmolek/tsl-linked-vanilla

Screenshots

No response

Version

179

Device

Desktop

Browser

Chrome

OS

Windows

[sunag]

This happens because you are setting the value before rendering instead of during the call process. To control this type of event, you should use this: #31514 or userData( 'customColor', 'color' )

three.js/src/nodes/accessors/UserDataNode.js

Line 77 in efbf630

export const userData = ( name, inputType, userData ) => nodeObject( new UserDataNode( name, inputType, userData ) );

[DennisSmolek]

This happens because you are setting the value before rendering instead of during the call process.

Isn’t all value assignments to uniforms done this way? You set the value of the variable before calling render typically.

And why do the two sets of nodes affect each other? they are totally isolated.

[sunag]

And why do the two sets of nodes affect each other? they are totally isolated.

Oh yes, I think I analyzed hastily; there is probably some issue in the cache system.

[DennisSmolek]

Further Isolation shows that if I use NodeMaterial I dont have this problem. Its something with using THREE.MeshStandardMaterial

So its something with the cache/shared program of the regular material where it looks like NodeMaterial gets a fresh cache per instance.

I guess its not a good pattern/usage to mess with uniforms in the standardMaterials.

I'll see if this extends to my r3f version as well.
Update: it does. Using NodeMaterial fixed it in r3f as well.

[sunag]

Using NodeMaterial fixed it in r3f as well.

Makes sense, I checked the material and it's not a *NodeMaterial. Even though it still works, it might behave unexpectedly. Try replacing MeshStandardMaterial with MeshStandardNodeMaterial.