Materials as node groups
TLDR; Make materials work like geometry nodes in terms of tree==group and custom input attributes. i.e. make shader nodes consistent with geometry nodes
Nested trees
If you pay close attention to geometry nodes, you'll notice that every single tree is a group. You can use any tree inside another tree. This makes for a very powerful system where you can make trees that work as standalone, or as a modifier inside another tree.
I think materials should work the same. So you can do this:
But still have the Leather and Fabric material available for other objects. So this wouldn't be a thing:
Input attributes
Currently every single node input is shown in the surface panel of the material properties. I don't believe this is ever useful, except maybe if you only have a single principled shader without other inputs. I think exposing custom node tree/group inputs here would be way more useful and allow for user friendly pre-made materials. If someone made a complicated material (e.g. car paint), you could simply drag it in and change the sliders from the material properties without ever having to dive into the node editor. On top of that, different meshes could have the same material, but different material settings.
14 Comments
I believe they are planning on doing that. After working with Geometry Nodes a lot I can only wish shaders were like this too. Would make procedural assignment of shaders so much easier, specially by being able to map textures outside per object.
Are they? Where have you read?
So What u want is basically a material layer node? If that's so I totally agree! Every renderer has a material layer node, except for Blender's renderers.
+1 for layered materials. How would you suggest handling the displacement outs of the materials? Disagree with the Input attributes not being exposed by default. Perhaps an override flag that lets you see the parameters you want with the ability to set custom parameters?
For the inputs, we can keep the current panels and just add the custom inputs above. What is there to be handled about the outs? Displacement and volume would work just like surface.
I agree about a top level material control area, just leave it as is below.
Say there was vector displacement coming out of one shader and height based displacement coming out of another shader. Assuming these would go into the layer shader, how would it handle mixing the displacements? My understanding is displacement is usually handled in another tree in most other rendering engines.
I believe they have to be internally converted to be plugged into the displacement output, which is how the current system works right? You need a displacement node in between any type of map and the material displacement output. But I do agree it’s not clearcut, settings like bump only or displacement only or both can get complicated to manage. When I think about it, I wonder if there’s simplifications to be made to the whole bump/normal/displacement system we have currently.
You would need to define which properties are exposed in the material node to make this fully usable in node editors and the Properties editor. This can be done using node groups, so I don't really know why this should require a different system ?
And yes, seeing properties in the properties editor is useful. Easily overcrowded, especially since Principled BSDF is the default shader, but easily fixed with node groups. When you made a shader simple to use, and you only need to edit settings, animate, make drivers and other such things, it can be quite simpler to stay in the properties editor. And when you do these while animating, it saves you the need to waste screenspace on the shader editor.
I can’t verify right now, but iirc you need the node selected for it to actually show up in the timeline or graph editor. At least when you filter selected. But as soon as you have multiple parameters keyframed, you do that anyway, right?
The point is to make materials easily available inside any other material. Without having to create both a material node group and a material datablock that has nothing else but that node group in it, which is simply cumbersome. But the proposal thinks a bit farther ahead and tries to make function and logic consistent to geometry nodes.
I don't see where you are going with your first paragraph.
For the second paragraph:
To make a material available in another, unless you want to expose all possible inputs and make a bigger mess than the properties editor display, you would need to define which properties are exposed in the material's nodes.
Regardless of whether it's a material or a nodegroup, you need to speend time "making it usable from outside", I don't see how nodegroups and your proposal is better in that regard.
The only downside of nodegroups is see: you might have materials that just contain a nodegroup. But the big advantage of nodegroups: it's already there and does everything else you ask.
Is that downside such a big deal that it need a developer to spend time working on what you propose? Create new nodes, definitely breaks retro-compatibility, new ways to link/append materials and other things such a change could imply?
Maybe we could have a half-way thing where, in the Shift A > Nodegroup menu, there could be a list of materials in the scene, and selecting one would automatically turn that materials into a nodegroup? You would still need to spend time setting the available inputs and outpus, but at least you can do it from another material without back-and-forth.
I was saying that you need the shader editor open anyway if you want to animate, rendering the properties redundant.
The halfway proposal doesn’t make sense cause the whole point is simply to start unifying the way in which all node editors work. It creates expected behaviour and lowers the cognitive load for users, because they won’t have to keep similar but different functionality in their head. It’s just bad UX to have a bunch of almost similar interface paradigms in the application.
exactly like in the picture in my proposal with a bug red cross over it. It’s just silly and requires more steps to edit cause you have to tab in and out of the nodegroup.
You’re trying to make it sound as if I’m this egotistical dick that wants developers to spend time on my idea that will only benefit me. I don’t appreciate it.
I'm sorry you feel that way, but my only goal is to discuss feature proposals to either push them further or find solutions to concerns I or other people may find about them. Because I care about this proposal's ideas and the discussion is part of that website's purpose ;)
Indeed, but not necessarily, I.E. if you have a shader simple enough or made a node group to simplify it, it is not "needed" to open the shader editor, and you almost always have the properties' editor open no matter what, so you are more likely to open the shader editor when you can do without it.
Though if we had a way to chose which settings to expose there, it would be nice. But again: nodegroups do that already.
That confuses me, because the way I understand the material node you propose really sounds like a "similar but different" nodegroup. Except nodegroups already exist and can be used to input/output any kind of data available inside materials (color, shader, floats, integer, vector), whereas to my knowledge material nodes in GN only output material data?
Or maybe you think to basically turn materials as what nodegroups are right now? Which would mean having an additional material input node and optional output data?
You're still missing the point: consistency . I'm talking about higher level interface concepts such as node-based editors. Having two node-based editors work slightly differently is confusing.
It's literally the tl;dr in my proposal.
Only that first example is an actual argument, for which there's ways to solve it well (see other comments). It's a detail, and not the body of the proposal. For the second example, you're already spending time defining custom inputs, so nothing changes there. Already addressed in the proposal as well.
Maybe you should read it again?
It is when you want to animate a shader parameter.