Is there a template to convert a very simple vertex - fragement lit shader in the HD pipeline ?

Hi,

I would like to do a first very basic conversion, to see how the base of a new HD pipeline shader works

Is there a resource that shows the equivalent of a base diffuse lit shader, like the one in the Unity documentation (https://docs.unity3d.com/Manual/SL-VertexFragmentShaderExamples.html) ?

I post the shader below

Code (csharp):

1.  
2. Shader "Lit/Diffuse With Shadows"
3. {
4.    Properties
5.    {
6.        [NoScaleOffset] _MainTex ("Texture", 2D) = "white" {}
7.    }
8.    SubShader
9.    {
10.        Pass
11.        {
12.            Tags {"LightMode"="ForwardBase"}
13.            CGPROGRAM
14.            #pragma vertex vert
15.            #pragma fragment frag
16.            #include "UnityCG.cginc"
17.            #include "Lighting.cginc"
18.  
19.            // compile shader into multiple variants, with and without shadows
20.            // (we don't care about any lightmaps yet, so skip these variants)
21.            #pragma multi_compile_fwdbase nolightmap nodirlightmap nodynlightmap novertexlight
22.            // shadow helper functions and macros
23.            #include "AutoLight.cginc"
24.  
25.            struct v2f
26.            {
27.                float2 uv : TEXCOORD0;
28.                SHADOW_COORDS(1) // put shadows data into TEXCOORD1
29.                fixed3 diff : COLOR0;
30.                fixed3 ambient : COLOR1;
31.                float4 pos : SV_POSITION;
32.            };
33.            v2f vert (appdata_base v)
34.            {
35.                v2f o;
36.                o.pos = UnityObjectToClipPos(v.vertex);
37.                o.uv = v.texcoord;
38.                half3 worldNormal = UnityObjectToWorldNormal(v.normal);
39.                half nl = max(0, dot(worldNormal, _WorldSpaceLightPos0.xyz));
40.                o.diff = nl * _LightColor0.rgb;
41.                o.ambient = ShadeSH9(half4(worldNormal,1));
42.                // compute shadows data
43.                TRANSFER_SHADOW(o)
44.                return o;
45.            }
46.  
47.            sampler2D _MainTex;
48.  
49.            fixed4 frag (v2f i) : SV_Target
50.            {
51.                fixed4 col = tex2D(_MainTex, i.uv);
52.                // compute shadow attenuation (1.0 = fully lit, 0.0 = fully shadowed)
53.                fixed shadow = SHADOW_ATTENUATION(i);
54.                // darken light's illumination with shadow, keep ambient intact
55.                fixed3 lighting = i.diff * shadow + i.ambient;
56.                col.rgb *= lighting;
57.                return col;
58.            }
59.            ENDCG
60.        }
61.  
62.        // shadow casting support
63.        UsePass "Legacy Shaders/VertexLit/SHADOWCASTER"
64.    }
65. }
66.  

Thanks in advance.

I just need the equivalent one file that contains the vertex and fragment functions, to see the relation between the new and old pipelines, for using as base to convert my shaders.

 

Also is the method of reading texture into the vertex shader the same as in the current standard pipeline ?

 

Also will the Blits and render texture style programming work in the new pipeline, or there must be changes made in that aspect also ?

I tried to convert my volume clouds today, but i cannot get anything to work and those do not use the lighting libraries of unity at all.

It is a real nightmare of EPIC proportions to port anything to the new pipelines and i have already lost huge time to even try to do just one of the 20+ shader systems i have and with zero success.

I was planning to release another 4 major assets, which are all in advanced state, now everything is lost and all my development time has gone to waste, as it is completely impossible to convert anything more complex than a simple unit shader to the new pipelines.

This is so extremely disappointing and now i think of moving away from the store, it is just not a way to treat asset store developers, causing this extreme new requirement where every single thing has changed and is impossible to use the old code at all and even more impossible to see and understand what can replace it, to have any small chance to convert a system to the new methods.

 

Stop crying, it’s in PREVIEW(!!)

 

If it was in preview, should not have been so early in the front page of the store through the Book of the Damned, now everyone only cares for the new HDRP pipeline and should they use this, then none of the previous assets will work.

It is a bit crazy that will have 3 incompatible pipelines to begin with, preview or no preview, makes no difference, it is just too chaotic to have any practical use. I keep a RPG project for sometime now as well, besides my assets, and now is the first time that i know for sure 90% of the assets i used there will no longer work or will be totally remade and have to re implement everything, it is a huge nightmare for asset developers and long term game projects as well.

Also gives a vibe of zero trust in the store assets anymore, as now Unity forces them to break in big ways without possible recovery, unless they become new assets altogether, which is remaking everything from scratch (and now for 2 different incompatible pipelines)

I have never come across such a bad idea of handling the future of a system, i mean it is like having 3x Unity platforms now and to a big degree unrelated.

I am sure logic will prevail and the current pipeline will merge with the new HDRP one, in the sense that old code and assets will just play (without using the new pipeline features) directly, without having to remake everything.

The best idea would be to have the current pipeline directly applicable to both new Low and High quality pipelines.

 

A simple diffuse shader in the new HDRP would help a lot to at least get started on what functions to use to access equivalent to the current pipeline light features and access to the vertex shader.

 

Of course, this should be on the main page, because this is a new vector for the development of the engine and the community should move on to it gradually, and not once a day when it comes out, it would be absolutely stupid and not logical. On the forum, on the Keynote-s, and everywhere Unity warns that this preview and not for production yet, but that people gradually enter a new direction of development, besides legacy pipelines are still there and no one forcibly says to use SRP. Those who turn to him now do so at their own peril and realize that all this will not work perfectly right away. Closer to the release will be more documentation than there is now on the forum and in the github, which means it will simplify the process of migration assets, but do not expect that it will be at the click of your fingers. Even at the first presentations, they said - SRP are not for everyone, it's a more serious approach to development, which requires quite a lot of knowledge, and that's right, because for a quality product one must be able to more than poke a couple of buttons and lick the shader from the documentation.

 

I am not sure this fragmentation though is done the right way, do other engines keep 3 separate versions at all times with everything between them be incompatible ? Seems like this will create huge issues for users in general and the store assets will of course be much more complex and error prone and harder to keep for both the makers and the users.

The problem is that this should be created in a unified way, especially considering the Unity name and initial purpose to cover all platforms with a single project. Now this is totally gone, the turn Unity takes is 180 degrees and this tells me that is a very rushed decision (besides the obvious lack of any documentation).

 

No, it won't. Why? Because you mounted this horse heading backwards.
Games aren't made on the way you are describing.

Let's see a real plan:
- do we want to support desktops only with realistic gfx? -> HDRP only
- do we want to support mobiles/VR only? -> Lightweight
- do we want to support mobiles/VR and desktop with the same assets and we don't care about realistic gfx on desktop? -> Lightweight (common denominator)
- do we want to support mobiles/VR and desktop but we want realistic gfx on desktop? -> Lightweight for mobile/VR and HDRP for desktop
- do we want to support everything and we don't want to maintain two separate SRP? -> write your own SRP

If you want to maintain realistic gfx and support mobiles as well, you will need duplicates of _EVERY_ asset you have regardless of pipelines.
Nothing is stopping you to use these systems however you want, but if you are serious about a project and you actually plan what you want to do, you have to decide what to support and how you will actually do that.

---
As for the AS assets and creators:
You as an AS developer have to decide IF you want to support LWRP or HDRP. If you want, you CAN. You don't have to do that and certainly don't have to do that in one asset.
The HDRP will be powerful enough to release your assets as a separate version if you want to sell HDRP product - if your asset is worth supported on HDRP at all (which I do not have information about since I do not own any of your assets, so to evaluate this I'm not the best person).

(And you really shouldn't support HDRP just yet if the lack of documentation and/or the lack of features are getting in your way and you're complaining about things, because in case of HDRP, anything can change overnight and you will be complaining about those things as well)
If you're not willing to put the EXTRA effort in the support of HDRP, you should not start to do anything about it until they release it publicly as a finalized product (and things will change even after that, believe me, this is how software development works, we iterate, you should too).

 

But nasos is 100% correct. Fragmenting the engine into LW, HD, deferred, forward is a bizzare decision. HD pipeline has been marketed like crazy and seems to be far from a release that will help anyone making games in the near to mid term.

I'm happy to see HD in development. It needs to happen. Unity's graphics are quite far behind out if the box. I love the engine and I'd love help with graphics!

That said like most developers many of the graphics I've developed are very custom solutions. Not having any information available on HD sucks. The git hub page is pretty bare bones.

It's the best thing for the engine! But I mean ... it does 100% suck being a developer with unity if your striving for quality graphics at the moment.

 

No, it's quite sensible. And they have not fragmented Deferred and Forward. HDRP supports deferred and forward. LW supports forward and deferred is on their internal roadmap to be added at a later date.

You are also wrong with your assumption that you can't have HDRP and LWRP in the same project. But if you do that, you will giving yourself twice the amount of work, because they both have different asset requirements (textures, lighting, etc). Why do they have different requirements? Because one is designed to work on everything and look the best it can doing that, while the other is designed to look prerendered and only works with compute shaders.

Mixing them both is not actually technically possible without making HDRP fail to function.

I think it 100% is a smart, intelligent move by people with serious AAA qualifications. Just pick a SRP and be done with it. I did and I'm very happy.

 

In the years I have been using Unity, this is by far my favourite year so far. I do understand a range of negativity that some people are expressing in relation to pipelines, but I think its all great so far and I do not confuse the temporary pain during this era of open development of the pipelines, with the potential for the future, a good chunk of which has already been realised. Lots of the visual results are stunning, and many of the decisions make complete sense to me, especially now we can see some of the results.