Official Lightweight Render Pipeline is Evolving!

Yeah, I agree with you. The situation is even worse in the latest LTS version- Unity2018(for me personly, unity 2019 is even more stable than 2018, because lwrp has much more game breaking bugs in unity 2018, and fixes won't get backported), All new features are not in a usable state including lwrp, and is not more stable than the previous version. So maybe it's more practicle to just stick with unity 2017 for old projects.

For new projects, I think it's worth the effort to learn the "new" Unity, since it's more "comfortable" once you get used to it

 

I just want shadergraph and vfxgraph in arfoundation

lol, ETA PLZ

 

Does it support camera stacking yet? I'm not switching to LWP/Universal RP until you can do Camera stacking easily in the editor without writing custom SRPs or extensions...

 

PERFORMANCES ISSUES
Hi all,
6 months ago I have done a benkmark comparing STANDARD SHADER with LWRP for mobile devices and with LWRP app lose arouind 30-35% in performance especially on less powerful devices.
So I stopped using the LWRP.

Has anyone done any performance tests on URP?

Meanwhile have the performances on LWRP improved on 2019.x?

Thanks in advance for any feedback/info

 

Does this mean you will be removing the good old built-in Forward Renderer?
Is there any plan to upgrade Unity's surface shader system to support Universal?
I know there is the Shader-Graph to make "custom" shaders using nodes, but I REALLY like to program my shaders myself by code.
Surface shaders are perfect because we can write optimized code without having to worry about manually supporting Unity's internals.
The shader graph generated shaders are good for artists but are too bloated for programmers.

 

So, will the Forward Renderer be removed?
If that's the case and we're forced to use Universal, you should REALLY think about upgrading the surface shader system to support it.
Otherwise I think I'll skip newer versions of Unity and cancel my subscription.
I know it sounds harsh but it's a real deal breaker for me.
If the only options I'll have will be using the shadergraph, you just removed the best feature of Unity for me.

 

You can still write custom shaders in LWRP, you just don't get the Surface Shader abstraction.

 

yes of course. But making a pixel-vertex shader that interfaces with all the internals of LWRP like Lightprobes, lightmapping, shadow reception and casting, single pass multilight lighting... is clearly doomed.
There is a reason why surface shaders exist.
Removing them is foolish.

 

I appreciate your sincerity about this.
As long as the forward renderer is not deprecated, it's ok.
LWRP and HDRP are cool, but a visual shader editor will never be on the same level of performance than manually coding a shader.

There are people who make a living just recoding shaders made with visual shader editors into real pixel shaders.
It's really a waste to deprecate the surface shader system just because we have a visual editor now.
New shiny features shouldn't deprecate well established and good working ones just because they are new.

I'm not sure to like the direction this is going, to be honest.

 

Does this include WebGL? Because even though you say 'anywhere', the package manual doesn't list it as a supported platform. I found a post saying it should, in which case it probably ought to be mentioned on the package's page. I'm just asking to be sure before I spend a lot of time trying to upgrade.

 

@aleksandrk have you any feedback about URP performances on mobile?

 

That's one of the main reasons I still use Forward Rendering instead of any other deferred renderer.

 

I never got a response for if realtime GI is ever coming to URP?

Am i just out of luck if i want to do a dynamic day and night system?

 

GI is ptrobably just a wish by now, even iof they have started work on it, I don't think they have a "solution" yet. My intuition tell me they will start by trying a probe base one inspired by DDGI.

Does that mean we should hand optimized all permutation for all platform? or the generated code already take that into account?

 

It's just like the old surface shader generated pixel shaders: trying to optimize it by hand is a never-ending nightmare.
Yet another reason to update the surface shader system to support the SRP.

 

Since Unity is removing Enlighten and will be doing their own realtime GI, expect it to be supported in 3 to 4 years.

 

Well, hand optimized shader code won't perform much better than a correctly connected shader graph. The code it generates might look terrible, but most of the optimization are done by the driver, not by the shader programer(including shuffle the code around, to move arthemitic operation after sampling a texture, inlining methods and much more)
And there's another fact should be konwn, that the biggest bottle neck is the bus bandwidth, regardless if it's desktop highend GPU or mobile GPU(mobile GPU even worse), sampling 1 more texture costs more than adding a bunch of calculation or tons of shader graph nodes. You can profile your gpu if you are not sure about this. If you are running a very heavy game, and see GPU is 100% utilized, you'll be suprised that only 30-50% of the alu units are in use(the unit responsible for the calculation). The bus is consuming the majority of the gpu's power and is generating the most heat, not the calculation

So, don't be afraid of using node based shader editor, it won't perform bad if you are using it normally like you would do in code. And it's very handy and intuitive while implementing shaders

 

Pretty theory. Doesn't work in reality. I can assure you hand optimization is paramount in a shader.
No amount of driver optimization will move something from the pixel to the vertex shader, use lesser precision variables or pack multiples values into a single variable.
This changes DO impact performance way more than sampling an additional texture per pixel. Specially on mobile chips.
I'm talking from experience here. No fancy theory will be more accurate than reality.

 

When you say "built-in", you mean Forward rendering or Deferred rendering?
Are you saying Universal is faster than Forward with a single light and no additional passes like depth and normals?

 

That's cool then.
Still a pain in the ass to be forced to use the shadergraph though

 

Thanks for the answer.
Ok soon we will do a porting test on URP and I will submit a bug if we found seriuos performance issues.

 

Hmm. how can you move code from pixel to vertex if you are using surface shader? I think we are talking about surface shader and shader graph. And shader graph has the ability to choose precision you like

And you can add your own shadergraph master template if you want to have more control over the code it produces

I won't tell you this if I didn't compare it with hand optimized code by myself. I was skeptical about node based shader editor as well and thought it's just toy for artist or TA. But after I made an experiment, which I tried to pack everything possible together, and tried various techniques which greatly reduce the code needed. The result isn't that obvious that I could say hand optimization would make big difference. I wondered about the test result, so I did the research for the reason why it is so, and what I told you is the result of the recherche. It's not that I read some random strange blog post mentioned something about it and just quoted it without further research. Does it perform better with hand optimized code? Yes, it makes a little bit difference. But definitely not that much as expected

Also, I'm not suggesting to make stuff like BRDF function with shadergraph, these stuff are still needed to be written by hand. But the code which connects the library functions together, can be safely implemented by shader graph.

 

Hi there, I will like to test my current project upgrade from LWRP to Universal pipeline, where to contact you? Thanks in advance

 

To be frank I'm still not sure you can easily do weird shader like megasplat with the graph. And I constantly experiment with weird shader that do tracing like effect and are more akin to write brdf than blending texture data. I'm worried, I feel there is a tone deafness here.

 

To be fair, for that level of shader development, I am currently modifying the LW/URP Lighting library itself. It is definitely more work than defining a custom lighting model was in SurfaceShaders but it is still a pretty nice framework to work in.

 

I upgrade my game ( huge with 25gigs of assets from LWRP to URP. Went pretty well ( few 3rd party shaders for sure we causing problems).

Tested importing new assets from the store and everything is fine but all my pre-existing materials still pink ( even after running upgrade material to URP process).

Tried re-importing URP but with same results.

Am I missing something in the conversion process ?

thx

 

You know you can define your own vertex shader with surface shaders, right?
Along with your own input output structs from vertex to pixel and multiple render targets, right?
We don't seem to be on the same page here...

ABSOLUTELY.
On Unity side I see a complete lack of interest to support something that wasn't developped by the team of the new render pipeline and therefore they just dismiss surface shader programing because it would be a lot of work to support it, and on some users side I see a fundamental lack of experience and understanding of surface shaders.
I have been coding surface shaders since Unity 3. I really don't see how I could program the things I did with the shadergraph without creating custom shadergraph nodes for everything everytime I do a new shader, and even then performance just couldn't be at the same level.
THE VISUAL SHADER EDITOR IS NOT ENOUGH, WE NEED SURFACE SHADER SUPPORT.

 

So there's likely no option for years? This would be less of an issue if HDRP was projected to work in stuff like WebGL but if they're trying to create something that covers all bases, and actually has use for a project (or worth upgrading a current one) that issue is kind of critical.

Day and night systems are kind of a mainstream thing now days, to lack that for years on this new flagship system is really unfortunate...

 

What about geometry shader and tessellation???
It's not yet supported by ShaderGraph... I can't even modify the vertex normal...

 

For what it’s worth, I think Josh Tripplet* from Intel is spot on about the requirements to adopt a replacement technology:

1) Sufficiently compelling (features).
2) No less capable (parity).

As soon as URP satisfies both requirements, the adoption will flow. But it’s clear that as of today it does not match 2). That’s why I think it’s too early to think about a name switch and that renaming or tagging it with the “universal” moniker is misleading...

Move URP and builtin teams into the same room and tell them to work out a solution so the engine can compile standard shader into URP-compatible stages and lighting (to the extent that’s possible). In the same way that it can currently generate the builtin forward and deferred code. That will provide a basic bridge over which artists and asset store authors can work to ease the adoption...

*: not related to Unity but interesting:

 

Yes, but I think it's out of the scope of the surface shader itself. Anyway you can do this with shader graph,too. By defining new Master node. Of course you can argue that adding a custom vertex shader has less work to do than adding a master node, but shader graph has the per step visualization which is very useful while experimenting or debuging shader, and it's much more productive than writing shader code by hand.

 

While you can make a 100 miles in a bicycle, I would choose a car for the trip.

 

The LKegendarie jason Booth think it's a headache, why me, who is just scrapping by would think any less? The problem is i'm caught in the middle, the graph is too simple for the thing I make, but the lw/urp seems too complex (where is the doc!?) for my level.

The big deal of the surface shader is to abstract lighting, and element of the pipeline, so we can focus on the part that matter, ie the core behavior of a shader. Vertex is absolutely within that scope. Ie I can keep separated vertex, fragment and lighting neatly, which was the big innovation, and it allow to make complex shader without having to care about all the boiler plate and the coupling. For example I work on a infinitely repeating tracing of hair, that's not well express as a graph at all, as it's primarily a lof of math expression, but light just work as I only code the tracing part in the fragment (and prepping the right data in vertex).

 

I honestly think that surface shaders themselves aren't necessary if Unity can provide two things:

• The visual editor should be powerful enough to do more or less the same thing as surface shaders, including simple vertex shaders. From what I've seen, that's already more or less so.
• Good documentation for integrating custom shaders into their new pipeline. In my experience, documentation for shader code, especially working with Unity's systems, is basically nonexistent and it looks like it's become worse since then.

If the new render pipeline has good low-level shader documentation (e.g. tessellation and geometry shaders, which would be hard with a visual editor) and has more consistent shader code that reliably compiles for other platforms, I'm 100% for the change. Even greater would be a way of including tessellation and geometry code into the visual editor.

However, without proper documentation on how to include high-end shader effects into the new pipeline, I believe that a lot of potential shader developers will be stopped in their tracks.

 

Then I think you should like the shader code of URP, it's much better structured and more clear than the good old UnityCG.cginc. The shader library provided by URP contains sufficient comments and has very consistent naming, which makes making custom shader very simple

 

I've looked into the code for the HDRP a few months ago and it looked like a very complex system, using code generators all over the place. Maybe I just wasn't looking in the right place, but from what I've seen it did look like a lot more thought and design went into the new system.

I do hope that the whole thing will move from "Look into the code" to "There's actually documentation"!

 

Yeah, not really disagreeing there, it is definitely not as convenient, I'm just being a bit more open to solutions that can be developed now or in future. The beauty of SRP is that *we* can modify the system and implement this stuff, even if Unity does not.

The documentation of the alternative is severely lacking indeed, i.e. it is just not there. The library is rather nicer than the legacy one but to find out how to do something you have to dig.

If you do not want to do custom lighting models (which was the most powerful part of Surface Shaders for me but not viable for all renderers), it should be possible to have a macro system for overriding InitializeStandardLitSurfaceData, InitializeInputData and/or overriding LitPassVertex/Fragment. At the moment, I just write those bits myself based on the existing passes, its only real annoyance is code repetition between the different passes.

You lose the niceties, like automatic mapping of the surface struct to the actual samplers, automatic enabling/disabling of features depending on what you are referencing, etc. but I am sure a reasonable compromise can be developed even without an actual shader compiler for now.

Alternatively, if ShaderGraph becomes powerful enough to allow full specification of what goes into what stage and what the structures are, if would be quite possible to do everything surface shaders did that did not require allowing custom lighting models, even by writing actual code. You would just use ShaderGraph to wire up inputs and outputs and your shader itself would just be HLSL in a custom nodes. That would only be a step away from an actual fully textual representation of the entire shader, and a smaller jump than from what we have now in URP.

 

Or... you know... they could just support surface shaders.
Of course the shader graph could be marvelous if and when they do all of this.
But do you realize it will take so much YEARS at Unity's pace to implement this without bugs and with proper docs that by then they will have made a new shiny feature and the shader graph will be deprecated?
I'm all about progress. But why deprecate something that is CURRENTLY working well to substitute it with something that doesn't?
I only see a lack of interest to support old systems just because they are old and nobody wants to support something they didn't do in the first place.

 

@Al

Could you help me find out if a bug I'm encountering is also in Universal Render Pipeline, or at least a known issue in LWRP 6.9.1?

Running into an issue with 2019.2 (all minor version of it) and LWRP 6.9.1 and was curious if this was fixed in 2019.3 and Universal Render Pipeline.

If I have two lights close to a skinned mesh renderer, and pulse the Intensity from 0 to X on one of the lights, the other light turns off when the Intensity of the first is > 0. If I put a default cube i with a LWRP/Lit material in the scene, it does not happen. I have my PerObjectLights at 4, and there are only those two lights in the scene.

This is pretty much a deal breaker for me and was pretty heartbreaking to discover after updating from 2019.1. I thought problems like this shouldn't exist anymore in LWRP since it is "out of preview".

 

Here's an idea:
I think the ShaderGraph should add support for a VertexShader function and a FragmentShader function in the same way we write built-in CG/surface shaders. Basically a node where we specific code in it. Then with the appropiate well defined well documented inline and macros people will add lighting, tesselation etc. Think of building the shader visually but structured the same way you write shader code eg properties, structs, functions, interpolators, etc each one with their own specific body of code.
This functionality won't be that much artist friendly, is more for the old shader coder (CG or Surface Shader) but can be easily added into the ShaderGraph editor and parsed into any HLSL compiler.

 

The issue is, the level of abstraction surface shaders provide just can’t support both LWRP and HDRP. You could do it for URP, but I cannot see how you could support both pipelines, they are way too different. That is, I assume, why they are focusing on an abstraction that would work for both, where the actual primitives provided can be substituted on a per-pipeline basis. Plus there is a good chance that the existing codebase is running on an obsolete compiler.

All I’m saying is, it is not as simple as saying “just support surface shaders”, I suspect strongly it would be more like “let’s reimplement surface shaders from scratch”.

 

That's a good idea there.
As I said before: I'm not against change. I'm against changing something that works for something that, maybe, one day, will have as much functionalities as the old implementation.

Oh, no doubt it must be tricky to implement, but as much sympathy as I could have for fellow developpers, that's what we need so it must be done. One way or another.

 

There is no doubt they are crumbling from legacy oopsies, but going 180° every two years and not learning about the strength of old implementation is aggravating. My guess is that rapidly growing and hiring new people, with no affinity with the old system, and who want to prove themselves by solving problem with silver bullet, is what's happening. And even by growing they seem understaff and overbook, when you read some response it feels like "there is too much work already, help, we gonna stick to our gun because we have no idea what you all are talking about".

Anyway, the beauty of standard was that you could go as complex as needed (minus visual coding **cough** strumpyt was excellent **cough**) and had a lot of flexibility. I learn shader by basically just not caring about anything, and just modifying code of generic shader, and it just worked, so I could experiment and the optimized, then start going out of standard.

The thing I want to see is what does look like a ssr or ssao or any of these complex post processing effect look like in shader graph (I mean math and branch heavy).

If anything I thought that srp would be a continuation of that, and that we would create our own surface shader by controlling the complete render pipeline easily. instead we have shader graph.

 

RIGHT THERE.
I could hug you now