Join us for #SRPLife Week!

Over the last few years, Unity has introduced the Scriptable Render Pipeline (SRP) system, along with several render pipelines (LWRP/URP, HDRP). These new render pipelines have created significant issues for Unity users and publishers on the asset store. A few with examples are listed below:

• Shaders must be rewritten from the ground up for each pipeline. There is no upgrade path from Standard to an SRP, and shaders written for one SRP (URP) won't work for another(HDRP).
• No upgrade path for shaders between versions of the SRP. URP 7.1.8 shaders are not compatible with URP 7.2.1 shaders, yet are both for Unity 2019.3.
  
• Rendering code must be re-written for each pipeline. The CustomPass system for URP and HDRP are completely different, yet do the same thing.
• Code is often broken or different for no reason on different pipelines. Camera.backgroundColor is used in URP/Standard, but in HDRP it's stored in a different property on a custom component and aliased in the editor to look like the camera component is being used.
• No documentation for shaders. This means countless hours reverse engineering the shading system. And when things change, there is no documentation on what has changed.
• New versions not sync'd to Unity releases. URP 7.1.8 and URP 7.2.1 shaders are incompatible, and both for Unity 2019.3. Users are forced to upgrade depending on which patch version of Unity 2019.3 they are using, making it impossible to support.
  
• Assets written for multiple pipelines cannot "just work" when installed. If you have even the simplest material, users will need to manually upgrade your project to work in SRPs.

Since SRPs were conceived, we have been asking Unity to address these types of issues, and this has fallen on deaf ears. Even after several years, we have no official response to any of these issues, or even confirmation that Unity see's them as actual issues worth solving. I have also personally received the feedback from several Unity employee's that "Only you care about this stuff", which I know is not the case.

As such, we invite you to join us in changing your profile picture from to the following image to raise awareness of these issues, and show Unity that more than one person would like to see them addressed.

 

I generally like the idea that Unity reinvents itself to keep up with new technologies and to optimize their pipeline from the ground up. And i really hope that some day (IN THE NEAR FUTURE) universal renderpipeline will be my new daily workhorse.
But for now i have to agree with you, there is too much half-finished stuff going on at the same time. These days everything seams so "agile" that it actually feels like chaos.
HDRP sometimes feels like an impulsive response to Unreal's AAA trailers and the stuff we really love and prefer unity for is slow and unconsistent in developement.
When i first heard about SRP i thought it meant a seamless transition from LWRP, over BIRP to HDRP ... but it's actually 3 independent engines now, that you can modify in their own ways!?
And get this damn package manager tidied up... I can't believe something so essential like the renderpipeline is sitting right between a "google AR ios plugin" and an in-app "purchasing system"

 

I agree with everything said here, hopefully they realise it's a bigger issue that is experienced by more than just a few people. Just because not everyone speaks up about the issues on the forums, doesn't mean they don't have to go through the same problems.

 

Done. I agree 100%. As excited as I am for all the SRP content, my only option has been to completely avoid it until it's finished.

 

Ya I agree , I use many other engines over the years (Still do ) when I first seen the new rendering, I knew it would be a mess.....I hate to say this, but its been what Unity continues to do, forget about those actually wanting to release stuff...and others who have... but we won't move to the new rendering, until its actually usable....stable... So I would agree with the OP and Oilli

 

Well i waited for like ~2 years? before i even got into SRP and it's still not production ready imo

 

That is really infuriating. I don't comment on those threads because I am not a shader programmer and have nothing substantive to contribute -- but the benefits of what you're arguing for are indisputable. And plenty other people do comment on those threads in agreement with you. Truly, what the hell has happened to Unity?

 

Living the #SRPLife over here too. The documentation is extremely weak.

 

Well, there would be a lot more still here if they had a fraction of your good will and patience.

 

While I don't agree that Unity is deaf to these issues (as you well know @jbooth some people are painfully aware), I think in general Unity needs to at least acknowledge them publicly (not through individuals) and lay out a path forward.

Here's some more points.

- Lost functionality. Things that emerged from 10+ years of graphics development at Unity are suddenly gone. Getting them back means fighting with QA, nagging every Unity person you can find, and insisting that these missing is a bug, not a "feature request you should discuss in the forum".
Examples include GPU Mesh Particles (1000x speed regression), 360° Stereo Rendering (omitting an entire industry)
- Not enough Testing in the Graphics repo. I had to personally create and PR unit tests and entire test categories for the URP where I got told "well, we can't test any combination, can we" for very common usecases (URP + ShaderGraph + VR). This goes hand in hand with the practice of pushing knowingly broken code to master and "fixing it in subsequent PRs" which almost always lead to regressions.
- Not enough dogfooding. Since URP/HDRP/ShaderGraph are separate packages, they are maintained by separate teams without much communication in the past. This leads to finger pointing ("that's not our fault") and curious cases of URP devs never having used SG, SG devs never having used URP, XR devs not touching Unity (only C++ backend) and so forth. I'm a strong believer that time spent "in the system" is important for everyone and ultimately avoids many errors and saves time.

I do believe the SRPs are the right way forward, and originally were a good idea. Deciding to develop them without a common system architect across graphics features was a bad one.

 

I like your ideas jbooth. I would also like unified workflow for URP and HDRP, one engine instead of 2 different ones.

I've made this scheme as suggestion how to unify SRP in one modular engine with inspiration of Houdini.
For example, one could create terrain instance running with foliage system and could switch between URP or HDRP for render.

Workflow and graphical interface would be the same for both SRP (shader graph UI , custom processes UI,..) only will they run in background differently.



I've also would like to SRP would become of a single instance engine, instead of installation per project base.
https://forum.unity.com/threads/single-hdrp-engine-instance-feature.914717/

 

I get the shivers when upgrading from one minor Unity version to the next. Let alone upgrading SRP minor versions. The Horror! The avatar describes best what I get to see. And the nightmare and huge waste of time that follows ahead.

For HDRP I've been thinking for quite some time now that there hasn't been any architecture concept. At all.

 

I was very impressed with the LWRP Shader Graph system and invested a lot of time in it, only to have almost all of my efforts trashed by the next version that came out.

Even the samples from Unity’s own blog didn’t work from version to version.

This in turn made me avoid the entire system forever. If anything, it shouldn’t have been shown or released until it actually worked properly.

 

We've been using HDRP for our project, and it was mostly fine so far. However i do have a couple of gripes with it:

1) The custom pass feature. Its great to have, but why the hell are you exposing only 6(!) injection points? Look at how its handled in the standard pipeline https://docs.unity3d.com/ScriptReference/Rendering.CameraEvent.html. Why not expose injection points for each rendering step like that? It literally takes 2 lines of code for each injection point, and it doesnt introduce any performance impact, so whats the matter? Why do we have to embed the package and modify the code manually just to add injection points that we need?

2) Locking most of the code/classes behind access modifiers. I understand that some code isnt designed to be accessed from outside, but some things are absolutely necessary to have access to. For example we use modified version of the HDRP/Lit shader, so we need a modified Editor GUI class as well. But can we inherit from the default LitGUI class that HDRP/Lit shader uses to write our own modification? Nope. And we need the custom editor GUI not just for the quality of life, unity uses shader editors for essential functionality, like setting keywords/stencil values, so we cant just ignore it (which is another problem IMO, editors shouldnt have anything to do with that in this case, it should be controlled with some project-wide controller). Ok, we can write our own shader GUI without inheriting i guess. So we need to do our own stencil setup as well. Ok, let me get the stencil values from the StencilUsage class. Oops, its also inaccessible due to its protection level. Great. That also means that in any custom coded shader we have to manually hardcode stencil values and change them manually with each HDRP upgrade where they decide to change up stencil values. Amazing.

Another example is rendering objects in custom passes. Unity has an example custom pass, which uses this line:

PerObjectData renderConfig = hdCamera.frameSettings.IsEnabled(FrameSettingsField.Shadowmask) ? HDUtils.k_RendererConfigurationBakedLightingWithShadowMask : HDUtils.k_RendererConfigurationBakedLighting;

Try replicating that in your own custom pass, and you'll get a compilation error, HDUtils.k_RendererConfigurationBakedLightingWithShadowMask and HDUtils.k_RendererConfigurationBakedLighting are just not accessible due to their protection levels. Why? Whats the point of doing that?

 

I don't have experienced yet the transition from a legacy project to the new SRP (Urp or HDRP) so I shouldn't express my opinion but I have faith on experienced devs and what described here is very very far from what I'd like to face when the transition will be unpostponedable.
So, please Unity devs, try to face these issues and give us the best workflow user-friendly tools possible.

 

You are just bad developers and do not know how to work with SRP!
Just a couple of mouse clicks and my 4k render has 222 fps! At the same time, it is possible to achieve maximum optimization, 0 draw 0 vert 0 tris!
If you turn off the shadows, then the frame time will become -1ms and my computer will fly to Mars.
This is only possible with SRP !!!
Graz Unity, you are the best!

Just kidding, SRP is terrible, URP works with a bunch of bugs, there are no shadows, post processing slows down, the shader graph constantly crashes, the build works differently from the editor. This is just hell to develop

 

SRP is excellent. Its just URP are bad... HDRP is fine

 

I'm working on a game that I'm tempted to switch to URP. The benefit of performance, access to shader graph and vfx graph... sounds great! But, every time I think I'm ready to commit, I run down the features I wanna use and remember why I havent.

Light cookies? Nope.
AO? Nope.
Decals? Nope.

Not to mention the amount of store assets that don't support URP. Many visual effect assets like NGSS and Aura 2. It's too much of a gamble of what your locked into, especially as a solo indie dev who relies on asset packages like these to make games that would otherwise be too complex for one person to finish.

That said, credit to the teams working hard at maturing this tech. I think it has great promise, it just needs to benefit from more cross-team communication and candid acknowledgement of what needs to be shored up to be 'production ready'.

Thanks for raising awareness on this issue. I hope SRP stabilizes in the next year; I'd really like to use it.

 

https://www.reddit.com/r/Unity3D/comments/hci3nh/unity_users_formally_demand_improvements_to_srp/

I'd suggest keeping the profile images in place until the problems have been suitably addressed.

 

Had so many problems with URP breaking on version change. Also trying to get into DOTS is a nightmare. Little solid documentation, major differences between HRDP and URP - that has to indicate a design issue!

 

I switched back to the built-in rendering pipeline and felt relief. Everything was consolidated, right there, all built-in, nicely integrated, easy to work with.

Prioritize compatibility or instead of sweeping existing systems under the rug, upgrade them?

 

@jbooth
Rename topic to "URP/HDRP Life". Don't blame whole SRP-api just because of 2 unity's in-house realizations are bad.

 

I mean it is pretty scary that the ENGINE devs themself fail to use their OWN ENGINE feature , like there is a proverb 'the shoemaker’s children are ill-shod'

As a hobbyist i don't really care that much if something is stable or not, it only frustrates me that some of the assets i like to use are not up to date or break with every version release and have to wait some time for the devs to fix them. So that is my only gripe with current state of the SRP, but considering working with Unity is some ppl livelyhood, i can imagine the frustration of constant overcoming the issues and head bumping, not necessarily because of their fault. I wish Unity took this stuff seriously and address the complaints and issues with SRP

I think someone has raised a good idea how they should approach it. Admit it was a mistake, remove SRP and other big 'preview' stuff from current Unity. Release Unity LTS and focus on Unity 2.0 with all those features not beeing constrained by current architecture , but i guess that will never happen.

 

Unity's OWN terrain system are bad. And jbooth making buck from this.

 

the fundamental issue is with SRP, because it does not provide the proper abstraction layers to make common rendering tasks compatible across pipelines, or even between versions of the same pipeline. The layers built on top can not be more stable as the foundation they are built on.

 

+1

 

Couldn't have put it better myself. Hence why I am still using the Standard RP as my daily driver.

 

Totally forgot about this. No support for decals at all in LWRP

 

I also wonder when ST 8 will finally get its support. Are we still going to have to dream about working GPU Instancing with shadergraph?

 

In with this as well!

Huge pain in the a** supporting graphics assets across all render pipelines when nothing is consistent between them and the existent API seems to break or change every few versions.

 

I completely agree. They are abandoning Built In renderer, without SRP (URP & HDRP) being fully ready. It leaves all of us caught in limbo. There are amazing assets that won’t upgrade to SRP until at least 2020.4 LTS due to current SRP standing. I want SRP to work; it makes sense. But the approach has been ham fisted, community deaf, and just all around ignorant.

As an indie dev. I have thousands ($$$) poured into this engine which makes it tough to say, but Unreal looks better every day that SRP continues to suck and Built In is abandonware. Just saying.

-N.

 

I hated how far behind Unity is with the times. They spend so much time diversifying that they just aren't good at any one thing. There are open source engines that are catching up to unity right now.

I've sunk 9 years of my life into learning this engine and the honest truth is there have been nearly no real improvements since unity 5. They continue to fall further behind. Unreal is releasing an incredibly powerful tool that already dwarfs the srp in a year. How long will it take unity to catch up?

Unity needs to invest time into producing full featured AAA games on their own engine so they actually have an idea of how terrible it is to produce games with their game engine.

 

They really should do that.

 

Unity do actually work with AAA (and all other) developers on shipping games, they have a very good idea of how the engine is used in production.

URP has growing pains like all new features, replacing the core renderer of Unity is no small feat. There is some push back from the XR community that this was recommended as the way forward with essential features missing*. Perhaps in this area URP could have been tested more before being recommended as a solution for VR and AR.

(* features missing: shadows over transparency, shadow fading at distance, shadow resolution blending, ambient occlusion post processing, etc.)

Objection is mute for the most part as standard renderer is still available and will be for a long time. It does all the things but performance might be a little less than URP.

 

The standard renderer had better be available for the next decade at least, that would be a catastrophe to remove.

I dropped URP for all assets I tried to support it with and have no plans to support it unless something amazing happens.

I do hope Unity figures this out. I never ran into a case where the standard pipeline fell short and only URP could give me a feature I wanted. HDRP may be a different story but I've never played with it.

 

except that they are letting it rot, adding new features that are SRP only, or breaking them in standard or not properly supporting them (terrain instancing doesn’t work with surface shader tessellation. Surface shader bugs are no longer fixed). Essentially standard will continue to crumble from lack of support, as they only care about SRP now.

 

I wonder if a refactor of standard pipeline would have been a good intermediate step instead of SRP. This is all hindsight and probably doesn't matter, but it may have been interesting to try and remove deficiencies from standard pipeline first as a baby step...

 

There was nothing preventing the development of SRP as a refactor of the standard pipeline - though it's obviously a lot nicer to start fresh and build something new and exciting along with the SRP.

In fact, when I was at Disruptor Beam we had a custom SRP that worked with surface shaders - it simply setup the same constants/passnames/etc and everything continued to work as normal. This allowed us to develop with existing shaders and asset store stuff until we were far enough along to put in our own lighting model, etc..

In my mind, the idea workflow would have been to make the render pipeline scriptable and replace needed functionality, such as Grab Pass, Graphics.Blit, etc, with the new functionality as optional. Basically, introduce things like CustomPass as an optimization and remove the old techniques over time. This would mean there would be a single way to insert a custom pass, instead of each render pipeline providing their own versions. Sure, perhaps the enumeration of where to insert a pass would be different, but right now there is no similarities between the two pipelines.

I'd have introduced a replacement for surface shaders that cleans up the old system, but does the cross compilation in a C# system, such that each SRP can take what the user has written, parse it, and decide what code to generate from it. The Shader Graph would have written to this format, such that there is a common abstraction layer that takes user-written shaders and converts them into SRP specific shaders, which doesn't care if that data comes from a graph, a text file, or any other system that might generate that data. Then when you decide to spin off your own SRP, or extend it via some asset store tool, you can modify the code gen to add whatever passes you want - and shaders made in the graph or a surface shader like format just work for the most part. Yes, if you decided to make the dreams renderer in Unity, you'd likely not have them be compatible, but in the case of HDRP/URP the inputs to the lighting equation are similar enough to abstract. And I suspect most renderers for the next 10 years will be the same.

 

Outside of Hearthstone, which big budget AAA game has been released with Unity?

 

What saddens me most is that HDRP actually has some genuinely desirable features that are difficult to code manually (or find a github repo someone else made lol) but is still not suitable for production use yet.

You could make the argument that GTFO or Escape from Tarkov fit the bill. But hardly anything on the scale of Fortnite or Unreal Tournament.

 

They don't really though, both of those are made from indies. Maybe Recore? (the game famously plagued with performance problems?)

There aren't really any AAA games made in Unity. There doesn't exist the equivalent of Unreal's Final Fantasy VII: Remake for Unity. It simply doesn't. At best it's "good looking indie games" (which are not AAA) or "technically AAA, but it concerns games built with their 4th tier teams, usually for mobile, and with indie sized budgets" (which again are not AAA, although I'm looking forward to someone arguing how Lara Croft GO is the equivalent of Gears of War 5).

Whether that matters at all for indies is a different matter. My opinion is that it doesn't.

But let's be clear, if Unity is saying they are talking to AAA that use Unity to ship AAA games, what they mean is that they are talking to themselves in an empty room.

(and I'll bow out of this thread now, since I'm getting off topic)

 

Thanks for pushing for this Jason.

 

I feel this strongly, have had so many setbacks on VR/AR projects when trying to use URP for supposed performance gains. After a good year and 120 bug reports to Unity, most of my VR and AR issues have been fixed.

 

In production on current and new projects, I only use standard and Amplify Shader Editor in LTS versions of Unity. TBH had mostly forgotten about URP existence myself. See some great things from time to time happening, but watch from very far away, I just don't have the patience (or time) anymore.

 

I want to add the fact that HDRP does not support custom lightning and it never will. This is such a terrible design decision. I made a water shader recently with Built-In and I ended up with a more realistic result using custom lightning, because it gives much more control.
HDRP is like the bad part of Unreal Engine shading workflow. It's monolithic. If you want to make something a little bit different than usual, you basically have change the code of the pipeline.

I made a post about it : https://forum.unity.com/threads/support-for-custom-lightning-in-hdrp.793416/

This is Unity's answer : "it is not possible do to custom lighting with HDRP by design"
So, you really need high fidelity graphics + custom lightning ? Well, bad for you, it seems it's never going to happen.

 

I was shocked to find out that built-in deferred is much faster than URP.
Could someone create AND MAINTAIN a thread that lists all that's broken or regressions from built-in to SRP? Or a google doc, that'll help a lot.

 

Unfortunately this is very common Unity behavior. I fear that Unity is actually too reliant on feedback and they use it as a weapon to cut corners and narrow the scope of their projects way too far. That way they can keep pumping out new features to attract customers and when anyone complains they can just say "well we listened to customer feedback and this is what they asked for."

Listening to feedback is good, having a tight scope is good. But, just like everything else in life, taking a good thing too far turns it into a bad thing. Customers shouldn't be expected to list every requirement of a system before you build it. At some point you have to ask yourself "what are reasonable expectations for this system?" Custom lighting seems like an obvious blindspot for a game engine.

Another example is UI Toolkit. They aren't even trying to reach feature parity before shoveling out version 1.0. The list goes on and on.

 

Unless youre talking about shader graph specifically, HDRP does support custom lighting. It doesnt support custom deferred lighting, but in forward and with custom coded shaders you can do whatever you want. We do custom per-vertex lighting this way in our project for particles for example.

 

No it does not. Read the thread I made about it. If it was the case, then amplify would have already supported it. You can't access the lights data (shadows for example) generated by the HDRP, because everything is made and merged into one big loop.

It is still possible to do it, but then you would have to rewrite a custom light process all by yourself, like make your own custom shadow masks. You would have basically 2 lightning processes for only one rendering. Very bad for performances.

With built-in or URP, what's good about them is that you can acess light data that are created by the pipeline, and then use them in your shaders. You don't have to re create the same data twice.

"We do custom per-vertex lighting "
You probably don't use the light data generated by the HDRP. That's the meaning of "custom lightning". What you do within HDRP is unlit, unlit by the HDRP lightning data.

 

Ok, let me rephrase. It doesnt officially support custom lighting, but you can hook up all the necessary standard includes and get all the lighting data you want. It just might change in the future, which might break your shaders, which shouldnt be hard to fix anyway. Again, we've made lots of custom lit shaders in HDRP for our project. Just look at the ShaderPassForward.hlsl and LighLoop.hlsl code, and try to replicate that.