TSL - CustomMaterial Features?

[Bug-Reaper]

Description

Yo the new TSL stuff is pretty slick. I've spent the past two days trying to feel it out, great bindings once you get the hang of it.

I've read through the God TSL document like 3 times, combed code examples, and I can't figure out a couple of thing?

1. Easily mutate the final color of a Mesh<TYPE>NodeMaterial (chain on additional shader logic to the final product?)
2. Similar vein, access material property values inside custom material nodes. Feels inconvenient that the colorNode which replaces map*color does not have access to the material's map unless re-added as a new uniform?

Perhaps I'm missing something obvious. It appears uv() and vertexColor() can be grabbed a-la-carte but is there no way to access other material properties inside custom TSL Fn()s?

Much appreciate any insight!

Solution

My dream is TSL "First Party" feeling materials with arbitrary top-level properties to drive uniforms. Modularity in these materials also pretty cool if possible.

Alternatives

Open minded, can contribute some help if it's a good fit.

Additional context

N/A

[Bug-Reaper]

Classic solve it immediately after post, found a snippet somewhere but you can import { output } from 'three/tsl' and chain the outputNode` to itself to mutate a material to itself. Vis-a-Vis:

import { output } from 'three/tsl'

const mat = new THREE.MeshStandardNodeMaterial({});
const invert = Fn([frag]=>{
// Any TSL code ontop of final material color coming in as [frag]
return vec4(sub(1,frag.rgb),1)
}) 
mat.outputNode = invert(output);

This solves my first question about mutating shadernode outputs. May add some better examples to the doc along with any other things from my learning TSL adventures of the past few days.

[Mugen87]

Similar vein, access material property values inside custom material nodes. Feels inconvenient that the colorNode which replaces map*color does not have access to the material's map unless re-added as a new uniform?

There are predefined TSL objects for this use case. Try it with materialColor:

three.js/src/nodes/accessors/MaterialNode.js

Lines 451 to 458 in ef73c54

	/**
	* TSL object that represents the diffuse color of the current material.
	* The value is composed via `color` * `map`.
	*
	* @tsl
	* @type {Node<vec3>}
	*/
	export const materialColor = /*@__PURE__*/ nodeImmutable( MaterialNode, MaterialNode.COLOR );

You can then do this:

material.colorNode = materialColor;

And of course modify the color with more TSL according to your use case.

[Bug-Reaper]

Thanks @Mugen87 I had no idea we have all these node-accessors.

I guess my question is:

someMaterial.colorNode = Fn(()=>{
  // ?? => How to access material-props here??
})

I can't figure out how to reference a NodeMaterials's .map property from inside a custom node for example?

Mostly curious if all a node-material's properties can be accessed inside these custom-node functions?

[Mugen87]

If you want individual access on map, you need to wrap it into a texture() TSL call.

someMaterial.colorNode = texture( map );

[Bug-Reaper]

It's confusing that MeshStandardNodeMaterial cannot access it's own material properties from inside it's own nodes.

The material is able to reference these properties/uniforms internally right @Mugen87 could they be exposed easily? I think it's a good idea to expose access to all unique material properties including all .maps but also things like metalness/irridesence/etc. Particularly access in the context of custom-nodes attached to that material.

---

Let me know if that makes sense to you? Material-prop access like outlined above was possible and widely used in/via onbeforecompile creations.

[Bug-Reaper]

I've spent about a week in TSL intensively 10+hrs a day and here are my biggest observations:

🔥 Unexpected Friction 🔥

• mod() didn't work for higher-order vectors IIRC it crashes the shader-code.
• There are many magic-variables that allow access to material-node property uniforms but it is inconsistent and difficult to determine where things get mapped to.
  • No way to access node-material .map property uniforms.
  • cameraLogDepth uniform not exported by 'three/tsl' though listed in docs and used internally by three.js.
• Foot gunned by not understanding I needed to use toVar() and .assign() to update values inside a loop
• Foot gunned by not importing from three/tsl (undocumented you need to do this lol).
• custom-uniforms are not cloned when material-node is cloned. I'm not complaining about this behaviour per-say, but it was interesting to note.

✅ Unexpected Dope Sh*t ✅

• That nested-loop wrap macro is the sexiest thing I've ever used
• You can use this trick to convert old-style-materials to node-materials, super useful for many cases.
  • new THREE.MeshStandardNodeMaterial(oldMat);
• The code I write feels a lot better and more useful than older GLSL hacks.

TLDR: TSL is good and I'd like to see more transparent access with material-node property uniforms but overall still very good.

@Mugen87 Hope this feedback is helpful and please share it with others if relevant. There's some small pieces from this I may PR into the TSL wiki doc along with some common TSL use-cases I'd like to have example snippets for. I'll leave this open as a reminder to myself until I get a second for that.

Cheers,
Llama

[Bug-Reaper]

Closing, will address properly in #30778