State of Node-based Shaders in three.js? Any good tutorials?

Questions
, ,
21

Regarding the nesting of nodes through the constructor, I’ve an approach that helped with that. :slight_smile:

Basically, I put all the nodes hierarchy creation in a single method of a class, this method does not create all nodes directly, it mostly calls other methods that return a single node each. This way I can extend that class and overwrite every methods to return different nodes (without ever having to mess with the hierarchy or rebuilding it).

Something like this:

class MaterialA extends Nodes.PointsNodeMaterial {

  _buildNodesHierarchy() {
    const posNode = this._getPositionNode();
    const fooNode = this._getFooNode();

    this.positionNode = Nodes.add( posNode, fooNode );
  }

  _getPositionNode() {
    return new Nodes.PositionNode( Nodes.PositionNode.LOCAL );
  }

  _getFooNode() {
    return new Nodes.Vector3Node( new Vector3(0, 2, 0) );
  }
}

class MaterialB extends MaterialA {

  _getFooNode() {
    return new Nodes.Vector3Node( new Vector3(0, -999, 0) );
  }
}

It worked great so far !

1 Like
22

interesting! could you paste a small snippet of how you’re working with it in action?

23

This might be captain obvious butting in here, but babylon’s node-material-editor might well be worth looking at for ideas/code inspiration …

There’s a lot of tutorials available already, and it does generate GLSL - just tailored to their engine of course (I assume that means interaction with lighting etc via includes)…

24

What’s the status on this? Is node constructor nesting optional these days? Very much needed to simplify declarative abstractions.

I think that also nodes should not be regular JS properties, but inside of a Map in a .connection property, with initial values null or SomeEnum.None, so that dynamically reading the connections is very easy (right now, mapping over keys in node or Object.keys(node) may result in key/value pairs that aren’t actually nodes, but some other data of the class, and this makes it not possible to easily read node connections without having to explicitly list all node properties ahead of time.

In places like this,

code would be

if (node.connections.has('iridescenceNode')) { // or similar

but that pattern is still a little inflexible, because it happens inside of a constructor of WebGLNodeBuilder. What we really need is a method to be able to update the underlying shader as needed (and node manipulators would need to carefully call that after updates, a single time, to avoid performance cost).

Basically we just need all aspects of nodes to be:

  • dynamic, including
    • connections
    • finalization and re-finalization
  • easily inspectable
    • nodes/sub-nodes/connections can be obervable without pre-defined lists of keys needed by people doing the inspection (understoof that WebGLNodeBuilder knows pre-defined keys for its purpose, but that’s fine)

I wish I had time to contribute to this. For now, I can only express these ideas.