How do I convert my project to the Low End SRP?
2 Likes
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.
1 Like
How do I convert a custom unlit shader to be compatible with the Low End pipeline?
The base of it will not change, some of the shader library or core SRP function may still change so doing any heavy customisation to the pipe, Including writing lit shaders that make use of the LW shader library will need adjustments later on. If you use the lightweight pipeline as is and use the shader graph as much as possible for now everything will upgrade as we continue to work on the pipeline, bear in mind visually things might change as we are still refining the features.
So the package manager has only been given a GUI in beta6 so please download that to have full access to the pipelines from within unity, they also have the new template system which will start the project in the configuration of your choice.
Currently unlit shaders work out the box in LW pipe, but there are a few things you should do to make it 100% compatible, you need to remove #include "UnityCG.cginc" as now you should use the SRP shader library, for LW pipe this means at least #include "LWRP/ShaderLibrary/Core.hlsl" and then replacing any functions that come from the legacy unity cginc, right now we donât have any concrete documentation but you can look through the new code here https://github.com/Unity-Technologies/ScriptableRenderPipeline/tree/master/ScriptableRenderPipeline/LightweightPipeline/LWRP/ShaderLibrary
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?
1 Like
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.
3 Likes
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.
1 Like
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?
Unfortunately I havenât spent a whole heap of time in the HD render pipeline as that is handled by another team, but I looked at that post of yours and I can answer what I have done in Lightweight pipe to get around the current lack of ObjectSpaceViewDir().
inline half3 ObjSpaceViewDir( in half3 posWS )
{
half3 objSpaceCameraPos = mul(GetWorldToObjectMatrix(), float4(GetCameraPositionWS(), 1)).xyz;
return objSpaceCameraPos - posWS.xyz;
}
Which is essential what was in UnityCG.cginc just using LT pipe shader library.
Again right now writing your own shaders in the pipelines is going to be very painful at the start while we get the documentation ready for the shader libraries, but the pay off of being able to have custom render pipelines and complete control over how you want to render anything is very much worth it, and for now if you donât like the idea of them donât use them, or wait till the documentation is there and shader graph is feature complete 
Legacy pipes are still in there and will be for a while.
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: