[IMPORTANT]Asset store compatibility and SRP issues, for publishers and users in general

UPDATE : I believe it is very important to add this quote from @AndrewAssetStore here at the beggining of this thread (thank you very much for your answer, this is the kind of clear response we needed to give some reassurances to asset developers during this big transition!)

ORIGINAL POST

I am starting this thread hoping that we can discuss here about all the compatibility issues, workflow and potential deprecation of assets from the asset store now that Unity 2018 introduces the new rendering pipelines, the SRPs, as well as how it will affect both the end users that get those tools and us publishers that actively develop them.

For unity users that only buy assets instead of publishing them to the store, you need to know that the changes to Unity are requiring us to potentially support all 3 different pipelines, despite the fact that some of them are restricted in features and are incompatible with many current assets in the asset store, not only due to the new shader creation pipeline but also to the way the whole rendering system works. This will require all publishers to spend a considerable amount of resources and time not only to port assets to Unity 2018 but also to support them, and the currently proposed workflow by Unity will also make it considerably more difficult for end users to install assets from the asset store, as every version of the asset for every pipeline will be included in the same package (despite errors and incompatibilities between them) with the end user being responsible of picking and choosing from the folders structure which parts are designed for the pipeline in use and installing only those.

Many assets right now will not work, and will not have any purpose in the new pipelines as they were designed specifically to solve issues of the current one. There are tools with very specific purposes that are now in danger of being deprecated if we are forced to support all versions of the new SRP system.

But the Unity team has not confirmed to any of us that we will have the choice to restrict support of our assets to only one of these new rendering pipelines, for example, the mobile oriented Lightweight, or the current Standard one.

As publishers, we have made our concerns and issues known to the Unity team, but they instructed us to share them here in the public Beta forums as well, and I am also interested in letting the general users know about this, since the changes that will be introduced to Unity have a great potential for confusion, splitting the user base between three wildly different and totally incompatible pipelines, two of them with partial/ no support for custom shaders, and for which even updating 3D assets is a painfully long process that involves the creation and set up (by hand) of material variations, demo scenes and demo projects for each pipeline.

I open this thread so both sides can discuss here and hopefully attract the attention of the Unity team in charge of this change, to get clearer answers. This is a very big change, a change that they are requiring us to make, without enough information, answers, and as the Unity team told us, without any final plans. In a sense, we are jumping towards a big change, without any clear goals.

 

I don't want to dismiss any of your criticisms but I just wanted to point out that I am happy that there is 3 different pipelines. I love that the pipelines have such a tight scope. Lightweight pipeline - basic features, good performance, perfect for mobile. Advanced features are just not there, and there is no need for them, so 'Lightweight Compatible Assets' aren't going to have to worry about running on high end platforms, they can just focus on being lightweight. Also, it means that performance improvements/platform specific new tech/etc can quickly roll out to the platforms that actually use them. A Unity update that adds support for something super advanced that works on High End PC's but not on mobile has little chance to 'break' my mobile only game since I am using the Lightweight Renderer.

I think ultimately the hard separation is a good thing. Unity just needs to arm asset developers with adequate tools and guidelines to make this system easy to adopt.

I think having to write potentially 3 copies of your shader asset just comes with the territory. There should be 3 different versions to take full advantage of what each rendering pipeline offers.

 

The issue right now is not the pipelines themselves, but that Unity seems set to make it mandatory that all the publishers in the asset store support all three pipelines, without considering that some high end plugins and assets will not (and should not) work on low end platforms such as mobile.

What you describe would be an ideal scenario, but that is sadly very far from what the Unity team has described to us publishers so far. What they describe is the exact opposite of that.

As an example, if you purchase a plugin for "Simple Water for Mobile" that is made mostly for the Lightweight pipeline, the creator of said plugin will be required by Unity to support the Standard and HD pipelines as well, and by Unity's instructions, you would need to download all three versions in the same package and search carefully which parts are for the pipeline you are using.

An update came to the HD pipeline that broke the "Simple Water for Mobile" plugin? The creator needs to make a patch for it, and upload it to the store. Since all three pipelines are inside one unique package, you would receive the update as well, despite it not being intended for Lightweight users.

This is exactly the problem we discussed with the Unity team. No one is against the new pipelines themselves, we are against the way they are being introduced and the workflow they have given us so far as the intended way to update our assets for the store.

The main issue is that Unity has not even confirmed to us something as basic as "You can release an asset that is Lightweight compatible only". So far, it seems that there won't be any assets exclusively for one pipeline, but instead we will all be forced to give support and manage to port our assets for all three of them.

If this is not the case, I really want an official response from Unity to tell us just that.

Thanks for replying though!

 

Wow, Unity is requiring support of all three of their official pipelines? I suspect they will lose some asset developers as a result--at least on the official Unity store, if that requirement sticks. Seems like a better approach would be to allow developers to pick which pipelines they support, but ask that they be transparent about which pipelines are compatible with their asset(s). (Somewhat similar to asset descriptions saying whether something works in forward vs deferred right now.)

 

Sorry I misunderstood! Wow, ok, that is kind of strange. I honestly imagined a world where every rendering pipeline was treated as their own thing, as important as the Unity Version itself. Assets on the store would be marked as 'Supports Unity 2017.1 and Lightweight Renderer'.

Very strange that they are forcing developers to support all of them. Would love to hear back from Unity.

 

That was what we asked them in the developers forum. We want a new filter in the asset store, just like the one there is for the Unity version. We want the users to be able to filter out which assets are compatible with which pipeline, and for Unity to allow us to decide if we support 1, 2, or all 3 pipelines (or more, since there will also be custom made ones)-

Unfortunately, their answer was that there are no final plans about any of this, and they dont know yet if they will require us to support all pipelines or let us decide. That they dont have any information yet, nor any final plan about any of this, and that they know it will be annoying and may take months to each asset publisher to update dozens or hundreds of assets by hand. And then they sent us here, telling us that there may be someone from the team in charge of SRPs on this forum who may be able to give us an answer

So here we are....

 

Don't worry! We also thought we misunderstood them at first, but with each answer they gave it became more and more clear that this change hasn't been well thought, and that it will affect greatly the Asset Store content.

And, so far, there is not even any support for custom shaders on the new pipelines nor any indication of a way to upgrade them so...we were told to prepare for the change, without any instructions nor clear plan ahead.

That's why we want an official reply

 

This was the official reply we got and because of that, we are back here to ask for a clearer and more definitive answer. The change requested by Unity is way too big on our end, and it is not reassuring at all to know they don't have any set goals nor any specific plan ahead.

 

There are multiple things going on here that need to be made clear to people who are not publisher, or not as versed on the SRP changes. Some of these things may seem obvious, but im being concise.

1) Any shader currently in existence will only work on the standard pipeline.
2) Any shader designed for a specific pipeline will not work in any other pipeline.
3) Materials specify a shader they use. This part right here has multiple implications beyond just people who write shaders, which i will cover in a minute.
3) Prefabs point to materials, which point to shaders. This play in the same as above, an i will cover it in a moment.
4) The way the current distribution of assets work, if an asset supports more then 1 pipeline, the end user will have to be concise of what pipeline they use, and make sure to import the proper folders, an leave out the others, OR the asset developers will have to write "middleman" apps that "streamline" this process by including additional sub assetpackages that get imported. While this doesn't seem horrible from an end user perspective, this is a lot more work from a publisher stand point, especially given more work is already required to support any additional pipelines.


So now lets look at Materials and Prefabs. Since prefabs point to a material, and materials point to a shader. This means all those assets developed prior to 2018, will not work in the Lite or HD pipelines at all. Wont work. Why? Because prefbs point to materials point to shaders, and the standard shader does not work outstide the standard pipeline.

Now lets think how smart the average person is. How many people do you think are gonna have a package in one pipeline, and download an asset that DOES NOT work for that pipeline, and be like wtf!!! why doesnt this work?

So now all you end users have to go through by hand and change all the materials to point to a new Lite shader, or HD shader, or are you expecting the publishers to put in that much more work for the same price?

So shader developers will be expected (doesnt matter if its required) to support ATLEAST 3 pipelines (atleast 3 cause you know someones gonna come out with a badass one everyone wants to use, making it 4 or more), and anyone who produces "Prefab" packages will have to make their packages support the main three pipelines out just so as to avoid user complaints and issues, plus any new pipelines that come out...

All the while expecting the end user to not just hit "import all" into their project and then wondering why there are errors....


This means if you write or use custom shaders, make or use prefab mesh packages, or make or use any package that generates a mesh and uses a material, these changes somehow impact you, the impact may be irrelevant to you. but its there.

 

Sadly, most of these issues could be solved with both an official "You can support whatever pipeline you like" and a new filter in the asset store to reduce the chance of errors on the publishers / users side but we are not getting any word on that end.

 

I'm pretty sure they will allow you to ship assets which only work on, say, the HD pipeline. But I'm also pretty sure they will stop promoting you if you don't support their new pipelines.

My bigger concern is that we're being forced to use a shader graph, one which will likely end up languishing in a semi-finished state if it follows the pattern of so many other Unity tools. Shader graphs are fine for small shaders, but quickly become inefficient both in a workflow and code performance manner. They also never give you full access to what you can do in a hand written shader. Are they going to support arbitrary data in the v2f struct? Texture Arrays? Sharing texture samplers? Proper branching semantics? Gradient and LOD sampler access? Geometry shaders? Custom domain/hull shaders? It's likely many of these things will never get into a shader graph, because they quickly make the graph way more complex to use.

Documentation for the lighting pathways in vertex/fragment shaders of Unity 5 is basically non-existent. The best documentation out there is a HUGE tutorial Catlike Coding did on the subject. I've run into breaking changes with Unity's lighting pipeline in every major release since I started working on assets (5.4, 5.5, 5.6, 2017.1, 2017.2, 2017.3). Every single point release changes something, and I'm left spending hours digging through the standard shader source trying to figure out what changed, and finally figuring out how to make my code work for BOTH the previous and new versions of Unity. Unity support will reply, when asked for documentation, that the shader code "Changes too fast to be documented", or "just look in the standard shader code and see what it does".

All shaders not produced in the new graph tools are being forced through this pathway, and once again it looks like no documentation or examples are being delivered on how to deal with these pathways. Maybe some wonderful examples are coming, but the fact that examples only use the graph is not encouraging. TimC has stated that 'The graph is their solution to these issues", which basically means Unity is going the Unreal way, where they expect everything to be done in node graphs or your on your own.

 

That would certainley help. The second issue is developers have been given pretty much zero information from what I can gather about what will be required to generate shaders in the new lite and HD pipelines.

This however doesn't do much in the way of helping people who generate and use mesh prefab packages. Some of which have HUNDREDS upon HUNDREDS of prefabs in a kit, all of which would need to have either their materials switched to a material for that pipeline, or have the materials themselves update to point to the proper shader for that pipeline. One way create multiple duplicates, the other way requires you to write some sort of conversion tool for your packages.

 

Here is my prediction. We will be told we can support whatever we want, a filter may or may not be put in, but all your favorite art asset packages will now be split in three, Buy the package for the pipeline you use. Use another pipeline, buy another package.

 

I'm an end user, and I get the feeling I'm not going to like Unity in 2018. All this SRP stuff is sounding very complicated.
So if I somehow manage to create my own SRP, I'm pretty much screwed in using any assets from the store because they won't support my pipeline?

 

That is a big concern for me as well, since most of my upcoming tools deal with custom shaders in one way or the other. I dont want to deal with a tool that is going to end up forgotten like the Terrain engine. This will force a lot of people to use the Unity engine as it is, with little to not custom shaders / assets.

The problem is, even if it is not really nice to say it (since I do like Unity), that if you compare the baseline Unity tools and engine vs baseline Unreal (or other engines), Unity is not in any way the winner. A main reason Unity has a fighting chance against other engines is the asset store and how "easy" is for people to share custom assets, which has helped for years to solve the many issues and lacking features of the main engine.

This. This is another big issue. The Unity team has been dismissing in their answers the actual amount of time that it will take to update our assets. Let's say it takes 4 hours to update a medium asset to work with the new pipelines, set up prefabs, scenes, materials, etc. (supposing you use only standard shaders). Let's say now that we add another hour to write and package its documentation and upload it to the store.

Now let's say you have a hundred of those assets in the store. Are we expected to spend 500~700 hours on this? At best, working 10 hours a day, it will be 50-70 days of nothing but updates and uploads. Without any new development, without any support to customers, without any work on our own games, nor anything else.

This is a real problem, and not an easy "One click, upgrade all" fix as the Unity team seems fixed on thinking.

 

Exactly. You could of course request to asset creators that they give you some support, but unless your SRP is a highly popular one, don't expect any asset to support it.

SRPs, lets be honest, are not designed with indie devs in mind. They are designed for bigger companies with a dedicated graphics programming team who can afford both the time and resources to roll out their own assets.

And as such, it should be entirely up to developers which one they use, and which one they support. They are a very good idea for very specific purposes, but they are being introduced in the worst possible way.

 

Rumor says that Unity's CEO was the CEO of Electronic Arts....why does this business model sound familiar?

Let's hope we are all mistaken and this is just a PR mess up. But again, Unity has quite the history with changes and new features so we will see.

 

And please, dont get this wrong anyone reading this. None of us are saying SRP is bad. We are saying that there is a LOT of potential for issues, which so far seem to have gone unaswered.

 

Well, there goes that dream. Honestly I'll probably just stick to good ol standard Unity. Unless there's something like 1000% improvement in performance.

To get back on topic. I'd say there has to be some kind of filtering system on the store. But new users aren't going to know how to configure it. As a new user, I'm not going to read the entire SRP documentation to figure out what pipeline to use, the pro's/con's blah blah. No, I'm gonna download Unity, download some cool asset package and be very disappointed when it doesn't work out of the box.

 

And then you can come give us a 1 star review, thinking it was all the fault of your friendly asset developer

Just kidding. We do understand very well that this will be a huge issue for most users, both for lack of experience and because Unity is making this way more confusing than it should ( starting with the names, why lightweight and HD? Why not call them Unity - Mobile and Unity - High End both in the engine and the store? sounds pretty clear to me which is which, no need for extra Pross and Cons ).

We just need now an answer showing that Unity understands (and cares) as well.

 

I think the way SRPs have come to pass over these last several months is another indication that, for better or worse, and despite the massive size of Unity as a company now, they still operate very much like a startup. That's not a knock on Unity at all. There are, however, pros and cons to the development model that includes early reveals of WIP features and rapid, public iteration with continual solicitation for feedback from your customer base. The uncertainty and seemingly late handling of many of these concerns is part of that "cons" list. (The fact that we've known about and have been able to follow SRP's development for all these months is part of the "pros," relative to how a more traditional software development company might handle timing and transparency of their communication.)

I don't envy Unity or our wonderful asset creators in trying to navigate this set of challenges. It feels like this is a very painful phase, but one that is also necessary for Unity to level up its graphical chops. The jack-of-all-trades rendering paradigm needs to go the way of the dodo.

 

I doubt you'll want to create your own SRP. It's kind of an all in thing. Here's the thing though:

- The shader graph will have a system for cross compiling shaders into a target SRP. You will be able to script this as part of the SRP, and conversion may be almost automatic if your SRP doesn't change the inputs to the lighting equation.
- If you don't use the shader graph, well you're likely up S***s creek, the same way you are if you write vertex/fragment shaders in the current Unity. TimC has signaled that the graph is their solution to these issues, so I wouldn't expect good support if your not using the graph.
- The system for cross compiling shaders from the graph for custom SRP's could be written to work with textual formats just about as easily as it could from any other format. In fact, a textual format, being closer to the final code which is going to be compiled, would be more customizable anyway. Decoupling these two steps into two separate systems, IMO, would both solve these issues and make the code more modular. I started asking about this over a year ago when SRP was first being proposed, so it's sad to me that this hasn't been better thought through after all this time.

Not kidding - this is absolutely what is going to happen.

 

Which is the reason behind my worries that this whole "experiment" and "upgrade" will end like the Terrain system. It has been what, 3 years since the "Max mesh trees" slider stopped working? 5 years since they promised an upgrade?

But an engine can survive and be usable with a limited and half finished terrain system. With a limited or half finished renderer? That's another story. Let's hope Unity gives this the importance it deserves.

 

So tonight I managed to get a very simple LD shader and surface shader to compile as one file. I have not extensively tested this, but it appears to work. Basically what you can do is declare each shader inside of a subshader block, such that you have the surface shader in one block and the LD SRP shader in the second block. This will allow you to write a custom shader that works in both pipelines without having to duplicate your materials and prefabs. Since they continue to reference the same 'shader', it just works without user issues.

Note that if you use the standard shader, you'll still have to duplicate the scenes/prefabs/materials, because the parameters and such in the standard shader are different between the current pipeline and the new LD one. Not sure if anything can be done about that..

But if you have a custom shader, you can basically do something like this (Note, I have multiple of the SRP passes and all the lighting/etc code commented out because I can't seem to include the lighting pathways unless I also install all the SRP source into the project - basically the SRP shader doesn't really work right now, but you get the idea):

Code (CSharp):

1. Shader "LightweightPipeline/Standard (Physically Based)"
2. {
3.     Properties
4.     {
5.         _MainTex("Albedo", 2D) = "white" {}
6.  
7.         // Blending state
8.         [HideInInspector] _Mode("__mode", Float) = 0.0
9.         [HideInInspector] _SrcBlend("__src", Float) = 1.0
10.         [HideInInspector] _DstBlend("__dst", Float) = 0.0
11.         [HideInInspector] _ZWrite("__zw", Float) = 1.0
12.     }
13.  
14.     SubShader {
15.       Tags { "RenderType"="Opaque" }
16.       LOD 200
17.  
18.       CGPROGRAM
19.       // Physically based Standard lighting model, and enable shadows on all light types
20.       #pragma surface surf Standard fullforwardshadows
21.  
22.       // Use shader model 3.0 target, to get nicer looking lighting
23.       #pragma target 3.0
24.  
25.       sampler2D _MainTex;
26.  
27.       struct Input {
28.          float2 uv_MainTex;
29.       };
30.  
31.       half _Glossiness;
32.       half _Metallic;
33.       fixed4 _Color;
34.  
35.       // Add instancing support for this shader. You need to check 'Enable Instancing' on materials that use the shader.
36.       // See https://docs.unity3d.com/Manual/GPUInstancing.html for more information about instancing.
37.       // #pragma instancing_options assumeuniformscaling
38.       UNITY_INSTANCING_BUFFER_START(Props)
39.          // put more per-instance properties here
40.       UNITY_INSTANCING_BUFFER_END(Props)
41.  
42.       void surf (Input IN, inout SurfaceOutputStandard o) {
43.          // Albedo comes from a texture tinted by color
44.          fixed4 c = tex2D (_MainTex, IN.uv_MainTex) * _Color;
45.          o.Albedo = c.rgb;
46.          // Metallic and smoothness come from slider variables
47.          o.Metallic = _Metallic;
48.          o.Smoothness = _Glossiness;
49.          o.Alpha = c.a;
50.       }
51.       ENDCG
52.    }
53.  
54.     SubShader
55.     {
56.         Tags{"RenderType" = "Opaque" "RenderPipeline" = "LightweightPipeline"}
57.         LOD 300
58.  
59.         // ------------------------------------------------------------------
60.         //  Base forward pass (directional light, emission, lightmaps, ...)
61.         Pass
62.         {
63.             Tags{"LightMode" = "LightweightForward"}
64.  
65.             Blend[_SrcBlend][_DstBlend]
66.             ZWrite[_ZWrite]
67.  
68.             HLSLPROGRAM
69.             // Required to compile gles 2.0 with standard srp library
70.             #pragma prefer_hlslcc gles
71.             #pragma target 3.0
72.  
73.             // -------------------------------------
74.             // Material Keywords
75.             #pragma shader_feature _NORMALMAP
76.             #pragma shader_feature _ _ALPHATEST_ON _ALPHABLEND_ON _ALPHAPREMULTIPLY_ON
77.             #pragma shader_feature _EMISSION
78.             #pragma shader_feature _METALLICSPECGLOSSMAP
79.             #pragma shader_feature _SMOOTHNESS_TEXTURE_ALBEDO_CHANNEL_A
80.             #pragma shader_feature _OCCLUSIONMAP
81.  
82.             #pragma shader_feature _SPECULARHIGHLIGHTS_OFF
83.             #pragma shader_feature _GLOSSYREFLECTIONS_OFF
84.             #pragma shader_feature _SPECULAR_SETUP
85.  
86.             // -------------------------------------
87.             // Lightweight Pipeline keywords
88.             // We have no good approach exposed to skip shader variants, e.g, ideally we would like to skip _CASCADE for all puctual lights
89.             // Lightweight combines light classification and shadows keywords to reduce shader variants.
90.             // Lightweight shader library declares defines based on these keywords to avoid having to check them in the shaders
91.             // Core.hlsl defines _MAIN_LIGHT_DIRECTIONAL and _MAIN_LIGHT_SPOT (point lights can't be main light)
92.             // Shadow.hlsl defines _SHADOWS_ENABLED, _SHADOWS_SOFT, _SHADOWS_CASCADE, _SHADOWS_PERSPECTIVE
93.             #pragma multi_compile _ _MAIN_LIGHT_DIRECTIONAL_SHADOW _MAIN_LIGHT_DIRECTIONAL_SHADOW_CASCADE _MAIN_LIGHT_DIRECTIONAL_SHADOW_SOFT _MAIN_LIGHT_DIRECTIONAL_SHADOW_CASCADE_SOFT _MAIN_LIGHT_SPOT_SHADOW _MAIN_LIGHT_SPOT_SHADOW_SOFT
94.             #pragma multi_compile _ _MAIN_LIGHT_COOKIE
95.             #pragma multi_compile _ _ADDITIONAL_LIGHTS
96.             #pragma multi_compile _ _VERTEX_LIGHTS
97.             #pragma multi_compile _ _MIXED_LIGHTING_SUBTRACTIVE
98.  
99.             // -------------------------------------
100.             // Unity defined keywords
101.             #pragma multi_compile _ UNITY_SINGLE_PASS_STEREO STEREO_INSTANCING_ON STEREO_MULTIVIEW_ON
102.             #pragma multi_compile _ LIGHTMAP_ON
103.             #pragma multi_compile _ DIRLIGHTMAP_COMBINED
104.             #pragma multi_compile_fog
105.  
106.             #pragma vertex LitPassVertex
107.             #pragma fragment LitPassFragment
108.  
109.             //#include "LightweightShaderLibrary/InputSurface.hlsl"
110.             //#include "LightweightShaderLibrary/Lighting.hlsl"
111.  
112.             struct LightweightVertexInput
113.             {
114.                 float4 vertex : POSITION;
115.                 float3 normal : NORMAL;
116.                 float4 tangent : TANGENT;
117.                 float2 texcoord : TEXCOORD0;
118.                 float2 lightmapUV : TEXCOORD1;
119.             };
120.  
121.             struct LightweightVertexOutput
122.             {
123.                 float2 uv                       : TEXCOORD0;
124.                 float4 lightmapUVOrVertexSH     : TEXCOORD1; // holds either lightmapUV or vertex SH. depending on LIGHTMAP_ON
125.                 float3 posWS                    : TEXCOORD2;
126.                 half3  normal                   : TEXCOORD3;
127.                 half3 tangent                   : TEXCOORD4;
128.                 half3 binormal                  : TEXCOORD5;
129.                 half3 viewDir                   : TEXCOORD6;
130.                 half4 fogFactorAndVertexLight   : TEXCOORD7; // x: fogFactor, yzw: vertex light
131.  
132.                 float4 clipPos                  : SV_POSITION;
133.             };
134.  
135.             // Vertex: Used for Standard and StandardSimpleLighting shaders
136.             LightweightVertexOutput LitPassVertex(LightweightVertexInput v)
137.             {
138.                 LightweightVertexOutput o = (LightweightVertexOutput)0;
139.  
140.                 o.uv = v.texcoord.xy;
141.  
142.                 //o.posWS = TransformObjectToWorld(v.vertex.xyz);
143.                 //o.clipPos = TransformWorldToHClip(o.posWS);
144.                 //o.viewDir = normalize(_WorldSpaceCameraPos - o.posWS);
145.  
146.                 // initializes o.normal and if _NORMALMAP also o.tangent and o.binormal
147.                 //OUTPUT_NORMAL(v, o);
148.  
149.                 // We either sample GI from lightmap or SH. lightmap UV and vertex SH coefficients
150.                 // are packed in lightmapUVOrVertexSH to save interpolator.
151.                 // The following funcions initialize
152.                // OUTPUT_LIGHTMAP_UV(v.lightmapUV, unity_LightmapST, o.lightmapUVOrVertexSH);
153.                // OUTPUT_SH(o.normal, o.lightmapUVOrVertexSH);
154.  
155.                // half3 vertexLight = VertexLighting(o.posWS, o.normal);
156.                // half fogFactor = ComputeFogFactor(o.clipPos.z);
157.                // o.fogFactorAndVertexLight = half4(fogFactor, vertexLight);
158.  
159.                 return o;
160.             }
161.  
162.             // Used for Standard shader
163.             half4 LitPassFragment(LightweightVertexOutput IN) : SV_Target
164.             {
165.                 float4 tex = 0;//tex2D(_MainTex, IN.uv);
166.                 float3 normalMap = float3(0,0,1);
167.                 //half3 normalWS = TangentToWorldNormal(normalMap, IN.tangent, IN.binormal, IN.normal);
168.  
169.  
170.                 //half3 indirectDiffuse = SampleGI(IN.lightmapUVOrVertexSH, normalWS);
171.                 float fogFactor = IN.fogFactorAndVertexLight.x;
172.  
173.                 float metallic = 0;
174.                 float smoothness = 0;
175.                 float ao = 1;
176.                 float3 emission = 0;
177.                 float alpha = 1;
178.  
179.                 //half4 color = LightweightFragmentPBR(IN.posWS.xyz, normalWS, IN.viewDir, indirectDiffuse, IN.fogFactorAndVertexLight.yzw,
180.                 //  tex.rgb, metallic, 0 /* specular */, smoothness, ao, emission, alpha);
181.  
182.                 // Computes fog factor per-vertex
183.                 //ApplyFog(color.rgb, fogFactor);
184.                 half4 color = half4(1,0,0,1);
185.                 return color;
186.             }
187.  
188.  
189.             ENDHLSL
190.         }
191.         /*
192.         Pass
193.         {
194.             Tags{"LightMode" = "ShadowCaster"}
195.  
196.             ZWrite On ZTest LEqual
197.  
198.             HLSLPROGRAM
199.             // Required to compile gles 2.0 with standard srp library
200.             #pragma prefer_hlslcc gles
201.             #pragma target 2.0
202.             #pragma vertex ShadowPassVertex
203.             #pragma fragment ShadowPassFragment
204.  
205.             #include "LightweightPassShadow.hlsl"
206.             ENDHLSL
207.         }
208.  
209.         Pass
210.         {
211.             Tags{"LightMode" = "DepthOnly"}
212.  
213.             ZWrite On
214.             ColorMask 0
215.  
216.             HLSLPROGRAM
217.             // Required to compile gles 2.0 with standard srp library
218.             #pragma prefer_hlslcc gles
219.             #pragma target 2.0
220.             #pragma vertex vert
221.             #pragma fragment frag
222.  
223.             #include "LightweightShaderLibrary/Core.hlsl"
224.  
225.             float4 vert(float4 pos : POSITION) : SV_POSITION
226.             {
227.                 return TransformObjectToHClip(pos.xyz);
228.             }
229.  
230.             half4 frag() : SV_TARGET
231.             {
232.                 return 0;
233.             }
234.             ENDHLSL
235.         }
236.  
237.         // This pass it not used during regular rendering, only for lightmap baking.
238.         Pass
239.         {
240.             Tags{"LightMode" = "Meta"}
241.  
242.             Cull Off
243.  
244.             HLSLPROGRAM
245.             // Required to compile gles 2.0 with standard srp library
246.             #pragma prefer_hlslcc gles
247.  
248.             #pragma vertex LightweightVertexMeta
249.             #pragma fragment LightweightFragmentMeta
250.  
251.             #pragma shader_feature _EMISSION
252.             #pragma shader_feature _METALLICSPECGLOSSMAP
253.             #pragma shader_feature _ _SMOOTHNESS_TEXTURE_ALBEDO_CHANNEL_A
254.             #pragma shader_feature EDITOR_VISUALIZATION
255.  
256.             #pragma shader_feature _SPECGLOSSMAP
257.  
258.             #include "LightweightPassMeta.hlsl"
259.             ENDHLSL
260.         }
261.         */
262.  
263.     }
264.     FallBack "Hidden/InternalErrorShader"
265. }

 

This is a step forward, but unfortunately massive amounts of work to update our assets will still be necessary and the fact that the full SRP source is required for the different passes to work still has the potential for, in the end, confuse and raise issues with the end users.

This workflow you describe, if it can be made work well, could help if in the end we are forced to pack all 3 pipelines in 1 package, though IMO it still would be better to have 1 package for each pipeline, as it will also help us to keep things more organized.

 

Good to see the Unity team is here, though are there any clear answers for the several important and urgent questions we've been asking? Not to say that the big progress Jason made is not important, but the issue of this thread is a little more complicated and bigger than just making our custom shaders compile, and it needs some answers and reassurances.

 

Where is the documentation anyway which describes how I should modify my shaders?

 

Can we please get a minimal LIT shader example that works from the given project then? One which requires includes of lighting.cginc and such, but isn't a nested system of includes for the actual shader code itself. Basically, something like what creating a surface shader and hitting "show output" would give.

I tried modifying my project paths to match the include paths - this worked for the first set of includes, but not their includes, likely due to relative pathing. But I shouldn't even have to include all of this- it should be possible to use the files included with the installed SRP instead of having to copy all of these files and rearrange all the paths, right?

 

Indeed, that would be the most important thing.

 

I try to upgrade a standard surface shader (just made a new one) to Lightweight pipeline and seems to be stuck. Is there any step i should do before that ?

I am doing this in the new SRP project with the render graph samples (but not in a render graph shader)

Also i cannot cancel the stuck process and had to manually kill Unity process

 

You made the standard shader...as in a custom shader that uses the standard model? If that's the case, it won't work. The tool only updates the materials that use Unity's own standard shader, with all its inputs and parameters. Anything else is a "Custom" shader, and the workflow for that is still pretty much unknown.

And all this confusing and troublesome process is exactly why there are so many asset publishers worried and upset, all these changes we need to make without tools, documentation, plan, nor anyone who can get back at us with answers a little better than "We don't know yet"

 

Remember that email we got some time ago titled "Asset Store Publisher Notice: 2018.1 Beta is coming, get familiar with SRP."? That had a few broken links, missing links, and a broken project.

Broken link: https://forum.unity.com/threads/201...der-notice&utm_medium=email&utm_source=Eloqua

Missing link: For additional information read this Getting Started with Lightweight Pipeline guide.

Broken project: https://drive.google.com/file/d/1i0GlWYO0SRwauqu3U2rKoUAPO8BOFXw8/edit

That was a fail.

Anyone know how to get that project to work?

 

Another fail is that it was supposed to get released on the last week of December. In that email said at the end of the week.

 

Yet another one is that they said we should start learning how to update our assets during January, for the new version, while they didn't have any plan at all, the upgrading tool is not well finished as it has given issues to many people, and in their last replies the unity team just told us to "wait till the release is closer, something that will take several months".

For many asset developers the asset store is a big or their main source of income. They cannot just take this huge change without any planning, roadmap nor instructions. Nor can they just port by hand the work of years to all these new SRPs without taking a huge economic hit with all the time and resources they will lose only in making sure these ports work and are well supported in pipelines that are currently limited /poorly documented/ unstable.

And I guess we can also count as a big fail the dead silence they are showing towards our questions. They have replied to a few technical questions on how to use this or that, but about the important issues on what will be supported, what will they require from Asset Developers and how will this be handled in the store, they have been completely quiet. :/

 

Hi IrrSoft,
We are looking at how we can minimize the impact on our asset store developers and checking if we can come up with solutions to avoid any work from our users. Stay tuned.

 

Thanks for replying, it is good to know that the Unity team is at least keeping track of this. An official confirmation that we do not need to support all 3 pipelines would be really nice (or in that case, confirmation that we HAVE to support them), but at least it is better knowing that there may be an answer coming soon.

 

Thanks for the reply. It really does need to be minimized as close to zero as possible for publishers and users alike.
Ideally, having an upgrade tool that can translate / cross compile / interpret / whatever word you want to use old *.shader code into the new format would be appreciated. Only having support the the old shipped standard shader is frustrating at best and expecting users or publishers to create their own tool to step in via scripts etc. to both update custom shaders and then mass apply them to their (more often then not) immense library of materials and models is worse.

 

And once again, many of us will be better off giving support to only the Standard pipeline, or only the Lightweight one. Something that Unity refuses to allow / confirm we can do. As it stands now, we have no idea if we will have any choice or say on this matter.

I have an asset in development (thanks to this update, now on hold) that replaces the deferred pipeline and adds softer shadows as well as several smaller fixes to issues in the current rendering system. Most of those fixes won't even work on the Lightweight pipeline (no point shadows support) and will not be useful in the HD one (better native shadows already) so...what's the point in supporting all 3 of them? 1 of them is impossible to support, the other one would be a waste of time since HD will supposedly already have most of these features. It is a tool designed specifically for the current pipeline...and until they confirm that I will be able to support only this 1 pipeline and ignore the other 2, it would be a waste of time to keep developing it for the store.

It is quite frustrating to not get a clear answer in something as basic and simple as this. It doesn't have anything to do with the internal work of the engine moving forward, nor with the SRPs themselves, nor conversion tools nor documentation.

It is something as simple as telling us if we have any choice or will be forced to support this system. The lack of response as well as the part of the email they sent that says "Unity 2018 will keep supporting the current pipeline" make it feel as if they plan to deprecate the current rendering system as soon as Unity 2019. I hope I am wrong.

 

I know it's really frustrating to not have an official answer from Unity on what asset developers are required to support, but again, given their history as a startup shop (I happen to work for a startup just down the street from Unity's main office in San Francisco; this feels like familiar territory to me), I truly believe they haven't decided yet what to do. I also have to believe they are trying to weigh out all of the options, including consideration for the relative advantages and disadvantages of each, to figure out what is the best path forward--again, with the understanding that this is going to be painful, no matter what.

The best thing anyone can do here is to voice calm, rational, honest, descriptive perspectives on what you think needs to happen to help influence whatever the final call ends up being. I suspect lots of Unity folks who will influence these decisions behind the scenes are people who never comment in these threads, but are silently reading these posts. These are developers who can/should empathize with the issues the community is facing; we can tap into that empathy, if we present a compelling case.

 

In the end, after all of this, I still hope this is just a bad case of miscommunication from the Unity team (both to us and among their internal development teams) and that everything can be fixed sooner than later, since that is what will be best for all of us.

 

I hope you are right. Unity does indeed work at times in a way that is not really the best for a company of its size and with this amount of users and customers, but it is their style. Though again...they also have a history of half finished and half implemented features that end up in development limbo like the Terrain System and, up until very recently, the Input system.

We are all hoping this can be solved swiftly, since that is the best for everyone, but we also hope that Unity learns its lesson and understands that, with a community of users (indie and pro) of this size and whose incomes depend largely on their services, they cannot afford to jump towards such radical changes (and even less make them public) without a well thought plan. They may act like a startup but they haven't been one since many years ago and as Unity keeps growing, it is a working style that will drive many good developers away. In a startup it is understandable given their lack of experience and capacity, in a company of the size and experience that Unity has, these situations will give a bad impression of carelessness.

Unity should really have spent a few months collecting feedback from asset developers in polls and otherwise before pushing this Beta. That way, all these issues could have been worked out without the added pressure of all the bug reports from the general user base and without so many people feeling left out in the dark.

But again, everything we can do is wait for them to decide what to do with this situation.

 

To clarify my previous comment, I'm certainly not saying the way things have turned out so far is the "right" way, or even a good one. Just that there isn't malicious intent behind the lack of clear communication. If someone at Unity told you to post here, it's probably because they want to leverage the community's comments to get the right people to listen.

Certainly, this is a learning opportunity for Unity for future overhauls to foundational systems like rendering.

 

No worries, I understood what you meant. I guess I just feel a bit frustrated and sad at this working style since I already saw it before, some years ago, with Torque3D and Shiva3D (which was actually a bit of a startup at the time). Tons of promises and new exciting features always in beta, always unstable, always changing and always without a final plan.

I dont think Unity will end up that way, it is too big for that. But it certainly can damage the community and the image of Unity in the long run.I hope for the best, I really do not have anything against Unity. I would really love for them to learn and start working in a more responsible and thoughtful way. In a way, a community of millions is their responsibility now, it depends on them and they depend on it, so they need to be up to the challenge and improve their working model so Unity can keep being the preferred tool of so many developers and keep being for many of us the best option.

 

The new changes will also have a big impact on game developers side, given that many use the store for assets and now will simply not know anymore if this is viable, as the complexity to keep up good asset has skyrocketed, and was already very big before the new pipeline additions.

Also more advanced users will also find hard to upkeep unified projects, as the complexity could be too high for an indie studio.

At the very least there should be a year long beta on the pipeline aspect and involve all users from the start, not the last few weeks and with zero documentation about anything.

Currently i cannot even convert Unity standard shader with the provided tool, everything freezes.

 

This pipeline aspect should indeed be in beta for a long long while and once ready, it also should be kept as an alternative workflow. If it is turned into the main one or the only one then yes, many game developers will be in trouble. I imagine that only around 60~70% of the asset developers will have the time, money and motivation to update and support their assets with three times the work for the same price, and this will affect everyone deeply.

 

Indeed and the biggest issue is that the most complex and useful assets will be the ones affected the most, which will also reduce the value of the store a lot.

In short it is much better to have a bit less fancy graphics for a bit more time, than destroy the Unity's main worth overnight, which is empower indie game development and not only be used by multi million companies that can handle huge complexity and issues.

Or just offer the advanced pipeline as an alternative and merge the lower pipeline with the standard shader and offer a default single solution and an advanced for the users and asset devs that want to use/support it. That would make a lot more sense and keep things a lot more tidy and after that and some years of developing the HD pipeline, could also be merged as a mature option.

 

This would be a really good idea moving forward, it wouldn't affect current users nor would leave new users (which most likely will want to use the newest 2018 version) stuck with an engine whose asset store is full of amazing tools that they cannot use, while the base features are limited and not always the best.

 

Sorry, but a lot of things said here, while valid concern at it's core, is leaning towards an outrage, which is counter productive in my opinion.

Unity embraces a Lean development principles, and I for one fully support it. This is how modern software development is done in majority of good software houses, and it's the way to go. You propose changes, prototype it, give it to the public, gather feedback and act according to it. I do agree the lack of documentation is concerning, and they have proven in the past to neglect this aspect.

Just post the problems you are encountering, report bugs with reproduction steps, and keep the communication flowing; I seen many times in the past they do respond to feedback and you HAVE a direct impact on the changes.

In the end, if the pros of new solutions overweights the cons it's better for the end user that the solution became a standard, you need to adopt your business accordingly, banking on the fact that things wont change is a loosing strategy.

 

And while this is also valid, the main concern we have here is that there is not only a lack of documentation, but a lack of communication and planning as well.

None of us is expecting things to not change.

But, to make a basic example, what they have done is basically like Microsoft coming and saying to every developer "Starting next month, I want all your applications updated to run on Windows, Xbox and phone if you want to be able to keep selling them".

And after finding out that for some applications this is just impossible, not for a "resistance to change" but for valid technical reasons (and business too, we have our own target markets after all), they just told us plainly "Then we don't Know what happens now, we didn't plan this far ahead. The change is coming though! Stay tuned!!!"

It's true that some concerns have sounded more like outrage, but IMO Unity also needs a bit of tough love from those developers. We will give feedback and report bugs, but please let's make it clear that the issue of this thread has nothing to do with the new features themselves, but with the lack of communication and planning on Unity's side.

If we have to change our business and suddenly half the assets in the store become obsolete, that's a pity but we of course will adapt or move away. No problem. Just tell us directly.

If our business can stay active as it is for a few years more, while this happens and as long as there's people using the current pipelines, that's good as well. Just tell us directly.

The asset store has helped Unity in a big way to reach its current place among engines and it deserves, if not any concession to what we want and need, at least a hard confirmation that the change is mandatory. A clear indication of what comes next.

That's not asking much, that's the least we need and should have received.

Do you really think all major companies make changes that can break their partners business without any plan nor clear communication before the change?

Because a week ago we were still being required to start preparing our assets for the change already, despite our feedback and the issues shared. It was the little backlash and many issues we brought up that changed things to a "we don't know" "we will see" and silence.

Which again, is the main problem, more than the change itself. Outrage is not productive I agree, but neither is scaring your asset providers with business breaking announcements and then keeping them in the dark.