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.
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.
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
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
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!
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.
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:
Print Screen of nodes i.e. similar to uScripts
The ability to create dx11 shaders
The ability to create OpenGLES GLSL for mobile CG shaders for computer or mobile
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.
.
