2019.1 ShaderGraph custom nodes (poll, please vote !)

(I hope this is the right place to set this kind of poll)

As many of you probably know, in 2019.1b, Unity has changed the ShaderGraph API and how custom nodes work.

Custom nodes in 2018.x
The ShaderGraph API was public and you could extend it to add your own:

• custom nodes with custom UI for your nodes, like they do here

• add new master nodes to suit your needs (SimpleLit, ToonLit, built-in SSS ...etc)
• basically do anything in C# you could think of, before and during the shader is generated

Custom nodes in 2019.x
The ShaderGraph API is closed (internal) so you can't develop any of the feature mentioned above. However they added a new the ability to code directly in the graph or by including an HLSL file.

• this is awesome, especially for people that aren't familiar with C# and just want to try stuff or copy paste a function from the Internet

I think both functionalities are useful and target different audiences.
An artist or someone learning shaders might use the 2019.x way, whereas someone that creates nodes and tools for its artists to use might need the 2018.x API.
The rest of the Unity Editor API is really extensible so you can do custom UI for your scripts the same way Unity's doing it. Why isn't it the same in ShaderGraph ?

If like me, you are interested in doing custom UI nodes and C# in general, please vote in the poll so we can show Unity devs working on ShaderGraph that the open-API is important to us.
You can also comment and provide your own use case, that would be awesome !

Important: this isn't a place to rant against Unity devs. I love ShaderGraph and Unity in general and I thank the devs for giving me such a great tool. I think the new custom node code is really useful and will be used by many people. I just want to provide them with different use cases.

 

I also agree with ph_ in that we need *some* way of creating custom nodes and master nodes in C#.

To be honest, I have not looked that much into 2019's new way of dealing with the nodes, so I'm sure there's a good reason for it AND this new version actually looks kind of useful in some cases. I actually like it for prototyping shader code ideas quickly. But I still think there needs to be someway to 'package' up those custom nodes properly and provide some sort of custom GUI for ease of use to the artists like what ph_ shown above.

My other issue is for the ability to create a master node. I'm just starting to build my own custom "master nodes" in order to be able to do some specialized stuff for my game. If that goes away in 2019 -- I'll have to rethink my strategy going forward

Thanks!

 

I second this, for sure, as we have written custom master node / custom template based on 2018 API.

When I asked LWRP team about LWRP & SG migration path, I actually meant these API changes, which I knew before writing our own custom master node: our code are 100% going to break when upgrading to 5.x, unless SG team offers some migration path.

My understanding: Matt Dean is giving a talk at GDC on Shader Graph changes. I would love to hear what he has to say on this issue.

 

Same, what I would give to have access to this talk online !

 

To be specific: I didn't enjoy the API in 4.x, which I had outlined in a few posts. BUT they worked, which was the important part, as 4.x development was already winding down by the time we were using it in production.

So 4.x API was not great, but it's better than the status quo, which AFAIK, is no custom node in c#?

also cc @Andre_Mcgrail and @Kink3d for comments, thx for your hard work!

 

+1 with the "At least it worked". I don't mind rewriting everything I did to make it work with a new API, as long as it's doable and it works.
Also I hoped it shown enough in my original post but I love ShaderGraph and it revolutionized how I work with artists

 

I wish there was some way to mark a method as "use at your own risk". I can understand wanting to reduce the API footprint to reduce 3rd party asset breakage in future upgrades but that shows scant regard for those of us happy to accept the risk of future breakage as a necessary tradeoff. I often miss Python's philosophy on private methods: "We're all consenting adults here".

(I know there's various funky ways to get round private methods. I guess that's what we should be doing here)

 

I really need loop/convolution/continuous addition of multiplication nodes.

 

I mentioned this in the official Unity discord but I'll mention it here as well:

I answered "No, I don't think the 2018.x API is needed." because you will be able to do similar thing on 2019.x eventually. We got custom function nodes now on SG 5.8+, we got nested sub graphs, we will get subgraph input style customization later on. Even today you can build everything with custom function nodes and subgraphs but will not be able to make the node controls as fancy looking yet.

With all these combined, we can craft similar reusable subgraph nodes using the SG with zero c# code needed. I don't really see the issue with this new approach, but I do think the old 2018.x SG custom node approach was messy, I'm more happy where the things are going right now.

 

You can do a lot with the subgraph and and custom function node but not everything. I have some shaders that uses instanced indirect rendering and that needs an extra setup function reading data from a structured buffer and also a #pragma to set up this. With the custom node this could be injected in the shader but that does not work with the sub graph.

 

Serious questions:

- Can you make custom master node in 5.x / 6.x?
- Can you insert your own compile keyword in 5.x / 6.x?
- Can you create a custom inject point in 5.x / 6.x?

Here is an example of my custom ShaderGraph template:

Code (CSharp):

1.     //--- properties ---//
2. ${Props}
3.  
4.     struct VertexInput
5.     {
6.         //--- vertex input ---//
7. ${VertexInputStruct}
8.         UNITY_VERTEX_INPUT_INSTANCE_ID
9.     };
10.  
11.     struct VertexOutput
12.     {
13.         //--- vertex output ---//
14. ${VertexOutputStruct}
15.         UNITY_VERTEX_INPUT_INSTANCE_ID
16.     };
17.  
18.     struct VertexFunctionOutput {
19.         //--- vertex function output --//
20. ${VertexFunctionOutputStruct}
21.     };

As you can see I have full control on just about everything. That because I have rewrite SubShader generation process.

(Basically, I have created ShaderGraph 4.x custom master node to behave more or less like Amplify Shader Editor's templates.)

I haven't looked too deep into 5.x / 6.x, last time I checked, these interfaces (such as ISubShader) are no longer public, aka not extensible.

 

Why not? couldn't you just use Custom Function node to include a shader that has these setup? I kinda did this with global parameters here:
https://github.com/0lento/OcclusionProbes/blob/package.hd/Include/OcclusionProbes.cginc

I then just call that function from my subgraph using custom function node and since the whole file gets included, the global parameters work in the final shader too without having to expose them manually in SG.

I think you are referring to:
https://github.com/AwesomeTechnolog...haderGraphNodes/blob/master/IndirectNodeHD.cs

I don't see why you couldn't do this the same way?

 

no idea

 

Adding the include file is possible but all the #pragmas has to be in the main shader file.

But even if they add a way to add custom pragmas like ASE does it is still messy with the include file that has to be there. where with the custom node the result shader had all the needed code.

EDIT: I guess an option on the custom function node to "inline" the code in the include file would fix the pragma problem.

 

Ah I understand your issue now. Tbh the old approach you had was bit hacky too, would be nice to have way to add custom code for the master node itself somehow so you'd not have to inject dummy code to get the thing included..

 

I agree, but at least it was possible...

Lennart

 

+1; and let's say they implement everything through shadergraph's UI (which is basically the whole C# language + Unity API at this point, but anyway), why not remove the old API only when the new one is available ?
Usually they even give you a bit of time where the old API is obsolete and then new one is there, and eventually they remove the obsolete one.
In this case they removed the old API without even saying if there's going to be a feature-complete replacement !

 

Have a look at this post.

Lennart

 

I didn't see this thanks.
However, it isn't really good news to me. They say "Everything you've created with CodeFunctionNode will be convertable".
Like @bitinn , a lot of my work is done in custom master nodes, or using AbstractMaterialNode (CodeFunctionNode's base class). I did so because inheriting from CodeFunctionNode's wasn't allowing me to do what I wanted.
As an exemple, MOST of their nodes aren't inheriting from CodeFunctionNode but from AbstractMaterialNode instead because they use custom UI or other stuff.

 

Then you are probably left to cheating...
Edit manually or make a small Utility that monitors and and edits the assemblyinfo.cs file in the PackageCache folder.
Add in your own AssemblyDefinitionFile name here and you get full access.

Code (csharp):

1.  
2. using System.Runtime.CompilerServices;
3.  
4. [assembly: InternalsVisibleTo("MyCustomShaderGraphNodes")]
5. [assembly: InternalsVisibleTo("Unity.ShaderGraph.Editor.Tests")]
6. [assembly: InternalsVisibleTo("Unity.RenderPipelines.Lightweight.Editor")]
7. [assembly: InternalsVisibleTo("Unity.RenderPipelines.HighDefinition.Editor")]
8.  

Edit:
You could probably make a small editor script with a separate assembly definition file. This would compile even if your code does not and it could use the InitializeOnLoadAttribut to run and add your assembly if not present.