Convert to SRP Low End

How do I convert my project to the Low End SRP?

 

Thanks! I must say that documentation about this SRP thing is a bit all over the place though.

 

Is the low end pipeline mature in that if I start converting my project now, do I run into trouble later?

 

From the documentation:

However, nothing related to the lightweight pipeline is present in beta 4. It looks like the GIT repo still needs to be downloaded and added to the project folder.

 

Mind you, this whole stuff is still in preview.

 

How do I convert a custom unlit shader to be compatible with the Low End pipeline?

 

Historically Unity has changed the lighting pipeline quite often during the 5.0 cycle, requiring UAS authors who do not use a surface shader to update their lighting code with each new version. In my experience, this takes a lot of time, because Unity does not document this code or even really tell you what changed. You're left diffing shader files and trying to figure out what changed. In response to this, all of my newer projects used surface shaders exclusively and lived with their limitations, because the support cost of doing anything else is just too high.

As there is no more surface shader abstraction, how can asset authors who don't want to use a shader graph due to it's immense limitations avoid making SRP support a 2x nightmare compared to the previous pipeline?

 

Wait, can we not write shaders by code for SRP? If not , that is really a step backwards...

 

Oh no, you can- but you're going to have to write them without the surface shader abstraction, and once for each SRP that you want to support, which makes them much more troublesome to write and support over multiple versions of Unity. This is particularly problematic if you publish on the UAS. IE: Unity adds a new feature to the lighting engine in 2018.3, and you have to change all your shaders around in such a way that they work on the old and new pipeline, or have two different versions which need to be maintained. You will also be expected to support the traditional pipeline, LD, and HD by users, which means writing and maintaining three separate versions of your shaders, despite the fact that all three of those pipelines could be easily covered by a surface shader like abstraction (they all have the same inputs to the lighting equations).

The only way around this is to use the new shader graph (which doesn't work for the old pipeline, but abstracts LD/HD so you can run the shader on both).

IMO, a text based abstraction for the pipelines should have been available, with the graph built on top of that as a separate system, rather than having the graph also be the abstraction layer. This would have allowed SRP authors to make new SRPs which are automatically compatible with existing libraries of surface shaders, unless their SRP is so different that it doesn't conform to standard PBR style texturing (a possibility, but I suspect most will conform). This would have helped make a market on the UAS for SRPs while also making it much easier to write and support shaders for the UAS.

 

I see now, from reading this I think I have been looking at shaders all wrong from a learning approach.

I have been trying to learn vertex + fragment with the idea that surface shaders were in some way more complicated, or "not preferred" method. I now am realizing this is the opposite to the case. I've been really struggling to write a accumulation shader with vertex + frag but I think Ill be alright using surface, from what I have just seen in the docs as it looks like I can still write a vert function for use with a surface shader?

Anyway, I agree that if there are abstractions at the moment for writing code that make writing shaders easier, we should maintain the same sort of level of abstraction with the new system, to ensure that developers who are invested in writing shaders for unity continue to do so.

 

Yes, surface shaders abstract a lot of complexity from you; not only lighting but pass semantics as well. Writing a complete vert/frag shader which supports all of Unity's lighting modes is very complex, and made more complex if you have to do it in a way that is compatible across multiple unity versions.

I have various issues with the particulars of the surface shader implementation (magic keywords and variable names, hidden TBN matrix, etc), but the overall level of abstraction they provide is extremely valuable, similar to what a shader graph provides, but retaining much of the power a graph cost you. I see why Unity is leery of supporting them in an SRP world, because someone might write an SRP which is extremely different from the current pipeline and not easily translated - but the two example pipelines, along with many other potential ones that are likely to be created, could use the same basic abstraction. And their shader graph will have the exact same issue anyway, so combining the abstraction layer and graph tool as one thing seems like a mistake to me. Being able to hand author shaders and code was one of the main reasons I chose Unity over UE4 for our studio.

 

That is good news because the HD pipeline causes problems with the camera rotation matrix. Considering this question remains unanswered I assume this is a bug in the HD pipeline code. Why is the camera transform system different with the HD pipeline anyway?

 

Is fog still handled the same way in a shader as with the Lagacy pipeline?

Also, is the shader upgrade manual somewhere to be found yet? I get a bunch of shader redefinition errors/warnings like: