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.