Official Blog Post Series - Games Focus: Rendering that scales with your needs

What I am most interested in is the work going on on the gpudriven branch that has become stale due to the changes to the graphics repo. Any news on that that can be shared ?

 

Some links are on a private product board. Please make them public or remove the link

 

That's really exciting!

 

Very interesting and (IMHO) a step in the right direction for SRP.

Will the 'Block Shaders' system include postprocesses or will they only be used for object materials?

If not, any plans to unify postprocessing? That would be very cool !

 

In 2022 there is full screen shader graph, including postprocessing and custom pass. Is that what you seek?

 

I meant shaders created using text, as I understand 'Block Shaders' will be. I work faster with text

 

This is very good but i personally think this info can reach more people with a youtube video

 

The biggest dream for URP and HDRP are still that they would become a single pipeline with a quality slider. This is a major edge that Unreal has over Unity, that Unity forced you to pick your poison; permanently lower visual quality with URP but running everywhere, versus higher visual quality with HDRP but losing a part of your audience because it won't run on most mobile devices.

Unity has forced this Sophie's Choice scenario on all users. I realize that the HDRP contains a lot of stuff that isn't appropriate for a low-end mobile device. But choosing to support end-users all the way down also means that our product is permanently barred from looking as amazing as possible on a high-end desktop.

All the 2022 additions are certainly nice. But the elephant in the room is that it's impossible to make a product with Unity that looks as good as possible on a high-end desktop, and runs serviceably on a mobile device. It's a major loss that we're still grieving having proceeded with URP, and having only left Unreal because of Epic's shenanigans.

We only have one feature request. One render pipeline with a quality slider. I can't understand why you can't just conditionally compile stuff out. You make your own compilers! How is this beyond your skills?

 

AMD released new realtime GI solution which will be open source. Could you get this into SRP as soon as available?
It's under here https://gpuopen.com/learn/publications/

GI-1.0: A Fast and Scalable Two-level Radiance Caching Scheme for Real-time Global Illumination
https://www.phoronix.net/image.php?id=2022&image=gpuopen_gi_10_med

 

I'm very much looking forward to coexistence cause the platform limitations are the main reason I didn't even consider HDRP and opted for URP.

One thing I noticed is that it was mentioned different scenes can be for URP or HDRP. Is that more or less the setup? Is the reason cause lighting and scene configurations are so different?

Can the data between scenes be synced otherwise? Or is it expected to utilize prefabs to manage the two separate but effectively similar scenes?

I can understand this may be a challenging transition hence the need for two scenes if that's the case.

What's the expectation or goal of the workload for a formerly URP project to start adopting HDRP/URP workflow?

 

The birth of the two render pipelines has been a painful one, and the wounds they have inflicted go deep. I am delighted to hear that the healing process has officially begun. Yes, sanity has arrived as an afterthought, and much can be said about all the could-have-should-have’s to avoid the absurd growth in complexity, but I doubt there is much to learn from scrutinising parents past decisions. Instead, I sincerely hope the ambition to “increasing the compatibility between URP and HDRP” is an absolute top priority. The pain of learning two newly invented ways of doing (roughly) the same thing, while the legacy way is still lurking around and adding to the confusion is (mildly speaking) frustrating.

Efforts like Shader Blocks and the adoption of Render Graph in URP gives me reason to be optimistic. Surely “Render Pipeline Coexistence” will be a mess at first, but I believe it is the way forward as it will inspire/force more alignment between the two render pipelines. Throw the two youngster into the same yard and let them settle their arguments.

Much work is needed to make this Duality become Unity again, a hallmark of simplicity in design. Cheers to everyone at Unity pushing this agenda.

 

I'm looking forward to the day where "URP" and "HDRP" are simply two different default configurations/components on top of a core rendering system.

 

Unity was built with and around the Asset Store. It encouraged people to buy and build with a big variety of assets from different developers with different maintenance approaches. I have entire workflows built around assets that provide something I could not build myself. That would not be an issue - but the introduction of the render pipelines, each progressing at different rates is just a big mess.

Some developers are updating compatibility, some are even forcing a certain pipeline. Having them in a project at the same time is no longer possible or extremely buggy. So yeah, as someone working with many assets the decisions of the last years have been alienating and very frustrating - especially since the whole asset / package workflow was so encouraged by Unity itself.

 

Is there any information on when the standard pipeline is planned to be deprecated ?

Also will this mean all projects that use it will be btoken completly ? Or will remain as a backend thing ?

The main issues are that URP does not support replacement shaders like standard, with grab of material properties and also is far slower in image effects.

So in some cases standard is still the only option.

 

Hi, thanks for the heads up

Is there any plans to recreate the full functionality of replacement shaders with the URP before remove the standard ? Currently can render the objects with a custom shader using the renderer feature, but the material - shader used does not inherit the same named parameters from each material of the objects.

EDIT:

I see a similar feature in Unity 2022, seems like is what is missing

https://docs.unity3d.com/2022.2/Documentation/ScriptReference/Rendering.DrawingSettings.html

Is this planned to be in Unity 2021.3 as well or is decided as 2022 and above ?

 

URP Post Processing with multiple cameras

https://forum.unity.com/threads/pos...ameras-is-currently-very-problematic.1028533/

It this still an issue?

 

Thanks for the clarifications, is very useful

 

When is coming Enlighten realtime GI replacement in Unity, non RT based and no lightmap based? Something like lumen equivalent.

 

https://forum.unity.com/threads/glo...es-in-2022-2-and-beyond.1373970/#post-8715771

 

This one here is locked:
https://forum.unity.com/threads/wha...th-scriptable-render-pipelines.924218/page-15
, so I'm posting here.
I didn't read through all of it, yet my feedback for SRPs:
- I have been using Unity since version 4.
- I have learned how to manually write shaders.
- Sporadically, I tried using Texture Combiners and finally, Surface shaders came along, which both just weren't suitable for me (just too little control over what's happening exactly).
- Happy coding of fragment shaders.
- I gathered quite a number of shaders that work nicely with the BiRP.

Now you come along saying
- URP is here to finally replace BiRP.
- User written shaders from BiRP will not port to URP.
- New syntax for URP shaders.
and
- wait for it -
some speculation about coding shaders being completely deprecated eventually, which even the docs on SRP emphasize, saying "Shader Graph" is considered best practice over manually writing code.

So, what you're saying, going forward:
- Me learning BiRP's fragment shaders won't hold any value.
- All my existing shaders will be broken.
- Possibly even won't be able to write shader code, even if I invested massively to keep going forward with Unity.

Sounds like a huge PITA on the horizon and, from my perspective, with no feature improvement whatsoever.
I guess you should have
- kept BiRP for a basic approach and
- created one SRP, keeping it adjustable and extendable in quality for when you really need such thing.

Don't get me wrong. I do understand why you wouldn't want to keep BiRP if you have URP and HDRP majorly differing from it. Why you introduced such drastically different systems to begin with is what I don't understand. This is a guarantee for frustration to maintain, not just for you, but also for the users in terms of their workflow and assets they gathered over the years.
I don't need a scriptable render pipeline. I don't want two new shader syntaxes. I don't need tremendous amounts of time wasted. I need stuff working. And be dependable. Not a mutating behemoth that could drop BiRP any day, nuking all my stuff.
Will surely need to have another look at Unreal. I did keep assets as little engine dependant as possible, after all. If I need to invest a substantial amount of time, I may as well reconsider the engine of choice.

 

In terms of writing shaders, it's all HLSL, and while some details will be different and you'll need to do some porting, there are ways to keep writing HLSL in all SRPs. Unity is creating Block Shaders, which is new, and there's Better Shaders by Jason Booth.

 

Thanks for the reply! From what I understand, block shaders will essentially be surface shaders 2.0, though, and I don't want to depend on 3rd party. I hope detailed text based programming will still be around and supported and if it really isn't far from BiRP's syntax, I'd be glad to stay (I do like most of Unity), but from what I read, it does seem quite fundamental. I may be wrong. The posts I read may be wrong. I hope so. But well, I'll keep it in mind as a potential major issue.

 

I don't think they'll completely get rid of text based shaders. All that shader graph does it convert nodes to a text based shader.
I don't have a lot of text based shader experience, but hear that for a lot of shaders manually BiRP to URP converting isn't too bad

 

Somewhat makes sense, but I fear making shader graph the "intended way" for creating shaders also means they won't care about changing syntax all day long, because "just use shader graph, it generates the current code", while actually writing shaders becomes unmaintainable.

 

@Shushustorm Are they going to remove entirely BIRP? because you can keep 2021 LTS and learn step by step the SRP, don't you?

 

Will all the custom shaders for BIRB also be magically converted to URP? Because big part of the pain of switching needing to rework those for what gains? the little performance gains will be offset by the newer hardware that will standard in the next few years.

Same for compiling shader variants, editor workflow iteration is slower than BIRB not faster.
And then when you want a nice feature that will be common place in the next few years: Raytracing, URP cannot do it.

Thanks for making it better, but I still feel the overall direction is not user friendly having to choose a pipeline, better just some checkboxes for features on a single pipeline.

 

With stuff like coexistence I don't think it will matter if URP supports raytracing.

As for the shaders, in time people move on.

Except for NGSS...

 

Yes.
"We view the Universal render pipeline as the successor to the default rendering pipeline in Unity (aka the ‘built-in pipeline’).
[...]
As we mentioned earlier, Universal render pipeline is designed to be the default rendering path for Unity, a replacement for the built-in render pipeline
"
(highlighted by me, from here: https://forum.unity.com/threads/wha...nity-with-scriptable-render-pipelines.924218/ , also including many mentions that suggest Unity wants the user to want to switch from BiRP to URP)

Thank you for caring enough to suggest this, but the issue isn't having to deal with a huge amount of work at once, but having to deal with a huge amount of work at all. It's difficult to justify the usage of software that treats user investment like this. Of course, at some point new things get developed and old things eventually fade, but changing things on such a low level is quite an issue. I'm still unsure whether or not it'll be such an impact on rewriting like suggested by others. If not, I'll just port to URP. If it is, I'll take a deeper look at Unreal and see which is more feasible.

While my initial post may have been somewhat unclear (I did mean writing shaders on a lower level), I do know about block shaders, but those are just on too abstract of a level, since those are essentially surface shaders 2.0. And having ShaderGraph be the go to solution for shaders doesn't put a lot of trust in things not changing a lot under the hood so that one could maintain low level shaders as a user of Unity.

Well, LTS means 2 years support, right?
"An LTS release receives continued support for two years following publication"
(from here: https://unity.com/releases/lts-vs-tech-stream )
That's 2025, 2 years from now, maybe about 3 years if you release 2023 late. Wouldn't say that's "many years" and it doesn't really matter if BiRP gets removed 2023 or 2025 or 2027. It gets removed eventually, as soon as URP is "good enough" to replace it. Which, as stated, I totally understand. But it will lead to possibly a lot of rewriting work eventually. In fact, the sooner it's replaced, the better: Because if I decide to keep going with Unity, and keep writing BiRP shaders, because I think those will be easy to port, I'll end up with more work to port. Yet, I cannot switch already to test if it makes sense to rewrite, because URP still isn't finished. There are features missing and still a lot of complaints about quality and performance that make switching right now a complete gamble, which could be yet another time sink.
I don't doubt you'll end up with a nice URP eventually. But what's the cost?
Some limited performance gains or doubtful increase of graphics quality (both still don't seem to be on par with BiRP even after years of development) aren't always the limiting factor for a game either. For me, it clearly is time. And for many others, it is money, which again, they need to buy their employees time.

 

what? do you know or understand why URP exists? why would you want raytracing on URP?

1 - Unity needs more emphasis on explaining what is HDRP and what is URP and its uses (again) because is pretty common to see users with no idea about what is exactly URP

2 - I understand birp was very good at its time, but i think unity (also) needs more emphasis on giving users information about SRP and motivation to start moving out of birp (a system which in my opinion is archaic) i'm always surprised to see people still using birp lol...

 

Yeah I agree part of it is a communication issue, like their marketing team is NOT Good.

I think maybe after this coexistence thing is finished the messaging will be easier. Cause atm people have to choose between URP or HDRP period, and not just per platform. I think to most people HDRP feels like an experimental branch rather than a replacement for BIRP. Instead URP is the BIRP replacement, but that's cause it works similarly, and the platform range is similar. But I think in reality that's not what it should have been and that's not how it's made to be.

For me i picked URP simply cause i couldn't abandon mobile or WebGL (And maybe a potential Switch release) even though the end goal of my games visuals are fairly high end. I would rather use HDRP primarily, and use URP for everything else but that's not viable right now.

But it seems it will be viable later this year, and i hope they live up to those goals.

 

I agree with @Lars-Steenhoff

And I'd counter your question with the opposite. Why wouldnt you want raytracing on URP?
We're not talking about today. We're talking about next few years where hardware will be much more powerful.

I'm sure we're all looking forward to the day that we can ditch lightmaps, baking, reflection probes and all that jazz, even for mobile and web development.

 

OMG you are right, some people are totally clueless about what is URP and HDRP, i think you hit that nail, maybe most of the new devs think HDRP is something experimental and URP is the "estable" version of unity or something like that, maybe because of that there are just a few projects with realistic AAA graphics and some devs wants raytracing on URP lol

 

The reason why I would want a raytracing checkbox in URP is that I could make my game work for Nintendo switch and Playstation 5 in one render pipeline, and not have to port all custom shaders to HDRP just to get raytracing for Ps5. Like a unified system, thats what I expect out of Unity.

 

i'm interested on those demos, looks very cool, but you need to educate your users about URP and its uses, make a bigger and more obvious differentiation because i think the lack of that information is playing against your vision with SRP

raytracing on nintendo swich? is that even posible?

 

No

If
Ps5, checkbox raytracing on,
If
Switch checkbox raytracing off

 

aah yes i understand, sorry, at 3am my brain is on low battery mode xD well HDRP is what you want to use, remember that you can use a lightweight version of hdrp

 

Wait for coexistence then, I think making this simpler is their goal.

There's A LOT missing from URP to make raytracing work well (Shaped lights, exposure compensation, a lot more), but also right now switching between URP and HDRP isn't reasonable.

From what i've seen from GDC, and what they said during the feedback day. They're unifying URP and HDRP internals, and making it easier to have both in the same project. The even said the URP and HDRP teams are finally the same last year. I'm not sure but this seems to be coming to Unity 2023, I hope that's at least the start of it.

While that may mean you need to modify some shaders, it may also mean the update will be less drastic and easier to maintain.

But yeah based on my experiments with HDRP raytracing I just don't see it reasonable for URP to get it any time soon, but at the very least coexistence will making having an HDRP version of the game easier to maintain.

 

I hope you guys reach a point where you can talk more about coexistence soon, while performance is important I think for a lot of people the issue is platform restrictions and solving that would go a LOOONG way to moving people from BIRP.

URP is an easy choice for a mobile dev, but a mobile dev also targeting PS5? Imo URP looks better than BIRP, but plenty of people don't see it that way. I've seen people go as far as implement raytracing in BIRP rather than go to HDRP. It's a bit crazy imo XD.

 

Hi,

Is there any news on the Standard Pipeline deprecation ? This decision can destroy directly millions of projects and render store asset unusable, so even if at some point URP has all features, porting to that is not trivial and projects are still made in standard.

Also URP is massively slower in image effects, so i think for sure Standard Pipeline would be a good alternative to have if performance is needed and use image effects. Maybe URP is faster without image effects, but many games use them so would get a massive performance boost in Standard Pipeline, as URP image effects are so much slower.

 

Hi, thanks for the feedback.

The issue is that even if supported for multiple years, if Unity 2024 is released next year without it, most users will migarate to it and thus have all projects broken. This will happen long before the 2023 end of support, so the question is will this happen or Standard will remain as a legacy library to call (e.g. toggle between UPR and BiRP as is possible now) in Unity 2024 ?

Thanks again

Please note that to port a whole complex system to URP, even if the feature set is similar is not trivial or sometimes not possible, so removing the BiRP and adding similar features in URP does not solve the porting issue directly.

 

To add to this, there need to be better shader documentation if BiRP will be fully replaced. Right now some URP stuff for text based shaders is very hard to find

 

Indeed, there is many things that make me think removing BiRP in Unity 2024 would be a massive mistake.

Plus render a vast number of Asset store assets broken and unusable.

I cant imagine BiRP getting removed really, this seems a bit like a disaster.

Also i wonder why would it be required to remove the BIRP in any case and not just let it be as an option. There is zero point to creating such a massive problems.

 

I think removing BiRP can help with reducing editor size and bloat, reduce iteration time for unity releases (since new features don't have to be tested in BiRP as well if they might interfere), and probably some other stuff.

Myself I only use URP so don't have an issue with it, but for some assets or projects it can definitely be an issue.
On the other side IF 2023 will be the latest BiRP released, the LTS will have support until 2026 or something, so that's 2-3 years to add urp support.