The color output is also a big deal because it means easy displacement for OpenVDB volumes. You can displace in all six directions in a harmonious way rather than hacking together a setup with three different modifiers and red, green, and blue textures.
Then there’s the usefulness when the Separate RGB node is involved.
I wonder what this would bring ? shader nodes already kind of use fields, conceptually -since shaders are evaluated for every sample, much like geonodes trees are evaluated for every element/instance.
@moony how would a “multiply shader” node work ? it’s straight forward for “add shader” because in my understanding it just adds to the contribution for each sample, but how does “multiply” make sense in this context ?
I’m not sure I understand the question. If you can perform addition on two inputs, then you can also perform multiplication (multiplication is after all analogous to a series of additions).
I’m not suggesting we have a shader multiplication node - what we should have is a generalised shader math node - that includes all of the mathematical functions available in other math nodes.
Some math functions might be useful in a shader context, some not so much - but give people the tools and i’m sure they’ll find interesting use cases (just like I did for shader subtraction)
Materials arent evaluated per use. You cant expose element like Color like in Geonodes, add material to 5 objects and pass in different color for each object. You can only do that by custom properties and Attribute node, or by duplicating material 5 times. But if you use attribute then you cant make it into an asset, because you’ll have to attach info for user to create custom property every time they import it.
You also can’t pass in object coordinates per material. Only way is with Texture Coordinates node choosing one object, but you cant create for example “Decal” material that has input for object where you can have it on multiple planes and have multiple empties driving them. You have to duplicate materials and change object within node tree on every one of them.
Same goes for images, which is biggest pain in the ass. Not even node groups can recieve image data since sockets aren’t exposed in Shader nodes yet. You cant make node group asset if image texture node has to be in the middle. Because you cant pass in image from outside.
Fields for shader editor will be revolutionary for UX honestly, it will take away so much time and pain we have to spend on it. And especially for beginners, we can have assets so well set-up that if person doesnt want to they never have to touch nodes ever and just use material inputs, just like modifiers.
Aren’t you talking about exposing material properties? I thought when you said fields you were referring to geonodes fields, ie the diamond sockets
Well, can you actually expose a field-input in geometry nodes in such a way?
You can expose nodetree-inputs to the modifier, yes.
You can add a geonodes-modifier to 5 objects and set different values on their (the respective modifier’s) inputs for each object, yes.
.
.
But this works regardless of weather it’s a field-socket the input from the modifier is passed to, or a single-value-socket.
So it’s really a difference in terms of ‘how do modifiers work’ over ‘how do materials work’ and has nothing to do with fields whatsoever, it would seem.
So I think Hadriscus is correct here.
greetings, Kologe
Thanks for linking directly to the issue. If I understand correctly, using fields in materials is a prerequisite for exposing high level properties? I don’t really understand why, even though Hans provides a explanation,… it’s too technical for me.
this is good imo , it was an insane proposal. if they bring these features then please into the shader editor , not yet another one for just textures
