Feedback Wanted: Shader Graph

Yup! That's exactly what I need it for. Thanks for letting me know.

 

It would be nice if the option to output high-level shader code was available as mentioned above by another user.

Node graphs are great to work with but are likely to produce inefficient code which can dramatically slow things down.

Outputting the result to HLSL/Cg would allow shader specialists to optimize the node-graph results. It's also likely that shader devs be able to help find Unity bugs and implementation flaws if the output is readable.

 

Is there any way to create new master nodes? Meaning, if we want to use a Sprite or Image as a base (or whatever else), is this something that users are able to do, or do you guys have to add in the master node types to the shader graph?

 

I'm so glad you guys are finally adding this tool! I guess I just hate plugins so anytime I can remove one it makes me feel good! I watched the video on creating a shader and it looks great, BUT you guys have to add better workflow for adding nodes. Shader Forge solves this with by far the best way. Holding a letter on the keyboard brings a list of all nodes starting with that letter that you can scroll through with the scroll wheel and then click. I use Substance Designer, Amplify Shader Editor, and Houdini all the time and I hate not having this amazing workflow feature. I can create any node in Shader Forge in probably 1 second or less without ever taking my hand off the mouse. In others, I have to hit tab or space, then bring both hands to the keyboard, type out the node I want, then hit enter or go back to the mouse and click. It may seem small, but when you are creating nodes for hours on end, it really adds up and is just frustrating when there is clearly a better solution that doesn't seem hard to implement. Please add this or at the very least do it the way Amplify Shader Editor does it.

 

Forgive me if I'm wrong but I thought the focus of SRP was to not really require a billion options in the shader editor, but give control over existing features in a flexible way... so it's less about doing huge graphs. Because looking at the HD stuff, I can see it pretty much does everything, so it would only need a minimalistic graph for nearly all use cases.

So my thinking is - go for the SRP asset that closest matches the project/shader features you need... and then further tweak with graph if you even have to.

I could be totally off base though, still getting to grips.

 

I almost never use stock Uber-shaders. Most of the projects I've shipped since the advent of programable shaders have featured mostly custom shaders for every object (or type of object) in the game.

SRP actually has little to do with what's in your shaders, it's rather a way to customize the rendering pipeline for how everything is drawn. This obviously has great ramifications on your shaders (a custom SRP might have custom shader passes it requires, for instance), but it really doesn't have that much to do with what each shader does at the pixel level. Unfortunately Unity has chosen to do away with a surface shader like abstraction and only abstract the complexity of what SRP's will require via a graph tool.

 

With regards to textures, similarly to writing actual shader coder, you need both a texture source (in this case from a Property Node) and a Texture Sampler. Whether or not this can be merged into one node is another issue of UX.

 

It would be great if we could change the look of your graph editor. Its interface looks small enough. I'm sure that it will look even smaller on high-resolution monitors (at least in Windows). Are you planning to give users the opportunity to change the look of your Shader Graph tool?

 

The biggest, most glaring issue I have with the new shader graph is the lack of shortcut support. Consider adding shortcut implementation similar to Shader Forge or UE4's material editor, it'll save a lot of time for everyone involved

 

very nice! I really like the simplicity of the UI. Can't wait to try it out.

 

Hi, great to see this being implemented!

One small question, how would you handle the interface for choosing HDR color over an LDR color? Or is this already possible and am I missing something?

 

@Laurens-Paladin-Studios HDR Color is currently a separate node but it is not available yet. Its in a PR on Github waiting for approval. It might later be just an option on the Color node but first we need to determine if we will have attributes (like the HDR flag) on properties.

 

@DGordon It is absolutely possible to create your own Master nodes. Take a look at how the master nodes work in the Github linked above.

And for everyone with UX suggestions: Thanks, please keep them coming. During the beta period we will be doing a lot to improve the UX of the graph, including adding node shortcuts (in some form).

 

I already mentioned this to Tim on alpha, but I would love to see a register/get temp var feature so you can route output to it, then grab it again much later. This is in Amplify and was a totally blissful game changer - instantly untangled all spaghetti.

Another feature is of course being able to group things and leave a comment

 

@Kink3d don't forget ability to reroute node connection

also i found a bug when trying to change the uv selection it trigger selection marque and it stuck, i cannot do anything or select anything except closing the ShaderGraph(SG) window

 

I'm using UV Float3 and Float4 for aditional information for shaders - and without this, shaders simply can't work.

 

This seems like a giant step backward. Having a visual shader development tool has been a long demanded feature by a vocal subset of users, and it's good to see this finally coming to light, but to now make Shader graph the defacto way of "writing" shaders is quite frankly... bizarre thinking.

This is a case of jamming a square solution into a triangle-shaped problem hole. They really really need to take a step back and work on this whole paradigm for a while.

 

I don't think the original surface shaders we're far off the mark; they have a few too many magic keywords for my taste, but they handled the abstraction well. I think the goals for this system should be that shaders and SRPs can be independently mixed/matched without having to rewrite each other, as long as the lighting inputs (albedo/normal/occlusion/alpha/etc) between the pipelines are the same. For instance, someone might make a Dreams style renderer in SRP that only works with signed distance fields, but if you do that I don't think it's reasonable to expect things to just work.

Ideally, I think it would contain the following:

On the SRP side, a C# file which would specify how to transform the surface shader into the actual shader. This would allow the coder of the SRP to specify things like the pass semantics, parse #pragma's for special directives, etc.

On the Surface Shader side, the user would specify the structure for the application data, a vertex function, a v2f structure, and a fragment function. (Tessellation, geometry, etc eventually). I'm certainly ok with this being more verbose and manual than the original surface shaders were, such as always requiring both functions. The SRP could also provide a common structure for the lighting data it expects, like SurfaceOutputStandard, for instance.

The SRP code would have to generate the actual AppData and v2f structures from the ones provided. This is because the SRP is going to have certain things it requires, such as lighting data in vertices and needing to marshal that data through the v2f struct. It would then generate each pass, calling the user function, and then calling the lighting function or whatever it wants to do with the result of the user function. Perhaps there's some cleanup vs. the original standard shader here, which hid the data for a TBN from the user and instead had functions to do the transforms? That always seemed a little odd.

It is my understanding that code stripping works quite well in shader compilers, and that it could be relied on to strip most of the code from passes which don't use most of that data. But I know less about the dynamic compilers here- would, for instance, most of the code used in that function get stripped from the shadow pass?

Ideally a system like this abstracts the following from the user:

- Lighting semantics, both in the marshaling of data and calling of lighting functions
- Pass semantics

To be perfectly upfront, my interest in this is not about writing less code - it's about maintenance and cross-compatibility. Low level changes in the lighting pipeline have broken one of my products vertex/fragment shaders on every Unity release since 5.4, and it often takes an incredible amount of time to dig through the changes and figure out what broke, and every time I do this the code gets uglier since I still have to support the old way as well. My surfaces shader based products, however, require virtually no maintenance; they just work through every unity change, and every unity feature upgrade. From an asset store developer perspective, that is a huge win. Being able to write a new SRP and have most shaders on the store continue to work, or being able to ship a shader into the store and have it just work with custom SRPs, now that's pretty rad for the ecosystem. There will, of course, be exceptions, but I think it's a good goal.

 

BTW, the trick of using the new asset importers to do the transforms is really nice- I assume this gets refreshed when the SRP is changed causing a recompile of all shaders?

 

Oh, and on that front, the C# -> shader compiler you guys were working on seemed really interesting. If I could inherit from ShaderLit.cs and do:

Code (CSharp):

1. public override half4 ForwardPass(VertexInput i)
2. {
3.    var lightingData = MyFunc(i);
4.    return DoLighting(lightingData);
5. }
6.  
7. public override void DefferredPass(GBuffer g, VertexInput i)
8. {
9.     var lightingData = MyFunc(i);
10.     DoLighting(g, lightingData);
11. }

A whole range of bad ass stuff would start to be possible without giant towers of Macro's, conditional compiling and runtime breakage.

 

I suppose another way to approach this:

- Take a simple surface shader and see what it would take to get it to compile under the LD pipeline.

The current surface shader is a format that's well known. It shares the same lighting inputs with the LD and HD pipelines. With it, the user writes a function they expect to be used on the vertex and fragment stages.

I'm betting you could get pretty far without changing it at all, making tons of shaders instantly backwards compatible. If there are specific semantics that should be changed, change them, but most of the potential use cases are already well worn.

 

On the other side of the wall is me - someone who rolled all his own shaders, did all his own lighting from 2010 up until Unity 5 came out then I stopped. Too much work. And I don't really want to rely on asset store. I want to be able to handle my own jobs and the current design of SRP is beyond perfect for people in my situation.

Granted it's a major pain for asset authors but I can see a situation developing where potentially, it's going to be a lot of crap heaped on with macro keyword hell again, so perhaps it's actually worth waiting and doing it properly with C#->shader - that's something I might even have time for.

 

+1 for getting a float4 from uv.

 

This is exactly what we do at work- we have our own lighting, etc. SRP is going to be great for that- but I wear another hat when I'm not at work. That said, there is some intersection there since we currently use surface shaders and a surface shader generator we call 'shader stack' for our UI shaders (it's a photoshop based paradigm for making UI shaders).

 

talking about surface shaders 2.0 i would highly appreciate if we had full access to all members of the vertex to fragment structure within the surface function such as "WorldSpaceBiTangent" or "position" and the derived data like "tangentSpaceTransform" and "TangentSpaceViewDirection" of course – not only the few like today.

 

Yes, they are "hidden but usable via magic functions", which is pretty annoying. I've definitely done a bunch of hoop jumping because of those types of things. A lot of this was done so you could strip them out when not using normal mapping, etc. I think if we re-examined the current low-end cases, things could likely be simplified a bit for the sake of ease of use and code clarity. Our next game will forsake openGLES2.0 devices all together, so we're getting to the point where even those of us who have to support 'low end' devices are going to be using decent APIs, etc.

 

I have tried it out and it works well.
But I noticed one node that is not yet there and that is a node to animate textures using UV. I have been using the UE4 mat editor for quite some while and they have a node called Panner that is used to animate textures.I wanted to know if this feature is available and I have not noticed it or are there future plans to add it?
Good work though, Keep it up!

 

@utsav55501 I believe the node you are looking for is "Tiling and Offset" under the UV category. Use the offset input to scroll UVs. If you want to animate using a "texture sheet" (sprites for example) use the Flipbook node.

 

FWIW I sometimes pack extra data into meshes for shaders if they will need an effect. I abuse tangents and colour, but sometimes I need both tangents and colour so I can't. The authoring is done in Unity in my case (effects). And in my case, not particles.

 

Here's the one I wrote:

https://github.com/slipster216/VertexPaint

Lets you paint just about anything into all 4 UVs, with all treated as float4. Same painter I use in MegaSplat, which stores splat weights, stream/lava weights, etc in UVs..

 

Currently, if i made changes in subgraph, graphs in which this subgraph exist do not updates and i need to resave them manually. Is this expected behaviour? I would like to use subgraphs for material inheritance and layering but i would like to have realtime updates if i made changes in parent graph.

 

Is there a node that allows for combining multiple Floats into say, a Vector3? I'm currently trying to make a Vector2 out of the X- and Z-values of a Vector3, but I can't find a node that would allow me to do so.

 

Oh man, I'm loving this thing!
I recently spent the better part of a day figuring out how to code a specific shader, and I was able to get the same exact result in about 10 minutes with this new system! I am super glad that Unity is finally taking bigger steps in the visual department out of the box!

If I were to throw my 2 cents in, one of my favorite features about Blender's node system is being able to unplug/rearrange/swap connections like so: http://i.imgur.com/hrRA4RL.gif
The way it currently works, dragging out from an input socket with an existing connection just gives you the option to replace it with a new input node. I think that's still a good feature if the socket is empty, but I think in most cases (at least personally, others may vary), being able to quickly rearrange/swap connections is way more useful and efficient.

A couple other little things I noticed were in the properties panel; With Vector2, 3, and 4, you get the fine tuning handles next to the values, but it's absent when you have a float. Additionally, it would be nice to have a range slider implemented as a property, like you can do by coding shaders - and I know you could just route a float into a clamp node, but the slider would be a lot nicer to have.

Also - Are materials for the Sprite Renderer not supported yet or am I missing something? I'd love to use this in UI, but when I apply the material it tells me it doesn't have a _MainTex property :/

 

looks like if i convert a node to a subgraph and add a slot to it, things break consistently. It just seems like a visual issue though, closing and reopening the graph fixes it

 

Also, multiple master nodes in a graph? Is there a way to switch between them or is this just a UX issue that'll be ironed out later?

 

I'd also like to +1 the suggestion for faster node selection through shortcuts.

Shaderforge and Amplify both handle this well in their own ways. With Shaderforge you can press a key and a scrolling list will pop up with all the nodes that starts with that key (alpha-numeric).

Here I've pressed "A":



I can scroll to the specific node with the mousewheel.

Amplify simply inserts a node based on the key so there are specific nodes tied to letters and numbers. It's faster if you use common nodes, but I prefer Shaderforge since it saves more time in the long run.

And is there a way to hide this huge panel?



Takes up a lot of useful space when I don't always need to see it!

 

Is there a way to move the mesh inside the preview. It seems like it uses the mesh pivot for rotations and scaling instead of center.

 

I would love to be able to resize and/or close that panel

 

Few quality of life things in addition to a few other users suggested like
- Shortcuts for quickly creating nodes
- Pins to organize the graph
- Ability to be able to reorganize property order/appear the same way in the inspector

I know these aren't high priority compared to the work you guys have to do on the system but would be nice to have.


Ability to convert Sample Texture directly to a property. Currently you have to create and attach a property node to the Sample texture node to be able to make changes in the inspector. Maybe adding another drop down list above or below Type to change it to a property



Copy and pasting nodes - Currently this just offsets the nodes pasted a little from the original nodes. Would be nice to have the nodes be pasted wherever you mouse is at on the canvas.

 

In a newer build that's on github (Releases section - 0.1.11) you are able to resize it.

 

It is done inside unity with C#. Those scripts are a part of my CScape asset for unity:
https://www.assetstore.unity3d.com/en/#!/content/86716

 

.ShaderGraph files are json files? Why not yaml?
Just a curiosity.