I think it should work also with linked datablocks
The idea is to add ‘‘outputs’’ that you can later find listed in the Material Input node (or @RonanDucluzeau’s Material Attribute node).
I don’t think that is a good idea to let the user link wires to the Material Input node,as you can do with nodegroups. First you won’t be able to do that for external libraries. Second I like the idea that a material is “set in stone” and can be explicitly changed only when it is directly edited in the nodetree.
This required a bit of python, since NodeGroupOutput isn’t available in the AddNode menu (for materials), and the ShaderNodeGroup don’t look up to materials’ node_trees.
But still, it works without any problem.
All I did was to add a GroupOutput to the material_A, and setup as in a normal nodegroup.
Nice test but:
the whole point is to not need to set anything in material A. The “surface” output you had to link to the group output is a thing that shouldn’t be needed. The ShaderNodeGroup should have access to the same green-dot output, without any pre-work. That’s how the user could link libraries without worries
This only shows that it’s possible.
Now, for a good implementation, all we need to do is to treat ‘MaterialOutput’ nodes as ‘NodeGroupOutput’, and add some method to look for node_trees in materials instead of just using blenddata.node_groups.
It’s also possible to do a copy on_the_fly of the materials’ node_tree, and just add NodeGroupOutput just for the instanced material nodes. (that can be done just with python, and I suspect that was what @AFWS did)
That’s also a nice start.
I start to wonder if this “instanced material node” could be useful enough as a feature, leaving the whole AOV stuff as an additional side feature. In other words, maybe it’s just the matter of adding “AOV Input” to the shader add menu, complementar of the AOV Output, which already exists.
Currently, in material output node, we have a list saying (All, EEVEE, Cycles).
You just add an item “Meta Material” to this list and a text field to name your material output node.
Or you create a new type of output nodes : a metamaterial output node. (what Secrop did in his test.)
Then, in a Material Input node of a Meta Material, you just need to precise name of material and name of output node.
Like in compositing nodes, a Renderlayer node is requesting a Scene name and a View Layer name.
Why should an implementation be made so clumsy? Why not having an “Input Material” node that just can retrieve all nodes from another material? The coer of the point here is: not having the need of making changes in the original material, neither adjustments to use it as “meta”.
It should just work whenever, and wherever, summoned.
The idea is just to be able to create different nodetrees for EEVEE and Cycles.
If you have a complex nodetree that will only work in Cycles and unfornately provide something ugly in EEVEE. You may care about producing a simple but good looking nodetree for EEVEE.
In that case, your material contains 2 outputs.
Then, if you want to use that material as an input in another one, you have to provide a way to define what output to use as an input.
We could have a text field to precise output with ability to keep it blank when there is only one material output node in material.
The same way, that an UVmap node works when text field indicating UV channel to use stays blank. It works when there is only one UVmap. Or it uses active one until user indicates another one to use.
I think that Blender could choose which path to take, either Eevee or Cycles nodes in material A, depending on how is set the Output node of the material B. If you link to a only Cycles material, the nodes passed will be those linked to a “Cycles” or “All” output in matA. Otherwise for Eevee they will be “Eevee” or “All”.
Not knowing how the nodetrees are evaluated, I can’t say if this is harder than making the user choose by hand
What is meant with “Type”?
If it’s just there to separate volume from the other 2 outputs, I think it is not so useful. Having material name and Cycles/Eevee would be fine.
Like so:
I have thought about this many times.
The basis of my interest was the use of materials in geometry nodes. You can assign just a material and have an attribute naming convention. And you can enter attributes or textures (most importantly) as input socket values. It would make sense from a design point of view if materials, like geometric knots, were always free groups. But I think it would be very inconvenient to always have the obligatory 3 shader outputs, as well as 1 geometry output. So 3 outputs would only remain as a standard preset, not an eternal state.
Combining groups of materials in geometric nodes, as well as entering any data into them, looks like a very serious task, since it is not clear where exactly this data should be in the end. Also, if now any material has input sockets, this means that it would be more logical to see these inputs on the material control panel not the last node in the stack.
Unless I missed something, this seems straight forward to me. Geo nodes already work like this. Any geo nodes modifier node tree already is its own nodegroup. UI in the add menu might need some tweaking for long lists.
The thread is about shader node trees.
Good to know that somewhere it already works like this. It makes the idea more coherent, thinking of a future implementation…
Voilà!
I tried to put together a script but it works… blah!
The idea is to have an operator to setup all the nodes, inputs and links in one go, but…
I suspect there’s some bug in the nodegroups API.
Try to run the script: the node is created, the links also. Try to add/remove shader links and it works.
But as soon as you connect the displacement thing start falling…
Also outputs don’t appear in the material node??
