How useful could be a Material Input node?

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

Decide to play around with my custom material node some more. Added material target and type.


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:


It separates materials depending if surface or volume socket is used.

I must be missing something. Why shouldn’t we just grab the output(s) we want, without even need to care about the dropdown menu?

Wow, I need this so bad. Are you working in a commit to the base code or is an add on? What is the progress of it?

Bumpin’this thread to see if something has grown…

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…


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??

Please check it out. (remove xml extension) (204.4 KB)

1 Like