UPR without shader graph

I want to use universal render pipeline but can't stand shader graph. It takes me 30-40 minutes to come close to what I can type in a minute.

Code (CSharp):

1.  
2. void surf (Input IN, inout SurfaceOutputStandard o)
3.         {
4.             half rim = 1 - saturate(dot(normalize(IN.viewDir), o.Normal));
5.             if (rim > _RimFlipThreshold)
6.             {
7.                 rim = 1 - rim + _RimFlipThreshold;
8.             }
9.             o.Emission = _Color.rgb * pow(rim,_RimPower) * _RimLevel;
10.            
11.            
12.             // Albedo comes from a texture tinted by color
13.             fixed4 c = _Color;
14.             o.Albedo = c.rgb;
15.             // Metallic and smoothness come from slider variables
16.             o.Metallic = _Metallic;
17.             o.Smoothness = _Glossiness;
18.             o.Alpha = lerp(_MinAlpha,_MaxAlpha,clamp(dot(IN.worldPos,IN.lightDir*-1),0,1)) / 255.0 * pow(rim, _RimPower) * _RimLevel;
19.         }
20.  

How do I make this work with universal pipeline without using shader graph or old school vert and frag? I don't what to lose the simplicity of surface shaders, but don't want to use shader graph either.

 

Then you're out of luck as far as Unity is concerned. Unity is actually making shaders harder to deal with every release cycle, even if you use the shader graph, you can no longer write your own nodes for it without hacking the assembly files.

 

After you get over of some boilerplate that you need to write for vert frag, and the need to understand a couple more concepts, writing vert/frag shaders is really not that different than writing a surface shader.

Here's how to make a vert frag shader play nice with URP :

 

Until you have to support that same shader across multiple unity versions, package changes, and across multiple pipelines. Surface shaders did a lot more than only require you to write a single "pass", they protected you from complex changes to the lighting pipeline as you upgraded, automatically adding support for the newest lighting features and making sure everything was working correctly. When unity added VR support, everything just worked, and you didn't have to figure out a bunch of undocumented changes to the pipeline.

 

And also looked different in each version while Unity's BRDF was evolving in early 5.x. while my vert frag shaders looked fine (I was doing my own lighting, so).

The more Untiy features you rely on, the more you need to do the Unity dance when they decide to change things and that's all Unity features, not just shaders.

BTW, I'm not generally disagreeing with you, but Shader Graph isn't ready and does not produce fast shaders and gives you even less control than surface shaders. So if he can already write Surface Shaders, the thing that is at least doable right now, is to write his own vert frag shaders. The video I linked is a step by step on how to make vert/frag play nice with URP features (for the time being).

 

Hi! I'm having the same issue, and as far as I can tell, the only way I've found is to use vert/frag combo.
However, hlsl libraries are a bit better in URP than with the old UnityCG.cginc from legacy RP imo.

So for instance, you can simply use the vert function from 'Lit' or 'Simple Lit' shaders the same way they do, and implement the lighting model from them too in your frag function. Just include the .hlsl files you're interested in, which is what they do in their own shaders anyway.

Definitely recommend checking out the files in Packages/Universal RP/Shaders and ShaderLibraries.
Although not as convenient as the surface shaders, the Lit shader is far less daunting than the old Standard shader.
You should be good copy pasting most of the code from it and still understand what it does.

Message to Unity: You know better than anyone your shadergraph is still new, almost still experimental and full of frustrating elements. You should be tidying up the alternatives before you deprecate an old system. Not mentioning the fact that a lot of people will always prefer writing their own shaders.

 

Sounds like vert frag is it.

 

you can also use the 'custom function' node and use an hlsl function from a file
it's a bit of hassle to set up:

here's a short example

I have a file ShaderFunctions.hlsl

#ifndef SHADERFUNCTIONS_INCLUDED

#define SHADERFUNCTIONS_INCLUDED



void TerrainSlope_float(float3 worldNormal, out float output) {

float3 bf = abs(normalize(worldNormal));

bf /= dot(bf, (float3)1);

output = abs(worldNormal.y);

}

#endif

some important things to keep in mind:
make sure in your custom function node you have your variables in the exact same order and configuration,
as you have them in your function.
unfortunately you need to set up all the variables and names by hand :/

In your node you set the function to (in this case): 'TerrainSlope'
but in you hlsl file you need to type: 'TerrainSlope_float' (because its outputting float)

 

Sorry, a bit late to the party, but what do you mean? I'm pretty sure that custom nodes seemed to be working fine throughout the 2019 versions...? Am I missing something?

 

They have a node where you can plug in some HLSL and call a function, but they removed the ability to write real nodes like theirs are done, via a C# API - which is a whole lot more powerful. If you look at a simple example like my Stochastic node, which has a few options in the node API that change how the code gets written (enum choices, etc), it would turn into 21 different nodes if you tried to do it with the Custom Node option, which means 21 different little HLSL files that need to be updated any time you fix a bug or make a change. The user would also have to select the right one, instead of just using a simple menu to select an option on it.

The workaround is to hack the assembly files so you can still get access to the internal API - but closing down things like this so it's hard to extend is very un-unity like, IMO. Meanwhile they break something with each SRP on every single release, so writing traditional shaders is basically a maintenance nightmare, even if you disregard the extreme complexity vs. writing a surface shader.

 

+1 for the option to have any RP-package without the need to import shader graph as well.

 

I used to enjoy visual shading. Until I realized that it would be the bottleneck in performance. There is a limit to how many operations per pixel devices can handle. The tell tale sign came when it took minutes to update a parameter in Shader Graph. At that point I realized that the performance would be similar. And that I would have to manually add and remove portions of the shader by hand everytime I opened it with shader graph.

 

I'm still not sure why unity coupled shadergraph so tightly with the SRP. There's never a need to do that with code gen.

 

I see! I suppose an alternative hack would be to automate the HLSL updates and force rebuilds of the affected shader, but that'd be a nightmare of its own.

 

Node based tools are great to illustrate flow and components at a certain abstraction level but are really a pain when you need to code some complex math. Custom nodes which accept code are great for this however they are not yet available in the vertex stage so currently many shaders cannot be replicated with shader graph. This is planned for the future though.
Ideally I’d like to have a “code” view in which we can just see the generated code linked to each node with an option to override just the tiny pieces directly - basically allowing us to switch any node to a custom node type.