Shader Forge - A visual, node-based shader editor

Shader Forge is now out on the asset store, so, this thread is old now
Click here to go to the new thread!
(If you subscribed to this thread, don't forget to subscribe to the new one!)

Old content below:
----------

Hello!

After all this time using Unity, there's still no *visual*, node-based shader editor, for some reason, which I think is one of the few weak points of this fantastic game engine
I spent some time working on one, and here's how it currently looks, and works!

I'd love to hear what features you'd expect/want in an editor like this.

Shader Forge on the Asset Store

Here's a list of all nodes

Click here for a feature/node/todo list!

What features do you like the most/least about other node editors you've tried?
What do you think Shader Forge should do differently?

 

Thank you for this.

I think it would be great if you could use a combination of nodes and shader languages. Some community based shaders are quite complex and it would be great if you could make a script that takes a text based shader and translates the simple things into nodes and, leaves the more exotic qualities intact.

 

You should have a look at this > http://forum.unity3d.com/threads/56180-Strumpy-Shader-Editor-Now-Open-Source That should save you a lot of time, he's not updating it any more so go crazy. Good luck.

P.S. I hope you get it all working, this would be an amazing asset for the community.

 

I agree with the above posters. On an aside, though, your interface looks pretty awesome.

 

It will be awesome if fullscreen image-effect shader is supported

 

This would be very tricky to write, especially determining what counts as "exotic qualities" and not
I imagine making shaders with this is going to be easy though, so you (Or someone else) should be able to recreate most of the complex ones you've seen!

Thanks! I've written it from scratch though, in order to both learn more and to have more control and overview on the whole system. Might be handy if I ever get stuck on something though

Thanks! Most of it is just Unitys default skins though

Possibly! It would be useful.

Anyhow, a little update:

 

Oh man...i understand why you made this from scratch, but honestly we all hoping that someone can revamp SSE again .
and of course this is amazing work dude.
btw is this gonna be commercial or free? Just asking eventhough i hope it's free


Edit :

Oh and i notice that the shader input are familliar like UDK, but how about the code it generates? since in UDK there's a lot of unused code in their result which make the shader bigger in size

 

There won't be any unused code, especially not since it's still being passed through Unitys shader optimizer after Shader Forge is done writing it

Sadly, it's not going to be free, as I'll spend lots of time working on this, and of course, maintaining it once it's released.

That said, Unity pro isn't required in order to use Shader Forge

 

Another update!
It now supports blending modes. There are some presets, as well as a custom blending mode menu

 

Very nice work; interface is looking especially slick.

 

Exactly what I was looking for. Am very fond of node editing as have been using PlayMaker for my entire game and writing shaders for every little detail is getting silly. A node based shader editor would be absolutely awesome as stumpys is basically abandoned. Easily pay $50-100 for this no problem! Keep up the great work!

 

It now supports Transparency/Alpha, plus face culling and depth control
(Also, the connections now have uniform spacing)

 

Really nice work you are doing here, well done indeed!

 

Very exciting project...keep at it please
And...if it's not too big of a secret, how are you drawing your component lines, is it an addon or your own code? They are very nice.

 

Nice. I was going to make something like this too. Strumpy is quite good but for Free users it didn't have realtime visualizing of the output or per-node visuals. Yours looks much better and easier to grasp. It also looks somewhat similar to Unity's upcoming shader editor.

I'd like to say my piece on the whole node-based editing thing and hopefully this is constructive feedback that will help to make your editor even better. If I have to do the same amount of `programming` using a tool like this as I would likely have to do by writing text-based programs, then it does not save me any time or pain. This was for me the main problem with strumpy and that other shader editor, it was great in how flexible it was as a low-level tool but you basically had to hook up these stupid boxes just to do simple math operations like multiplying two numbers together. If I wanted to have to drag boxes around with the mouse and drag the little connector splines to join them up etc just to get to the point where two variables are talking to each other, that's too much work, better done in text form with a few split-second key strokes. This can be where user interfaces like this fail - forcing you to do tremendous dragging/manipulating/mouse work just to do the same amount of result. So please be careful about that. I notice from your screenshots that you're showing various nodes such as multiply, add, vector2, vector3, texture2d etc. These are text-based programming terms. I'd rather not have to mess around with all this low-level crap and all that stuff from text programs. How it that helpful? I want to see things be higher level than this but still maintain flexibility somehow. I don't want to be in a situation of having to assemble all these boxes and connectors just to get some basic low-level programming done - I might just as well open up the text editor and type it.

The other MAJOR annoyance about visual node editors for me is in the area of usability. Please be very careful here. It is not necessarily a good idea to let the graph turn into a spaghetti nightmare with no node alignment or way to easily and intuitively `read` what is happening at a glance. The thumbnails are a great addition for usability purposes. But for example, is it really necessary to let the user drag the boxes to any pixel coordinates they like and then end up with a big unaligned mess that is hard to follow? It would be great if you'd at least provide an option to auto-organize the entire graph and have me creating new nodes in a predesignated grid or something. Things flowing left to right or whatever should be neatly aligned so that I am educated from this alignment in how the nodes are relating to each other. Otherwise these charts just become a big noisy mess with little meaning that are hard to understand - then you've got to sit there for ages following through the whole thing figuring out what the heck is happening. It's also really hard when the way you present the links between the nodes makes them look bidirectional. When the links look the same on both ends and the connector shows absolutely no indication of which way the `program flow` flows, looking at it visually makes me confused about what is actually happening. I want to see visualization of the actual program flow, like bi-colored juice flowing through the system with animation or something. It is not necessarily obvious upon first glance that program flow proceeds left to right, and you have to make it as immediately easy to grasp as possible. The rule of thumb is, "don't make me think". If I have to stop to think even for a split second in order to figure out what the heck is going on then you've introduced pain and delay and confusion. If you can make your presentation and usability really clean, simple, obvious and intuitive, then you could be onto a winner.

I think you have to ask yourself who is your audience. At the moment it seems like you are targetting low-level shader programmers who already know how to write shaders, and therefore your tool is just turning a text-based shader writing interface into a mouse-drag based interface. I don't necessarily see much benefit there, and without benefits a tool isn't useful. I think if you target ALSO less experienced users who dont know or want to know how to actually `program` shader functionality, which your tool is requiring of them, you will access a far larger audience and make your tool much easier to use.

 

Just for reference, Unity's upcoming editor looks like this: http://blogs.unity3d.com/wp-content/uploads/2012/12/ShaderGraph2.png

And here is an example of how NOT to make a user interface: http://warby.bitproll.de/projects/9999_wip/warbys_uber_shader.jpg unless you're trying to make a picture of spaghetti. How can anyone have the slightest clue what this thing does without a lot of study time? Don't do this please - don't let the user do this to themselves. Actually you've inspired me to make a new tool myself.

 

I personally did not have that much of a problem with strumpy shader editor and it was free but if I paid for it I'm sure I would have been more picky.
Feature List:
1. Print Screen of nodes i.e. similar to uScripts
2. The ability to create dx11 shaders
3. The ability to create OpenGLES GLSL for mobile CG shaders for computer or mobile
4. Shader Auto Save
5. Prebuilt default shaders i.e.(diffuse, particle, ramp, reflection shaders, simple sss, hair, displacement, and etc.)
6. Prebuilt Voroni Noise, Perlin Noise, Cellular Noise, Simplex Noise shaders samples
7. The ability to make a shader which converts a color map into a normal map at run time
8. Flow shader creation
9. The ability to save out into shader format or into a shader node tree to be edited later.
10. Each node should have a mini help like menu which describes what the node does.
11. The ability to create post/screen effect like shaders.
12. Mesh preview window
13.

 

1. Print Screen of nodes i.e. similar to uScripts
What does that do? Save a picture of the entire node hierarchy, regardless of camera position?

2. The ability to create dx11 shaders
How do you define DX11 shaders? I've planned to add support for tesselation and displacement, if that's what you're asking

3. The ability to create OpenGLES GLSL for mobile CG shaders for computer or mobile
As far as I know; Unity automatically compiles the platform specific shader code from the CG code, GLES included. Just make sure you don't make your shaders too expensive!

4. Shader Auto Save
The shader will auto-save every time your shader is out of errors, most likely, and when you tell it to save manually

5. Prebuilt default shaders i.e.(diffuse, particle, ramp, reflection shaders, simple sss, hair, displacement, and etc.)
There will be plenty of defaults!

6. Prebuilt Voroni Noise, Perlin Noise, Cellular Noise, Simplex Noise shaders samples
There will be a few of these as example textures included in the pack, but I don't think I'll make nodes/code to generate them on the fly.

7. The ability to make a shader which converts a color map into a normal map at run time
What's a color map by your definition? A grayscale height map to Normal map node could work though!

8. Flow shader creation
As in texture-based UV distortion/panning? Yes, already supported! One of the example shaders will be a flow shader.

9. The ability to save out into shader format or into a shader node tree to be edited later.
Yes, they will be saved in the shader file itself

10. Each node should have a mini help like menu which describes what the node does.
Yes

11. The ability to create post/screen effect like shaders.
Most likely! Not 100% sure if this will be implemented, but it has been requested several times now

12. Mesh preview window
Well, yes, that's already in

 

Sorry for the late response to this imaginaryhuman! There are a lot of things to cover in your massive chunk of feedback
Thanks for your elaborate response!


From your post, I take it you have 6 primary concerns: (Correct me if I'm wrong!)

1. Node-based coding tends to become more tedious and time-consuming than actual coding due to dragging and connecting nodes to get the same result.

Learning shader coding is usually very difficult and intimidating for people who have never written code before.
Yes, you get to the same result as actual shader coding. But the entire point of this tool is that you don't have to code it
There are plenty of people afraid of code, who just sees it as something that's way too complex for what they want to get out of it.
It's a massive reward/effort threshold for many. If you already know how to code shaders and don't see any benefit of a visual approach, then no, you probably don't need this tool.
But even if you do know how to code shaders, you might want to have a more experimental approach, and visually track what is actually happening in the shader code. This is where the visual nodes come in. The node thumbnails are central for this tool, especially when comparing it to Strumpy or ShaderFusion, which both are very anonymous.

I believe most artists want visual feedback. I personally don't *need* visual feedback, but I definitely want to have it.


2. Node-structures tend to become cluttered and unreadable with more complex setups, making it hard for someone else to read your structure.

This applies to anything where you are in control of the underlying structure of a creation, where you can get the same output with different methods.
You can write terribly cluttered shader code, C# code, JavaScript code, php code, any code. You can have a photoshop file with 100 unnamed layers. A model in Maya with unnamed nodes, importing into engines as polySurface45. You can have a Unity project with an extremely messy folder structure, or scene hierarchy, and the list goes on.

My point is, it's up to the user to make sure you create clean structures with the tools provided.

So what tools will Shader Forge provide? I've planned to have support for nesting nodes. As in, selecting a set of nodes and collapsing them into a single node, which you are able to name to clarify what it actually is.
Having a tool to auto align or toggle on/off a grid would be useful as well, I might add that

With great power comes great responsibility, right?


3. The tool needs a target audience. It's using programming terms instead of more intuitive ones (Vector3 instead of Color, for example)

This is a tough one! I've been giving this a lot of thought.
For example, what should we call Gloss? Gloss, is technically the exponent of the specular light reflection. Technically it should be called "Specular Exponent". UDKs material editor calls it "Specular Power", which can easily be confused with the strength of the specularity, which it isn't.

Okay, so what about Vector3? UDK calls it Constant3Vector. Which is technically accurate. I call it Vector3 currently (Might change).

However, should we perhaps call it color? Let's call vector2 UVs too, because it's usually used as that. Vector could be called Value, or number, because, it is a value or a number. Vector4 could be called Color with Alpha, so then we have:
Number (Vector)
UV (Vector2)
Color (Vector3)
Color with Alpha (Vector4)

Which is fine, until you want to do something else with them. Perhaps we want to blend the normals to flat based on a parameter or texture.
We'd then need to use an "up vector". What's that? Right, it's a Vector3, which in this case is called "Color". Yes, normal maps have color in them, but that's not what they are representing, nor used as. It gets even more confusing with vertex offset. You offset by a "color", which gets confusing quickly.
It's also technically inaccurate. Colors never go outside the 0-1 range, which Vector3 can.

I'll have to give this a lot of thought, it's not an easy one. Simply having different modes to toggle between makes tutorials confusing, and communication difficult between different users using different terminology.


4. The tool is too low-level, using nodes like multiply, add and such, when it needs more high-level features to appeal to users not used to shader coding.

Shaders *are* low level *inherently*. There's no way you can pretend otherwise. If it's not low-level, it's not a shader editor. I'd say it would then be some form of shader generator, but not an editor.
The whole point with the shader editor is to provide the same flexibility as writing shader code, without learning how to write shader code, and at the same time get more visual feedback for what is actually going on.

I find it quite absurd that you say multiply and add are "text-based programming terms". Most people know what that means (And has for a long time). Even if the users aren't able to 100% predict what they mean in this context, they can just try it and see what happens, since it's visual.

Again, "I might just as well open up the text editor and type it" assumes that shader coding is easy for everyone to just do.



5. It looks to complex, and isn't very user friendly.

Making sure it's easy to learn is important!
I'll make sure the interface has as little clutter as possible for people opening it up for the first time.
That said, this is a tool, not an interactive experience made for people to enjoy. It should be easy to learn, yes, but there is a necessary complexity in a tool like this to ensure flexibility.
I wouldn't rely on "Don't make me think" as a guideline when making a tool. Perhaps when making games for people who casually play games, but not a tool.

For example, you don't open Unity for the first time and expect a game to appear without having to think.


6. Unity is already making a similar node-editor that looks pretty much the same

They haven't said whether or not they are working on a shader editor internally. The one you linked was from their NinjaCamp, where a group of employees (Strumpy included) worked on a prototype for a week, on projects which they don't otherwise work on.


Anyhow, thanks for the feedback
Sorry for the somewhat lengthy response!

 

Hi. Thanks for your replies, I wasn't sure if you were going to reply at all

I can see from your responses more of where your focus is, on making this an editor that lets you build shaders with the same degree of flexibility as is possible when getting into the shader code, but in a visual way and with some WYSIWYG elements. I do appreciate the thumbnails/live feedback.

You spoke about how your tool helps people `not have to code`. But I think we have to be a bit more honest here... the kind of thought processes that need to occur in order to write shader code is not very far removed from those you need to build these shader graphs, and just because you're working with a more visual system does not mean you don't need the same kind of know-how. Almost every engine, platform, system I've seen that has some kind of `visual programming` tool has lied about how visual programming completely alleviates the need to `program`, but it is really a smokescreen because there is still so much complexity involved, it just doesn't `look like` code.

I can see that you're probably saving time having to write the code syntax, properties, passes, cg headers, functions, correct syntax, etc... that does remove some of the complexity/pain and makes it easier to build the shaders in general. Thumbs up there. But in terms of the functionality of the fragment shader for example, a visual chart is almost 100% the same kind of complexity as is present in the shader sourcecode. I'm going to have to sit there and string together building blocks that basically represent every part of the sourcecode that I would've had to write anyway.

That's why I mentioned about multiplying, adding, etc... sure these are simple commonly understood terms, that's not really my point. My point is the user still have to work at a low level even if it's visual, and that kind of low level is simply too low for artists who are for the most part going to be non-technical. Making it have visual boxes and wires makes it look nice but it doesn't make it easier. Artists are most likely not programmers so much and won't be able to understand how to build the results they want from these low-level building blocks. I know you said shaders are inherently low-level... the results of shaders are not low level, just the way they have to be currently implemented.

For example to put together something that does bump mapping I'm going to still have to know about what a texture2d is, what a sampler is, what format normals are stored in, the requirement of unpacking them, how to apply them to the model, how to combine it with a texture, etc... in order to be able to build a graph that represents that... at the end of the day it is just as much technical complexity as writing shader code but just with a `visual syntax`. That's the only reason I was questioning who your audience is because keeping everything at this `low level`, which does provide flexibility for those who can master it, is going to simply be too difficult for a large majority of people. And you're right, it would make your tool more of a `generator` and not as much an `editor`, but it is the generator that removes the pain and makes it easier and more accessible to get results. Having higher-level interfaces doesn't have to mean there is no flexibility or control. It's very common for developers to equate a high-level interface with generalization/limitation of outputs.

But as you say, maybe that is not who you are aiming this at... if I did not know anything about shader programming or writing shader code and I came to your tool, I would NOT be able to very easily make a shader to do what I want without some significant learning curve because I still need to know the `language` of how shaders operate. Yet if I DID know how to write shaders already, I would be able to use your tool to put shaders together fairly easily. So I think right now you are actually targetting the more advanced shader programmers. If you want beginners, artists, designers, vast majority of Unity users etc to use this tool I think you will find it's not going to happen without adding a whole other layer of higher-level tools on top of the low-level stuff.

Take a look at some of the comments on the asset store for Strumpy, for example, there are valid complaints about how the tool is simply not useable for artists that don't know how shaders work because it's simply too low level. It's great if all you want this to be is an editor for shaders, it will get used by those who understand shaders and are more advanced developers, but I don't think you will be able to bring in a wider berth of customers otherwise.

You mentioned also about spaghetti code results and user responsibility... from a usability standpoint you still have to remove as much requirement for thought as possible. And when you think about it, does it actually `help` the shader development process to allow users to drag and position boxes anywhere they like on the screen, resulting in a big spaghetti mess? And are users even capable of creating an organized layout, or do they even know that they need to take that responsibility? From what I've seen of many of the crazy Strumpy screenshots out there, apparently not. And it just makes things hard to read. Why not just force automatic alignment?

Anyway, that's my opinion of this whole thing. You've inspired me to work on my next shader `generator` tool so this has been productive for me... not trying to say your project is wrong or has to change, just that right now it isn't suitable for a general audience and if you want it to be then you need to make it easier to get results.

 

Personaly, I think it is well suited for general audience. The schematic is clear even tho the terms may not be right. I like it and I can imagine some artists here without shaders background being able to work with the tool. As for the code it generates, you can always leave to someone with a good background to optimize it afterward.

 

1. Print Screen of nodes i.e. similar to uScripts
What does that do? Save a picture of the entire node hierarchy, regardless of camera position?

Yes that is correct. You know how on a PC you hit the print to screen button and it saves a snap shot of your desktop. You can then paste that snap shot into other programs like Photoshop to save as a jpg to look at for reference.


2. The ability to create dx11 shaders
How do you define DX11 shaders? I've planned to add support for tessellation and displacement, if that's what you're asking

Yes tessellation displacement DX11 shadier support is what I am talking about.

4. Shadier Auto Save
The shadier will auto-save every time your shadier is out of errors, most likely, and when you tell it to save manually

I mean it will save every couple of minutes like most programs like 3DS Max and UDK do.
It’s a safety net so that if the program crashes you will not lose all your work.

7. The ability to make a shadier which converts a color map into a normal map at run time
What's a color map by your definition? A grayscale height map to Normal map node could work though!

When I say color map I am talking about the diffuse map which has color on it or the texture but if you look at what substance bitmap2material, crazy bump or xnormal. You can take a texture and make convert it to a ambient map, heightmap and a bump map using some other tool.
But you would be desiderating a texture to change it to a height map which you would use to make a normal map from.

 

Thanks for all the nice comments so far!

Development should speed up these coming two weeks, as I'll have a lot more time to work on Shader Forge

Emission/Self-Illumination, a Power node and a One Minus node is now implemented!

 

Sounds awesome! I was disappointed when I realized that strumpy would not be compatable with Unity 4 in DX11 mode.

I see from your google doc that you might not support displacement Please do. I'm not entirely sure that vertex offset will do the same thing.

I wouldn't worry about the complaints of it being too complicated/spaghetti stringy. It only really gets that way if your trying to do complicated stuff. The closer this is to UDK's material editor, the better.

I see that you have plans for a cook-torrence and oren-nayar lighting models. What are the odds that we would have the ability to build real, energy conserving, physically based materials?

Hurry up and finish this so I can throw money at you!

 

I just meant that if you can get exactly the same effect using vertex offset, there's no point in having a Displacement input.
So yes, you will be able to do Tesselation+Displacement.

It will support custom lighting, so I can't see why it wouldn't support physically based materials. We'll see how much will be built-in later as well.

Glad you're interested in Shader Forge!

 

Looking forward for using / buying it
Just looked at the Feature list., Thumb up.

What is you time plan? End of 2013 or mid 2014 for a usable version?

 

It should release earlier than that, I would guess in about three months, perhaps

 

Very awesome to see this! Will I be able to use my own mesh to "preview" the shader? Right now I see you're using primitives. If you're looking for a beta tester let me know please.

 

Looks good. Unity's so called up coming shader editor you could be waiting another year for. You just don't know. One big thing to do is be able to specify precision and eliminate surface shaders ie use raw cg. This will go a long away to support for mobile at a decent speed. Also it should spit out clean cg code so user can add to it, for example modifying it so that it supports flipped Y on render textures.

 

Yep! It supports any mesh in the current build

Thanks! It's already generating fragment/cg shaders, and I've planned to add support for variable precision
It's not very pretty code at the moment, but I'll try to make sure it looks alright!

As for the RT flipping - It would be nice if you never had to enter the code, so preferably things like this should be under some advanced settings. Got any more things like this users would want exposed?

 

Your tool is coming along nicely despite my earlier gripes ;-) ... How are you updating the previous thumbs of the shader results in realtime? Do you have to render them in software, since you can't do shader replacement on Unity Free? Like is there some lag if you change a node that's far from the output, to update the nodes in between?

 

Thanks! The thumbs are generated from code, each is its own Texture2D, so I basically have two sets of instructions for each node, one for the preview parser and one for the shader code generator to read
So far I haven't experienced any issues with lag; the shader takes a little bit of time to recompile though (About 0.25 seconds).

 

A little update; filterable node browser and a time node

 

Looking good man.

 

So what's the price plan? Free like Stumpy Shader Editor or for a price?
Looking great btw.

 

Killer feature - Encode the shader configuration in a string variable that you generate per node, concat that all together and you'll have a copy and paste string from which to share shader code.

 

Apologies in advance for not reading the whole thread, but I did see a few posts that talked about spaghetti nightmares. The solution for this is pretty simple: Put minimize buttons on a corner on every node. The button minimizes all of the nodes that input into it that are not connected to another maximized node. I hope that makes sense (and that no one else already mentioned a similar idea).
I don't really have experience with shader node editors (and only basic shader experience), but I could imagine the ability to code custom nodes might also be useful.

 

Does this tool generate surface shaders or regular cg? like, does it optimize or does it possibly output some bloat stuff?

 

Most likely somewhere in the $50-$100 range, not sure yet!

It's generating CG/Fragment shaders! I haven't added the optimizations yet. That said, Unitys optimizer seems to handle most cases.
I'll still make my own optimizations though, just for readability of the code

 

Alpha clipping / Cutout is now implemented!

 

Hats off to your great work, looking forward to this one

 

This is great to see... As someone who used Strumpy before, this is a great thing to see finally come to Unity.

 

Very amazing work man Keep it up.

 

Will you also be supporting the alpha channels full range? And for things for SSS, will you be supporting features such as depth maps (Guessing that is the what the transmission mask is for), secondary gloss maps, and IBL?

 

If, by "alpha channels full range" you mean transparency, then yes

I'll try to go as far as I can as for depth maps go, they are a bit tricky! IBL will most likely be supported.
What's a secondary gloss map? (Currently it supports gloss and specular)

 

Was thinking of the skin shader for offline renderers which use two layer specular. And the depth map is for scattering in the skin. One issue that may arise is using SSS with light probes which kill off details in the normal map.

 

@Acegikmo
This is looking wonderfull ! And I must admit that when ever I see visual node programming thread my eyes get bigger.

I am sorry if I will abuse this thread a little bit.
I read a long post made by imaginaryhuman about visual programming issue.
And it has a lot of good points:
imaginaryhuman

First of all lets say that if You want to program something You must know how to program. Period. No fancy looking tool will do it for you. You must really know what are you doing in the first place. But how will You do it is something totally different.

And it can be regarded as the kind of thought processes

Yes, it is much easier to type with the text editor code for multiplying or adding, then to connect couple of nodes.
Adding and multiplying is just a tiny fragment of the whole program. You can implement it once with nodes and reused it millions of time. Like it was done with assembler, or FORTRAN or PASCAL.You don`t need to type 0 and 1 in the punching cards.

Yes, visual programming can get messy very quickly. But it depends on Your skill.

When You start to program a complex structure, and when You need to change something after three months of programming, or two years after you finished Your work, what would be your choice?
To go through the pages of codes, like reading the books from the library, or to have a tree with branches with snippets of code instead of leaves. Where you can visually monitor your program execution?

I believe that visual programming is a next step of evolution of computer languages. And with each step we gained new horizons in our though processes. You couldn't imagine an OO paradigm with assembler. That doesn't mean that assembler is not needed any more.

I know that there are different opinions about this subject, just being programmer and not an artist I found that when You need to create and maintain complex application, visual programming can be a good choice.

P.S. here are couple of my spaghetti :

 

I've now added a slider node with adjustable min/max, updating in real-time, connectable to any part of your shader tree

 

Looking great man..Keep it up, we need this in unity like yesterday

 

This is amazing keep up the great work