Official What is next for us at Unity with Scriptable Render Pipelines

The flexibility was actually way higher before there was URP and HDRP. I could deploy to all platforms from one Unity engine and use all the shaders and all the post processing and just tone them up/down for different platforms.
Now most stuff does only work in one or the other and the one thing which could deploy to most platforms and biggest spec ranges (old builtin RP) is not getting developed further properly anymore so it doesn't get any of the nice features for new graphics possibilities etc.
So Unity got a whole massively more less flexible, less versatile, less trustable, less stable, all thanks to this split up of everything.

 

This is a very narrow and one-dimensional view of Unreal and its workflows.
It offers very large flexibility, but it is sometimes hidden behind quite steep skill-walls (like C++ source changes etc)
Basically you can turn the whole engine upside down, you just have to dig quite deep. Unity does not even offer that level of customizability to begin with, because you (aside from paid extra) don't get source access.
You can build stylized shading in UE (Borderlands 3 shows that) and you can do easy toon-shading like this which does neither include 6 blog posts, nor source-rebuilds or similar.

If you are really interested, I'd suggest you take a bit of time to read this, if you want a more balanced view on the differences and similarities of UE/Unity's approach to certain things.

 

I've said this many times, i say it again: not LWRP, nor HDRP was not planned as a production pipelines. LWRP was an example, HDRP was an internal renderer for cinematics. Nobody even thinking about extensibility, exchangeability, migration and asset store stuff support.

 

Idea could be to create simple Workbench unlit mode renderer where you could create whole game, test it and then you may choose URP or HDRP in the end. That would require camera depth pass abstraction layer, terrain and particles abstraction data.
Postprocess and lighting could be added in final pass when URP or HDRP is chosen.

 

There's very little objective or balanced take on the blog post you linked. Most of it was written by user fed up with Unity while he had used UE4 for few weeks at most.

I'd continue with UE4 extensibility and where it really gets frustrating but this thread isn't about Unreal.

 

-->that's not a feasible solution i'm afraid. I mean the look of the game is an important aspect in most projects and so one would want to establish a look throughout production and know one can achieve that look on all platforms at good performance throughout production.
What most games do is either establish that general look for lower specs and toggle on fancier stuff/settings for highest end hardware or establish a look for higher end hardware and adjust settings/toggle stuff off which only runs on fancier hardware then when deploying to lower end hardware; not make a whole game in some barebones pseudo look and then in last step decide a fully separate RP which completely changes the look on everything and can not be easily switched back and forth between different settings/quality levels.

The whole ask for a single RP (at least facing to the user looking/usable like a single unified thing) is so one can make the whole game in one environment again and check instantly again how it looks with lower/higher settings constantly throughout the workflow in non destructive, easy and fun to work with nice iteration workflow.

 

I agree and yes, you are right - it isn't. I just linked that post in particular, because at least someone spent a fair bit of time explaining certain differences and the user i replied to certainly didn't care to really look into some of the aspects that the user complained about. I just wanted to offer some further reading and this was the fastest link i had at hand. More balanced was meant in relation to the remarks made by said user so far.

But i also agree - it's not about Unreal here and i didn't intend to push that conversation much further in that direction.

 

I'm saying this stuff as someone who has spent a year and half as tech lead on a mid-sized Unreal Engine project. We made many, many modifications to the underlying engine (we even paid for a custom support line to Epic engineers). But just because you have access to the source doesn't mean it is worthwhile/efficient to modify. Even just to rebuild the Unreal Engine, Epic recommends having a cluster of computers using Incredibuild (distributed compilation).

I'm definitely aware that post-process toon shading is a thing, but it creates a very different (grittier) visual style than you get from a proper toon shader.

But yeah, didn't mean to start a war, haha. Just felt the conversation was a little one-sided, and wanted to express that there are folks out here building complicated game projects that deeply depend on Unity's existing SRP flexibility.

 

Yeah, that is a thing, but it is also a thing that a very large amount of unity content creators/users (I'd bet the large majority) are not touching the URP and HDRP with a stick and so are force stuck with old not developed further builtin RP because this separate RPs is a broken incomplete mess (and while not combined always will never be feature complete as in all major features available in each and deployable to all platforms from each/a single thing).
So one thing should be clear by now: It can't go on like it is now (and has been for the past few years) : basically to put it blunt and brief: an utter unreliable mess for anything else than using builtin old pipeline (and again, with that not getting most nice new feature additions on graphics side, so that not a good offering either).

Unity does a lot of polls, was there a poll on what percentage of users is happy with this current setup of Unity with the separate new RPs and the old builtin RP not developed further anymore? I imagine replies to that would be quite eye opening if not already clear by current feedback over the last few years by the majority of users.

 

I think the difference is just that I'm content to wait a few years. Unity does clearly seem to be working on this, albeit fairly slowly. I'd rather they find a solution that works for everyone, and not just bounce back and forth between trade-offs.

I do agree that lots of people probably aren't / can't be quite as patient, though.

 

One of the advantages Unity has over UE4 (and I say this as someone who would pick UE4 over Unity for almost every new project) is that messing around with the render in Unity has a much lower bar of entry and iteration times compared to UE4. The built-in RP accrued a lot of extension points allowing users a lot of freedom in doing custom rendering stuff, even without access to the source code. It was also easy for 3rd parties to offer plug-and-play add-ons.

That is not quite the case with the SRPs.

The issue is that the core SRP was designed to replace the chaos of extension points with a flexible API, with LWRP/URP and HDRP being implemented on top of it. The original idea was always that people would modify the RPs themselves (or write their own) instead of extending them via extension points, but over time it became obvious this was not a viable solution: creating a state-of-the-art renderer takes a significant effort, very few people have the know-how to modify the internals of the SRPs, and without some sort of common higher-level abstraction different SRPs ended up being asset-incompatible with each other.

Add the dearth of stable extension points, which discourages 3rd party add-ons, and we see Unity kinda painted themselves into a corner.

 

Still no blog post on the future of the graphic's repo.

But! Noticed this morning that they un-archived it and appear to be preparing it for mirroring with their enterprise instance!

(PS. Why in the world they choose Github Enterprise vs PlasticSCM? They own Plastic now and it's better than github in every conceivable way + can push to github if required.)

 

↑ this, they bit too much that they can't chew it now...

 

Sounds nice.

But given how many VR developers are (and have been for most of 2020) using HDRP by choice - on VR that is little more than a mobile phone duct-taped to a couple of lenses (Quest etc) ... I think you need to reconsider your "absolutely not suitable" declaration.

 

Sure, you could use it, but it's a waste. Using a deferred pipeline (HDRP) on the Quest will make a game 4-5x slower than a forward pipeline (URP), for the exact same graphics.

All I am saying is that there is no and never will 'one pipeline suitable for all uses'. If HDRP had to support Oculus Quest they would never be able to add the cutting-edge graphics features it does have.

 

I think you may need to reconsider your stance here. As far as I know, HDRP is not supported on any of today's mobile device platforms. Can you provide a source on these developers or anyone using HDRP for VR projects for Oculus Quest? As far as I know, even the Quest 2's hardware is not equipped to handle HDRP. If someone actually got this to work, it's definitely not supported by Unity. See the list here under "HRDP is only compatible with the following platforms:" https://docs.unity3d.com/Packages/c...finition@10.3/manual/System-Requirements.html
Perhaps you are confusing this with developers using the Oculus Link cable to use their Quest as a completely tethered HMD? Which is beside the point as it requires a high end PC to actually do all the heavy lifting not the "mobile phone" chipset inside the Oculus Quest.

Related to the clarification above. You can't use HDRP with today's mobile platforms like Oculus Quest / Quest 2 as-is / untethered. But there are some potential exceptions of mobile platforms on the horizon though Unity doesn't currently support or provide workflows for them, e.g. HDRP could potentially run on the latest iPad Pro because it has a remarkable and modern GPU that beats any other mobile GPU in existence. (Though still underpowered compared to to a recent Console or high end PC, the platforms that HDRP is focused on.)

It's true in many cases it would be a waste. Using a deferred path will take a heavy performance hit on most of today's mobile platforms as the GPUs are underpowered and optimized for a forward path, but it wouldn't "be the exact same graphics." There are many pros and cons to forward vs deferred in terms of graphics fidelity and features. (e.g. deferred path allows for many more local real-time lights and certain effects without additional performance penalty but yields lower accuracy in some areas, forward path has a lower performance overhead but allows for highly accurate anti-aliasing and higher geometric accuracy.) More info on that here in the HDRP docs: https://docs.unity3d.com/Packages/c....3/manual/Forward-And-Deferred-Rendering.html
It is also worth noting that URP will soon have a deferred path which while in general will be discouraged to use on current mobile devices, it will have niche use cases for certain projects on certain mobile device platforms, and may see more adoption as mobile GPU architecture advances in the coming years. More info here on the URP roadmap: https://portal.productboard.com/unity/1-unity-graphics/c/10-deferred-renderer-support

I agree that it makes no sense for Unity to make HDRP work on the current Oculus Quest hardware. And I concur that there is no 'one pipeline suitable for all uses' right now and there will likely not be for a very long time, if ever. Though, never say never --a decade into the future (give or take a few years) that could come into question as every platform including mobile and web will soon have GPU compute capability, which is one of the main dividing walls between URP (compute not required for legacy device support) and HDRP (compute required for the best features and performance.) There is also the major shift in traditional (OpenGL, WebGL, Direct X 11-) versus modern graphics APIs (Vulkan, WebGPU, DirectX 12+). Once the platform landscape starts to homogenize in these areas, I think it's very possible in the further future to achieve one render pipeline reasonably suitable for all uses, but still highly unlikely we'll ever have one pipeline ideal for all uses. Especially as Moore's law is dead the market will demand further advancement in entirely new state of the art tech such as real-time ray tracing and neural rendering that may create new rifts in graphics hardware architecture and APIs, render pipelines, etc. Regardless, in the case of Unity, improving the workflows that let us target multiple render pipelines flexibly is a wise path as it will get us through the current divide, and also gives us a foundation for future generations of render pipelines whenever the next major paradigm shift in computer graphics software / hardware occurs. Transitions are difficult, but important, and inevitable.

 

Someone send Unity a memo that transitions need to end at some point though.

Although I guess if it's only the users suffering, Unity doesn't really have to end the transitions, especially with so many users somehow defending them.

 

This isn't happening on games industry. Things have always moved at fast pace here (especially in comparison to traditional software development).

 

If that's true then there's a gap to be filed in the software landscape : the need for stable game development software focused on the users.

 

there used to be this game engine called Unity that fit that nicely.

 

What fast pace? We are under the same transitions for many years. The pace is slow. A transition starts, then it never ends, people get left with either deprecated or unfinished features.

 

Unity dominates game-jams mostly because of WebGL. I believe it's why you almost never see Unreal Engine in jams, people are too lazy to download games to play them for a game-jam. Uh, the fact most games are 2D sure helps too.

Personally, I started disliking gamejams because of how everything is 2D. Everyone is interested in 2D, or likes to see 2D/pixel/sprite art more because that's what their game is as well.

So in the end, 3D games get pushed out/disliked. WebGL helps with that.
Oh well.

EDIT: Looking at OP's post. Things didn't go to plan :/
Many things on that list aren't in, although they were meant to be ready by now. And many aren't even on the Alpha version.

Also... latest LTS (released few days ago) version doesn't have Point Lights for URP.
Gotta wait another year

 

Or even removed features with no replacement like the Display Resolution Dialog, which I'm still not happy about.
Anyway here's a quote straight from the horse's mouth, before he became CEO of Unity:

This is the person running Unity right now. The simple fact of the matter is that Unity has a direct financial incentive to drag out features for as long as possible in order to keep people subscribed for as long as possible.
When you are 100s of hours into developing your game and you run into an incomplete feature, you're really not very price sensitive at that point in time. When you're deep into development you're well invested in it. So you'll subscribe a little longer to get the latest bug fixes.

The difference between Unity and Unreal is that Epic doesn't make most of their money from indie developers or subscriptions. They make their money from big studios like EA or ILM using Unreal (plus all the Fortnite money). So they have every financial incentive to get everything up and running as quickly and flawlessly as possible to keep the real customers happy. A single studio using Unreal pays for the equivalent of thousands of indie subscriptions.
Unity used to have a financial incentive to fix and finish things quickly under the old license purchase model (before the switch to subscription only) because if they didn't, then people would stick with the old version of Unity and wouldn't upgrade their Pro license to the latest version.

 

I'm normally not very vocal, but I have been using it professionally for a long time, mostly in projects not related to gaming. We also have some tools on the asset store (OfflineRender is the oldest) since version 5.6, which has always been hell to support even without the SRP, with Unity minor versions breaking stuff. When SRP started, the issues were onto a different level, we always try to support our users, it's not our main income luckily, but we are proud to be fast at least replying and finding fixes.

Last year we started a new project, this time a game, we started in Unity, but after a few months of development we switched to Unreal, and I can say we are more than happy with the change, C++ isn't an issue for us, but we have written less code then we had for the Unity prototype, and we don't have any spaghetti blueprints. The tools for game development are all there and feel more intuitive.

We won't drop Unity at least just yet, because there some projects we need to support, but almost all future work will be done in Unreal for sure.
And the old meme for Unreal compiling shaders, well I could create a few for the new wait dialogs in Unity, at least I don't have pink shaders for a few seconds on Unreal like in Unity when playing in the editor.

 

I think having two separate SRP's has mostly resulted in a hot mess, with neither hitting the sweet spot that games want.

The real dividing lines aren't some vague low vs high end. It's very specifically mobile vs most everything else when you really break it down.

I think in practice it's difficult to argue that two pipelines are better in light of actual development history. Sure if you need to support two different deferred implementations that's significant extra complexity. But theory and practice are different things. And how development has actually panned out doesn't do a lot to support their original basis.

But there is enough momentum to override actual good decision making I'm afraid. So we are stuck with the paradigm.

Mobile is probably going to come out ok. Plus there built in still a thing.

HDRP is really strange to me. You would think Unity understands by now what it is they are good at. Which is providing building blocks not high level features. But in HDRP you have a bunch of work going into higher level stuff where they have a lot of half baked implementations. While at the same time core api's are bug ridden or simply not supported.

HDRP would be awesome if it changed focus towards making the fundamentals work well and stuck with what Unity does best. I think since so much internally is a black box they thought they had to provide a lot more. It's not turning out well.

 

Built in is/was and probably will still be the best one for a long time. Stuff just works in built in while in the new srp everything equals to "wait for this , compile that, bake shader , etc". The overall workflow in the new SRP is horrible compared to the impressively performant and bug free built in.

 

wow, really? built-in render pipeline doesn't make you wait to compile shaders, has no bugs, no major limitations, no lack of extensibility, and no performance issues? that's quite a starry eyed viewpoint you have of BRP (Built-in RP) to say the least. the scriptable render pipelines have some issues, sure. and the first few years the SRPs were very rocky, almost unusable even in "production ready" releases, so many are rightfully burned by that --but they are quite stable now, with URP outperforming BRP in many performance critical scenarios and platforms, and HDRP's state of the art physically based feature set outclassing BRP across the board. overall extensibility of SRPs eclipses BRP no question. workflows still could use continuous improvement, sure --either way each RP is a mixed bag of pros and cons that can be highly subjective depending on your project, use case, and team member's strengths and background. no render pipeline is one size fits all or unequivocally better than another, in the same way no engine is the best fit for every project / use case.

 

The problem is that many feel (me included, to a certain extent), that if instead of the SRP mess we're in, they kept iterating on Builtin, then indeed it would have none of those issues at this point, yes.

 

SG shaders compiles 1000 times slower.

 

I mean sure that would have been great if it were possible --but it's pure fantasy. Built-in RP has had major deep-seated tech debt in it's aging codebase that needed to rebuilt from the ground up one way or another. No amount of incremental iteration was going to solve all of its problems and limitations. Don't get me wrong, the way Unity handled the SRP rollout and especially the expectations was a massive blunder that damaged its reputation. It will be an ongoing challenge to repair. But sinking all resources on iterating on the existing Built-in RP (without starting over from scratch) wasn't going to work either. We would have needed a rewrite, "Built-in RP 2.0" so to speak. Which is ultimately what is now being done with URP after Unity's course was changed due to community feedback (better late than never, it is going to eventually supersede BRP in features / workflows, something that the now defunct LWRP was never intended to.)

 

idk about a 1000 times slower but yes it's a fair criticism that shader graph compilation is some order of magnitude slower than shader lab shaders. aside from optimizations with shader graph and the shader compiler (which there has been and will continue to be) we sorely need a shader lab like written code API for shaders in HDRP and URP. Unity really ought to acquire @jbooth's Better Shaders outright and just pick up from there. I certainly had a laugh of recognition when reading this Shader Graph PR like "oh I was wondering about those ridiculous number of #ifdefs, makes complete sense now." Code generation / meta-programming can get very messy and redundant quickly if one isn't extremely careful:

[ShaderGraph] [2021.2] Remove the vast majority of unnecessary keyword permutation #ifdefs
Something like 99+% of these #if lines don't actually do anything, as they essentially boil down to #if true (basically they are active in ALL permutations).​

 

The real issue is that not even Unity team has the know how to change the pipelines and took like years to just put shadows in point lights in urp.

I cant really understand how it would at some point be considered viable that users would make custom pipelines, especially since doing so makes almost everything in asset store incompatible.

How could they possibly started with such a plan is really beyond comprehension.

That said, pipelines now are more finalized and seem to work between versions generally, though will be some more years until there is a real stable environment.

 

I dont see anything that was not possible in standard, you could write custom shaders and do most stuff and was extremely easier to do so. Plus was faster than urp and way faster than hdrp.

Only pipeline perk i see is the rather useless and overhead inducing ability to customize the render pipeline.

 

I get your stance from asset publishers standpoint (yes it's pain to deal with SRPs for that purpose), but for actual devs using Unity to build games etc, the ability to customize SRPs is a huge win and gives us access to things that we didn't have access to before. Of course it's still not full access to renderer due to part of it being still on native side but it's still way better than before IMHO.

 

I partly agree, but isnt making a custom pipeline essentially making everything in the store broken ?

For most indie devs that need the store help and ready to use assets, this i assume would not be a viable solution. Of course not saying that is bad to have the customization option, just that is so hard to use that is only for special cases.

 

That would depend on your modifications, I'd assume most things people change are not changing the existing hooks so that shouldn't be an issue. Also using SRPs today does mean you already can't rely on Asset Store offerings as much as there's never support for every released SRP version. Some publishers even only support LTS version and almost nobody supports betas and alphas so you can't even test things early on if you don't want the store offerings to break in all directions.

 

Feeling this right now with ILM helping drive virtual production focused feature development for Unreal. Things like clustered / distributed rendering, explicit multi-GPU render pipeline scalability, integrated video capture device support, and lighting control protocol / LED mapping support. While for Unity it seems like yet another area they'd like to focus on someday but are lagging behind in significantly. It seems that for better or worse, as a product, Unity tries to be everything to everyone, instead of choosing a limited amount of use cases to truly focus on like Unreal does.

I don't meant to derail too far off the topic of scriptable render pipelines but for what it's worth: this feature is now confirmed to be returning. (it is in "Planned" status.) See the Unity Platforms Roadmap roadmap for more: https://resources.unity.com/unity-engine-roadmap/platforms
"Reintroducing the Display Resolution Dialog window to allow developers to change their display and resolution. We are looking for feedback on how you had used this dialog in the past, what features were most useful for you, and any functionality that you did not use."

 

Glad to see Unity's fans share Unity's values on iterating and refactoring.

 

As a side note, Unity did sort of give an update on all this in this thread: https://forum.unity.com/threads/package-requirements-in-shaderlab.1108832/

It seems the official plan for Unity and SRP really is "4: There is no plan at all other than "keep hacking at URP until its stable and we can get rid of BIRP."

 

The issue is that even if they hack URP until the end of time, the overhead to parsing the pipeline will always make it much slower than standard imo given feature parity, from what i have seen URP is so far behind Standard that i cant see a way to match it, only hope is that will take so many years to finalize it (i expect the URP Beta to finish in 3 years at least) that hardware will breeze through the new extremely less optimized URP engine.

Which of course is a laughable wish to have, but what to do if Unity decided to make a slower backend for its rendering and try to make it as default.

Until then, i am still enjoying the extreme performance of Unity 2018 + Standard Pipeline, the experience is like a Cheetah comparing to a Sloth in Unity 2019 + URP.

The difference of rendering and editor speed is just VAST at this point with new Unity and pipelines be extremely sluggish comparing to older ones, and Unity 2020-21 make it even worse, there is no way this can be fixed imho, but still keep some hope they can at least remove some of those never ending new wait times in editor, so can do some serious work.

I cant really work when for every single small action in editor i get some random popup with a waiting time, this is like a bad joke. This is definitely worse than URP bad performance.

 

I'm a Unity fanboy, but everybody has their limits. Keeping my eye on what will be said at tomorrow's Unreal 5 Dev Tools talk.

 

I generously estimated the same timeline.

This does seem to be getting worse. Can take a full minute for me to click the dialogue box to select a shader. Granted its sped up after that first minute (which it wasn't for a while) but still Really annoying.

 

URP is faster, I believe we already discussed this but I plan to eventually go back to doing a bunch of real-world production like tests and, unlike what I did previously, publish my finding publicly. Although all the testing I did privately says that URP performance is faster. Ignoring editor perf/missing features.

Whenever I'm done with the tests, I'll ping you in the thread (hopefully I'll remember)

 

I dont recall, but i think this metrics were before parity to Standard, e.g without point light shadows etc

Would be interesting to see a 1:1 comparison at some point for sure.

 

This benchmark project for comparing performance of Universal / URP to Built-in / BRP on various platforms (which will vary of course) seems like a good place to start:
https://github.com/Unity-Technologies/PotatoBenchmark

 

I'd really want to see some official update for this thread / new thread to give some more recent info on this threads topics. It's been a year since the initial post and especially the cross-pipeline 2021 targets mentioned on the original post look like they are going to miss that target. I do see constant progress on github but these things seem to take their time.

Would be nice to see some recent update how and where things are going today.

 

I asked for that in that thread I linked and its gone very quiet from Unity since I did...

 

I will check out, thanks.

Also i will try to do a basic comparison in my mobile volumetric clouds system, so far i see in standard the fps is much higher, but could be a number of reasons as i tested different scenes, so i want to isolate just the clouds from my mobile demo (shader is same in both standard and URP) and pass that scene to URP directly in a latest Unity version and see how they fare in comparison. Will post results asap.

 

aaaah... this thread aged like good milk.
Still waiting for the "shader programming abstraction layer in the spirit of surface shaders" 7 months into 2021...

 

Its ok though. More than two weeks ago Unity mentioned that they would start a conversation about it. Its not started yet but it will soon.....

Totally not a worrying sign that if it takes that long to start a conversion about work, how long will the work take?

Context:
https://forum.unity.com/threads/package-requirements-in-shaderlab.1108832/page-2#post-7291690