Why is this artist even using the shader nodes editor at all… there is literally nothing “shader” to configure except the material parameters… which would be MUCH better done a different way.
IMO, it’s definitely ok, we’ve always been more developer oriented than artist oriented… Shader nodes have not been made to simplify shader development, but to make it modular…
I mean even in your example at some point the artist will have to edit the shader code…
in my example, we can have several big nodes(pbr vertex/fragment, unshaded vertex/fragment) and then an artist can make any new shaders which are based on these big nodes and some additional nodes over these. I saw some examples how it looks like in blender, I think it’s a good option for artists.
I don’t know how to make big nodes using the current shader system.
Well, IMO there is not often a good idea to sacrifice modularity and flexibility. I haven’t worked too much with shader-nodes so I can’t give a solid opinion, however, there is something I would like to know, In the second image you give (the second of the three last posted) you just mix all the simple-modules in a single unshaded one, right?, what removes you the modularity. What you want is a visual tool for artists, isn’t it possible to just make a tool that “visually boxes” the given simple-modules creating the equivalence of the “unshaded”?, so you can use those “boxes” anywhere you want.
You cold also allow to treat this boxes like a “black box” where you don’t see the internal submodules or see them by clicking some inspection button.
The point is, make a visual tool (the friendlier the better) but let the underlaying developer system the more modular possible (not sacrificing any of them)
1 Like
… exactly like you make small ones… but bigger… I don’t get your point
Not really…
For one thing, those two nodes are so tightly tied together that they might as well be just one node. (Why do you make it so complicated for the artist when they will have to use those anyway?)
For another thing, the output of the giant fragment node is the fragment color. There is no place to inject anything else because you’ve bundled it all into one black box. Texture filtering? Screw you, edit code. Color gradients based on normal, sorry, again, edit code.
So yeah, I guess our definitions of “easier” are just polar opposites… only mine matches the dictionary definition. 
I thought about this, it makes a new problem - resuing. If an artist wants to create 2+ its own shaders based on unshaded shaders, he should copy a lot of nodes to each new shader again, again…
for example, I want to present PBR fragment as one node.
This is a nice idea and someone already posted something along those lines. Like a grouping system for nodes.
Only thing that refrain me for doing it is that it has very few engine benefit, most of the benefit would be for editors.
… we already have that, it’s called PBRLighting.frag, rings a bell?.. it’s a ubber shader that takes material parameters as input… it’s waaaaayy more artist friendly…
But it’s very annoying when you want to change something inside, as a developer…
I don’t get it :S, sorry. If you have a big node that is a compound of other smaller one and it is treated as a template/blackbox/whatever you call it, the artist should use it just like your big node alternative (it is the same thing at this abstract point, a big node). If what you say is what happens if he wants to inject the code and modify this unshaded, with your big node he should copy it again and again, with the small modules alternatives he could just copy the unshaded template and remove/add/code the small modules it needs.
Well, maybe it could be “specified” and see if others do it xD. IMO it would be a good thing to have (I’m just a programmer but I like artists to make stuff too. It’s kind of annoying when they can’t work with me because they have “better engines” (easier for them) to use. When you try to make an indie group is an important factor).
So I think we shod have a possibility to work with both approaches, it depends on a case.
That’s an editor problem, not an engine one… just make a “create from…” option in your editor that would copy another material def…
I can make a new vertex part and use existing pbr fragment node, for example…
Well I definitely agree, my point is more that it could be implemented as a wrapper over the current system in an editor rather than a core engine feature. As you said in your first post.
2 Likes
You mean… like implementing a new myshader.vert and use with existingShader.frag?
You don’t need shader nodes for this.
hah, it’s your favorite advice for me but it can solve only part of cases.
yes, I can, but an artist can’t
Yes it is my favorite advice. Because it keeps the engine from being cluttered by situational code that no one need in game runtime situation. And no, it doesn’t solve all issues, and that’s why I sometimes accept some of your PR in the engine.
Unless you make a fancy UI in your editor so that an artist can do it , clicking buttons…
1 Like
I just want to remind the main point of this topic, I work on new shader generator, which allows making more difficult shader nodes, without worrying about collisions, missed world bindings, auto-resolving some defines and etc. And I don’t replace your shader generator, I just want to add an alternative option. It’s the main point of this topic.