Is there an equivalent of Create > Shader > Standard Surface Shader for LWRP yet?
Writing a whole Lit shader is too much of a PITA to maintain and ShaderGraph still doesn’t have the features I need (keyword support mostly).
If there isn’t support for custom (but simplified) shaders yet, will there be in the foreseeable future?
Is keyword support in the cards for ShaderGraph? (I hope so cos keywords are too powerful a feature to leave out completely.)
I pushed for a Surface Shader 2.0 replacement several times, because as an assert store author, it’s very hard to maintain compatibility through multiple undocumented changes to the lighting pipeline. And this is proving out to be even harder in an SRP/Package Manager world, because there’s no conditional compiles around packages like you get with Unity versions.
As an example, I wrote an adapter for MicroSplat with LWRP when it was on the 3.0 branch. It’s not compatible with 4.0.1’s changes, and there are all kinds of issues with this:
No notification that Unity has updated or changed that code. With major Unity versions, you know to test a beta- but with Packages, things happen any time with no warning.
No documentation about the changes. This is usual for shader changes, but still sucks.
No #define for package versions, so I have to rewrite my asset for 4.01 and abandon support for 3.0
No way to handle package version from the asset store, so users have no way of knowing what’s required or works
Meanwhile, surface shader level abstractions allowed us to write shaders that automatically upgraded through lighting system changes, while abstracting pass and low level semantics from the user. Ideally, Unity would have written SS2.0, then written a graph to sit on top of those abstractions, as they need to perform basically the same job.
And to my mind a lot (if not all) of those issues could be averted if ShaderGraph supported keywords. It’s pretty obvious that SG is there to replace the auto-upgrading shaders to match updated APIs but it’s missing one of the best tools to make multiple similar shaders managable (I have 4 shaders that would require 16-32 shader graphs each to implement as they are now).
Should be relatively easy to manage on the user side by making node connections dependant on a particular keyword, though implementation in the shader graph may be trickier, but Unity are most of the way there already.
That makes the assumption that you want to write shaders in a graph, which has serious scalability issues for large shaders, and that you are ok with all the other limitations they bring. MicroSplat and MegaSplat, for instance, use a shader generation system to write shader code dynamically based on features. They have hundreds of options, which wouldn’t fit into the shader_feature system, because the number of variants which need to be generated crashes the shader compiler and takes several weeks to compile.
Forcing everyone into a shader graph is like forcing everyone to abandon C# and use the graph once the new visual script system comes out.
