Feedback Wanted: Shader Graph

How about functionality, any features or important things missing or difficult to do?

 

Hi, really cool addition to the Unity Engine. I've NEVER coded any shader before but now i can't stop playing with Shader Graph, making simple yet good looking effects.
That said, is there a way to access the camera depth buffer? I wan't to make a intersect shader.

 

@Kink3d
I downloaded and fresh installed 2018.1.0b7 and then tried to follow your directions for using the Package Manager. I first tried by loading the Lightweight Project from an earlier beta/release (the one with the Nightmares scene) and then updating first the pipelines.lightweight (which was 0.1.29) and it failed (a conflict message, see below). I also tried loading core for the rendering pipeline (failed/conflict) and shader graph (failed/conflict.)

So I tried downloading and installing Unity Hub. Then created a new project using lightweight preview template. Then doing the package manager. It now said the shader graph was at version 17, but lightweight pipeline was only at 21. I tried updating it to .29 (only update choice) and again it failed.

Since the template does not really have much, I reopened Lightweight project/Nightmares and found that the shader graph does have the new logic nodes. I didn't try them yet, but they are there.

However, that still means I'm at .21 not .28 (or rather 29). So I am unable to get to the version you say is needed.
Also, this thread is awfully long and it's difficult to find your release notes for shader graph. Do you suppose you could move them all to one spot? Or are they already in one spot somewhere for easier reference?

Here is the error that I got on all variants (for all three items mentioned):
Cannot perform upm operation: Unable to add package [com.unity.render-pipelines.lightweight@0.1.29]:
A confict has been found for package `com.unity.postprocessing` required by:
com.unity.render-pipelines.core@0.1.21
com.unity.render-pipelines.lightweight@0.1.29 [Conflict]
UnityEditor.EditorApplication:Internal_CallUpdateFunctions()

 

I'm trying to create an Editor Window with a button that opens a specific Shader Graph asset in the Graph Editor. I know how to display the Editor Window and the button, but if I want that button to open up the Shader Graph in the Graph Editor window, what would I have to do?

Also, will there be any node documentation released during the beta? Because certain nodes like the Math nodes, I can google it to find out what each node does. Plus there's already documentation available on that on the Wiki page of the Shader Graph repo. But for nodes like Position, for example, I'm not sure what to google.

 

For the Nightmare project, you will have to delete the "UnityShaderEditor" and "New Nodes" folders. These folders contain the "Old v0.1.9" shader graph before the package manager now at "v0.1.17". Now that you are using the package manager to get the shader graph it's conflicting with the old graph in that folder.

Templates would be best to start to a rather clean project with less clutter in your asset folder. You can then import the texture files from the nightmare project if you want. If you do it this way, it's best to update the manifest file then open your project. If you update from the package manager everything will be pink after and you will have to close the project, delete your library folder and when you reopen the project it will recreate the library and it will be good.
(This will probably be fixed pretty soon)

 

Position node is pretty straightforward however some nodes in the editor have different naming from other shader editors.

For instance

World Normal - Other Shader Editors
Normal Vector (Change/set Space - World) - Shader Graph

So for new users who haven't used a shader graph before to know what the nodes do will find it hard following tutorials/documentation made with other shader graphs.
(Had to mention that for whats next since currently there isn't a full documentation for the Shader Graph yet.)

For now, you can use existing shader graphs documentation from

Existing Unity shader graphs documentation
Amplify Shader Editor - http://wiki.amplify.pt/index.php?title=Unity_Products:Amplify_Shader_Editor/Nodes
Shader Forge - http://acegikmo.com/shaderforge/nodes/

and also UE4's

(Remember to keep in mind the naming/UI differences)

 

@Grimreaper358 Thanks! Appreciate the info. Surely gonna look at these sources for more info!

 

Hey guys, something weird happened to me:
I was playing with the shader graph tool trying to recreate some water shaders from a Unity Package. But suddenly Unity stopped working for a bit and then when it came back the shader graph tool was really dark. I tried using realtime lightning and even baking a lightmap with no results (jk, a bad one btw).
It has been like this since yesterday. I have already reinstalled Unity and also reimported the shader graph sample project. Any ideas?

 

Ok so I'm sure I have a misunderstanding of how the Position node works, so I'm hoping someone can help me understand what's going on here. In this shader graph I have the following nodes:
Vector3 -> Split -> Add
Position -> Split -> Add

In the image you can see which fields are connected where.
What I don't understand is, if Vector3 outputs a Vector3 and Position outputs a Vector3, how is it that:
Vector3 -> Split -> Add = One color
...but...
Position -> Split -> Add = Two colors
What am I missing here?

 

I've received mixed responses from Unity regarding this, as a few have said it was already possible to do "toon" shading in some form (such as with the custom Vector3 for lightpos) -- Unfortunately, now I'm unclear as to the way to integrate a custom shader to do this, especially via Shader Graph, since, from what I've read from users like @jbooth (and correct me if I'm wrong for misinterpreting the problem as I've only had time to do a cursory glance over the thread), it is currently not possible to use code-based shaders with Shader Graph now. Am I correct to assume that the reason for this is that we can only either have one (code-based shader) or the other (Shader Graph shader) as the selected shader solution for Unity rendering pipeline atm?

What is the (current and potential) target ETA on the "Custom Master Node" being implemented into Shader Graph, and what form might it take (code/script or another graph) --



Regarding a toon shading solution:

I'm also curious how this new "Custom Master Node" might help with custom (and multiple!) lighting solutions like toon shading requires (solutions that include things like light direction, ramp gradients, color gradients for said ramp, perhaps an optional texture to define said ramp gradient, and falloff intensity gradients perhaps that define how quickly light gives way to shadow across the gradient). Also the ability to use multiple normals on the model would be useful too for more control over outlines in one normal set, and and then where (and how) light falls across the model (stored in another set of normals) to give the user more control over their lighting.

It really seems like this sort of thing should be included in the standard lighting options in the main master node (perhaps as specific toon shading options), and anything more extraneous would be a custom node (as the former suggestion will cover 80% of most toon-based styles -- and anything else will be specialized in a custom node, like the Disney painterly effect in the Guilty Gear Xrd thread I posted previously.) Currently, the way Unity works, the toon style is hard to produce effectively due to the lack of a separate set of normals, multiple light sources, and control over the gradient ramp, texture, and each color of that ramp.

 

Thanks for the info! It's definitely a good starting point for me in trying to understand the outputs a little better.

 

Specular AA is usually implemented as a roughness texture pre-processing step, and not anything unique in the shader or pipeline. There are of course some games that do it as a post process on the gbuffer, but I'm not sure if there's a benefit to that over processing the textures, apart from reducing some import time.

Certainly different pipelines / graphs could store the roughness in different channels, and the type of processing changes based on the specular lobe, but it'd be amazing to have a straight forward framework in place for this that's a little more explicit than an asset post processer and file name suffixes.

 

And if shader graphs will be packing textures, it could be done there, nicely specific. I read that some kind of pre packing thing was being worked on.

 

Hello

Gaussian blur would be a great mathematical function for post processing textures with the shader graph. Is there currently any similar way to do gaussian blur with the shader graph?
It would also be awesome to be able to implement own mathematical functions and use them in den shader graph.

 

Apologize if this has been asked already, but from what I can tell, the Shader Graph is not backwards compatible with respect to pre-existing shaders, i.e. the Shader Graph will not intelligently decompose an existing shader into a graph representing its constituent elements(?)

 

i did this: https://gyazo.com/1de0fb99ebb0792eb1c30d505613f02b

 

This is such a mess... maybe it is time to deprecate Unity? Other Engines have material editors that are stable and working for years, supporting tesselation, terrain coordinates, vertex animation and only one pipeline for all platforms... you can create a terrain material in 2 min, or an animated water plane with underwater. This SRP sounds like very amateur. What pro studio will use something in such a state of development. Have you used the material editor from UE4 once for example? What about the compatibility with what was done before? Do you realize the problem? All PBR materials will become obsolete? How many assets will be affected? How many projects under development will be broken? It is like if you ask everyone to start their project from scratch.
I think it is doomsday for Unity. I am very sorry about that.

 

Except that they have been saying the exact opposite of that., recommending that existing projects stay on the legacy renderer.

 

I think the exact opposite of what your saying, but okay. Ive used UE4, your comparing some drastically different capabilities.

 

I feel like toon shading options are being left out in the cold (in almost all game engines) in favor of the pretty PBR stuff. -- But just like anything nice and shiny, people eventually get tired of looking at it and find themselves wanting something different.

This is of the utmost importance to game-development.


To be capable of supporting toon-style options (in both the Forward and PBR/HD-based approaches) would ensure Unity is future-proofed for this eventuality, not to mention that support for manipulation of the core lighting (even if it required a separate, slightly-different GUI) would be really useful to those of us experimenting with newer, awesome (and wildly-different) styles of rendering in shaders than what you see or know now. You have seen the kind of stuff artists can do if given the right tools -- All I ask is that you give us the tools!

The time is now (during the initial tool development/design process) to include support for this type of feature into Unity's pipeline. Trying to integrate something this closely with the core rendering of accessing lights/etc. will be much more difficult later on. Despite the additional work and design overhead it might require right now -- it will ultimately be worth it, to everyone involved, in the longrun.


-- I only wish you'd give this suggestion more credence. This request is not specific to toon-shading btw -- toon-shading is just a valid and useful way to test the flexibility of your lighting pipeline tool's design -- and currently, that flexibility is not yet to Unity standards -- especially if it cannot do what I ask of it now. Just imagine all those amazing ideas people have in the future that want to do this kind of thing (and more!) only to find out that, "meh... Unity just can't do it..."

Unity is the central powerhouse of technical-accomplishment for imaginative and inspirational artist-friendly tools -- I want to see it continue to live up to that. -- Please don't miss the mark with this one.

 

can you replace a node with another node?

say you connected multiply with few nodes,
but would like to change it to subtract? (and keep connections)

 

@izym: Yes, my intention is to blur textures. Is there any way to do this at the moment?

Working with the shader graph for some time something different also came to my mind: A great feature would be to be able to integrate a shader graph or sub shader graph into regular shader code or the other way round.

 

You're absolutely welcome -- you guys are enabling lots of possibilities I didn't think would ever make it into Unity for a very long time (if at all!) so just know that I totally support you guys and the enormous task you have at hand!

I'm really glad to hear custom lighting and tighter rendering pipeline integration is in the cards! -- It's a challenge to make something both powerful /and/ accessible to artists since we tend to prefer that power also be intuitive (especially for a general-purpose tool.)


On the UI front, I don't know if it will help you guys but here's my two cents:

If there were ever a way to simplify the task of providing power and simplicity from the UI front, it would be to distinguish the various functionality into more "blob-like" groups of smaller modular functions that exist at a specific point in the pipeline. A good example is a typical shader -- it usually consists of only a few actual workflow elements (perhaps visualized as tabs):

1. handling vertex positioning (including normal manipulation/editing, possibly with inputs from other elements such as a texture map or RGBA channels from "texture manipulation" tab's data),
   
2. texture manipulation (including image-based pixel-coloring and UV placement, how normals affect the output of texture images, RGBA channels of an image/texture/vector with tools to normalize their output for use in other nodes/tabs),
   
3. lighting scenarios to act upon the texture images, uv, and vertex position information (such as the number of lights, their colors, positions, orientations, what textures/uvs they affect, how normals affect the output of light, etc.),
   
4. and of course output to the screen (depth-sorting, transparency, tossing any unnecessary pixels, handling any vertex coloring independent of texture information while also being mindful that some vertex coloring and positioning informs texture information of course (say in a second pass), so allow for that too, but keeping things compartmentalized like this as a default is always a good idea (even if you allow bits of these elements to be used across the various "blobs" of the shader) --

Perhaps tabs on the Graph could assist in visualizing each of these "blobs" of the shader data in a more workflow-oriented fashion (which is more approachable to artists like me) so that each tab autoconnects to the other tab 'blobs' and flowchart "portals" could connect between the different tabs/blobs of workflow functionality (if for some reason you want UV or vertex position to affect the screen output texture -- which is highly-uncommon [but still possible with this approach!]) After all, a shader is nothing more than a series of steps. In the end, break those 4 elements down into "groups" and you have yourself the start of a highly-functional and highly-intuitive UI as long as you never go over about 4-5 "blobs" if you can help it -- otherwise you're missing something that would help you simplify things. There is /always/ a way to simplify things to be more intuitive, and compartmentalizing things based on workflow functionality is a great start.

Hopefully this too can help you guys!

I use this principle to design any interface I deal with, and it always works -- no matter how potentially-complex or convoluted the UI is capable of becoming. Simple and elegant can indeed come with power -- without the need for complexity -- as long as consistent grouping of these "blobs" of functionality is possible (and located in places in the user's workflow where they make sense -- and this can be determined by determining how linear or non-linear a workflow can be -- then just finding that sweet spot to mesh the two experiences!)

If you guys ever need a UI/UX designer that can handle something complex like this... I totally know a guy.

 

General use feedback @Tim-C

Compared to using other graphs I find the 2 floating windows quite distressing and would love to regulate them both to a dockable side panel, so the zoom/pan/scale of the main graph is preserved without things getting in the way. Basically these things *really* get in my way, no matter how much I zoom and pan to avoid them. I find myself spending more time moving those out of the way or zoom/panning the graph because of it.

Essentially they aren't saving real estate because whatever they do reveal around them is largely worthless without more space. So please consider the ability to dock both floaters out of harms way.

TLDR: amplify and unreal keep the graph area entirely clean from any of that, there are no overlaid windows.

 

Could you add a WebCamTexture node for the input as well as a MovieTexture. It would be fun to play around with these nodes to do edge detection on a live scene and so forth.

I am just trying to add lots of feature creep to your schedule.

 

Just drag the relevant texture into the material slot...

 

Just a thought, it would be really cool if there was a way to easily share your shaders with the community. I get that you could just save the file but it could be nice to have a place to showcase and share your cool shaders.

 

It is my goal to have a solid base layer, however it is created (preferably within ShaderGraph), and add an additional transparent layer on top of it.

For example I have a cylinder object, I want the cylinder to be entirely red, with a swappable transparent texture on top of it. In one case it could be a grid, in another a hexagonal texture.

I'm able to use a transparent texture in Shader Graph and swap it out, but the end result is then that I only see the 'cutout' and not the red base layer.

Hope this helps, thanks. Will try to add visual examples later on currently haven't got the material present.

 

Will there be an online shader repository where we can download lots of shaders? How will we be able to share shaders? Will the graphs be saved out as XML or JSON or something? (Is there not already an open graph file format that Unity can implement? i.e. a way to share shaders across different 3D modelling applications and game engines?)

Edit: Sorry @petey I seem to have replicated your post a bit.

@inLawsGaming Interestingly Unreal engine is introducing a new thing called "Material Layers" where you can combine shaders in layers much like layers in photoshop. It would be good if Unity copied this!

 

This is not far off from what I was suggesting with my tabs/blobs idea in my previous post -- the only difference is that Unreal's version of this automatically makes the node/noodle connections for you depending on the type of additional parameters are changed/altered in the shader that "overlays" the previous ones.

I actually think this design is better than my idea, but it'd mean almost abandoning the "single-graph" approach entirely.

This could be possible if team Unity could isolate events in each shader that relate to one another (which is actually made possible if they use my "tabbed" or "blob" elements approach (i.e. the 4 separate "layers" that deal with specific types of shader parts in a workflow -- i.e. vertex/surface position orientation (vertex locations / animations, normal directions), texture manipulation (multiply/etc. textures, uv positioning, normals manipulated by texture data, & rgba data itself), surface lighting properties (such as custom lighting situations, multiple light sources, textures that are affected by lights, texture references that pick up light color, ramp gradients for lighting, softness between the gradients, etc.), and finally the screen output portion (which handles per-pixel processing such as depth maps or anything really that affects the final blit and color of a pixel and whether or not it is drawn -- likely used to help with postprocessing effects most of all).

All of the above could easily be adapted to a "layer" system that simply takes duplicated data nodes across the 4 tabs and simply "links" portions of any two shaders' duplicated nodes (nodes that exist in a particular workflow tab/element in the Shader Graph) into a "layer" system that can be told on a per-shader and per-tab/element level that the effect of this element/group should be ignored/added/multiplied to other shaders it would combine with (and how many times to allow this combination to happen, since you probably don't want it happening but once or twice in most cases before the effect becomes too strong or diluted) --

This essentially would ensure the output of a final (highly-modular) shader that could be shared and combined with other shaders (i.e. toon lighting could be combined with a PBR shader.)

 

Unity is getting layered materials in 2018.1. HDRP has it iirc

 

Shaders are saved as a file so you can send that file to anyone (or copy to another project) who has Shader graph installed and they can open it. Only thing I think would be tricky to send would be shaders with subgraphs in them, sub graph part is kinda weird. (Might just work sending it along with the shader file)

I really like this too and hope to see something like this in at some point. Shader Graph isn't setup yet to handle it so if this was to happen it would be a while. (In unreal you have embedded materials/Sub Master graphs to work with to make the different layer - Shader graph doesn't support anything like this yet)

 

I agree with this. I was using Photoshop today and it got me thinking, if possible, a layout and UX similar to that would be ideal (Dock, Connect, Collapse, Hide, etc). Though, just being able to dock and connect panels would be fantastic enough. At the moment it's pretty annoying to resize my window and have my preview and property window disappear if the panels are placed on the right.

And, this is personal taste i guess, but can we also get rid of the rounded corners in the design? I'm talking generally, but it's at it's worst in the property panel with the huge round buttons:



I find these a little obnoxious! Idk, wouldn't it be better to adopt the reorderable list look? Or the new look you have for the things like the Post Process Effects?



But yeah, dockable/connectable panels would be fantastic. And rounded corners for panels should go, imo.

 

Unity bought many asset store tools and integrate in in side already and working on many. Why unity building this and not buying and adding Shader Forge or Amplify Shader in save time of their engineers?
Same way there are many VS solutions already in store, than why to put it on road map and not just buy any that works best and add it in unity and spend time on polishing it and making more powerful?
I am not against any one just not able to understand it. So please don't take it negetively.

 

Actually

Maybe the creators of Shader Forge, or Amplify Shader Editor didn't want to sell their tools to Unity? Or UT wanted to create something from the ground up that tightly integrates into Unity?

Anyway, Shader Graph sure, does look promising. Exciting times ahead!

 

Just some thoughts - not facts by any means:

Spoiler

(Spoiler so I don't junk the thread up)
SRP and graph technology means yes they could have bought Amplify if it were on sale (I won't speculate) but they would definitely have had to work harder in the long term because it is designed to support builtin first, so integrating it would be very difficult. It would likely have to remain an asset store asset.

Making a shader graph built on top of the builtin renderer's surface shader (Amplify) was also probably harder than doing a graph from scratch that supports minimal pipeline functions + usual suspects, and comes with terminology that is different to what Unity wants, angry customers ("why is it free WTF I just paid for it") etc.

Visual Scripting - hate to burst your bubble but none of the asset store solutions are ideal. Some of them could be used but it is likely all of them can be improved on, and all of them don't do what Unity wants them to do. So all of them would need a rewrite once bought by Unity regardless, it's the same work for Unity as doing it from scratch in some cases.

Unity often buys systems and hires the developers. They did it with the UI (which by large failed - creative difference can happen) and Textmesh Pro (which seems to be going very well) and a few others. Unity is not a stranger to buying.

But this has taught Unity very many valuable lessons: all the assets they'll buy will take *considerable* engineering to properly integrate. It's not: buy and flick a switch. Because all that would do is make it cheaper for you but not improve it at all. And why buy it if that's the case? no, they buy to integrate, to change the engine to suit and often this means: entire rewrite, which invalidates the point of purchasing it for some things.

So when Unity considers a purchase there's a lot of factors like if it will be quicker or better to do from scratch, will the author of the asset come with it (pointless if not) and is the author actually good enough to work at Unity.

That's my understanding of the surface of the problem, my own thoughts on it.

 

My number one thing that I would like to do is have a set of pixel shaders and a set of vertex shaders and combine them in any combination. Maybe you can do this already? Hopefully the new system will make it simpler anyway.

For example I may have a water vertex shader that creates ripples and I want to combine this with a metallic shader to create a metalic liquid effect.

BTW I am not a great artist or shader expert. This is just my perspective as an amateur so-to-speak.

 

I downloaded the latest version. Made a new PBR graph and the texture is pink. No matter what I do I can't get it to be anything else other than pink. I added my own textures and tried all the settings I could fine. I am running 2018.1 beta 7.

 

LOVE that you are putting together the shader graph. Great job so far!
I have used ue4's material editor, blender's material editor, and a few others. I can not wait until this gets complete.

Can you make it so that users can (easily) programmatically add their own nodes? Like the user could add a piece of shader code and it would get called in that node. (This would expand the shader graph huge as users could expand it.)

Also is it possible to do sub surface scattering at the moment?

Thanks Again!

 

I was wondering if it was possible to import a shader made in shader graph in a project that does not support it yet?
I tried importing the GeneratedShader.shader and the UberShader.shader from the LightweightAndShaderGraph project (they get created when compiling a .ShaderGraph) but I wasn't able to make them work on another project.
They have all the correct input textures and floats but the UberShader is always transparent and the GeneratedShader does not compile because it is missing an include "LightweightLighting.cginc".
I couldn't find this .cginc file anywhere in the Lightweight project.

Please let me know if it is possible to use the compiled shader versions of a shadergraph in another project and if so how.

Thank you for your time.

 

In Graphics Settings; do you have a Lightweight Render Pipeline setup?

 

I had it set to High Def. I changed it to Lightweight and had to manually change all my textures to use lightweight since the update program did not work. It still shows pink. I created a new pbr graph and that is still pink. I am not sure if I should start from scratch and make sure I use lightweight from the beginning.

 

Shader Graph currently only supports Lightweight Render Pipeline; so HDRP won't work.

Try making a brand new project (Using the 3D Template), importing Lightweight and Shader Graph via Package Manager and see if you get exactly the same result.

 

It worked when I went through the package manager. Thanks

 

Hi,

My biggest concern with all these shader graph systems are that there is no user-driven multi-compiling. Does Unity's solution address this?

That's the biggest strength of Unity's written shaders, allowing one to write a single shader with multiple, user-defined variants.

Anyway, thanks.

 

From twitter you can see this has been in development for a long long time

 

The shader graph got some nice attention from the unity blog today! It's exciting to see this get rolled out. When 2018.1 is released out of beta, can we expect the shader graph documentation to come with it? It'll really speed along new users, and hopefully help folk make some custom nodes that'll hit the more complicated use cases while the next round of shader graph features come online.