Nightmare - SRP,URP,HDRP

Is there any chance that one day this will go away?Like one RP?
Atm situation is terrible and like me low budget,
when i buy assets some of them offer URP some HDRP and some SRP ,its total mix and now to be safe u need buy one asset 3 times all cuz of this...When i want build something i know i have some Models ready for it,and then i just face that this not work in URP,something else works only on SRP,some HDRP.
I today buy bundle with Environment SRP, and looks like it works only in URP,HDRP when other assets works in SRP only..
Sorry for my ENG

 

No

 

Because both HDRP and URP are SRPs. By definition if something is working on all SRPs, that means it is working on both HDRP and URP. I think you're mixing up SRP with BiRP (the Built-in Render Pipeline), which IS NOT an SRP by definition.
SRP = Scriptable Render Pipeline, which BiRP is not.
If you want to use one pipeline, stick to either the BiRP or to URP.
Also the compatibility sometimes just means the shaders need to be updated. Sometimes they can be updated by the Wizards in the SRPs.

And I seriously hope, they won't go away.

 

No.

In many cases assets can be converted, but this has to be done manually.

There's also an option of making your own assets in pipeline you're most comfortable with, without buying 3rd party ones.

 

Note that SRP sometimes refers to Standard Rendering Pipeline which is the built-in pipeline. It can get confusing sadly.

@Aress28
As someone with about 200 assets on their account I shall tell you something: Resist the weird urge of feeling like "missing out" if you do not buy what you think you will only need months later!
Why would you ever buy for the different pipelines if you know what pipeline your current project uses?
Especially with assets that actually are worth buying because of good support etc. it is rather unlikely that they will disappear from the store. So keep them in your fave lists until you actually need them and then buy for the right pipeline.

As for a pipeline going away, I'd tend to believe that in 3-5 years the built-in will be officially depreciated. Yet there still will be indie games based on it for years longer for sure.
Afterwards it's URP for Indies + Mobile and HDRP for Studios. That makes sense once URP has been lifted to the same usability as the built-in.

 

I don't know why people consider HDRP not for indies ?

I would only say that URP is for low spec and hdrp for high spec targets.

 

No it doesn't. Everyone calls it built-in for a reason.

 

It is never called that. It is "built in". SRP is "scriptable".

 

Never say "never." It might not be *correct* but I have definitely seen people use "standard pipeline" on these forums.

 

SRP around these forums is a common swear word. Perhaps it was called it once or twice but now it is BiRP, or Built-in Render Pipeline.

(Joking aside, both Unity and the forum refer to the built-in pipeline as built-in or BiRP)

I haven't in the last few years, must be looking in the wrong places. In any case it's 100% incorrect to refer to it as that, according to Unity. Unity call SRP "Scriptable Render Pipeline" and that's the end of it.

Not least because "standard" is really, really the wrong message to send about the Built-In rendering pipeline that will not get new features, and is already falling behind.

Universal is probably a fair bit ahead than old BiRP is. For starters, you get Forward, Forward+, Deferred, working transparent shadow receivers, VFX, AMD FSR, Spacewarp, BRG (Batch Renderer Group - extremely efficient rendering), DOTs support, Hybrid Renderer and so on...

So yeah BiRP's legacy, not standard. Sorry

It's on long term maintenance now. Served us all well but times have moved on. BRG stuff just is the last nail in the coffin since performance is going to be night and day between them in the long term.

I think it probably is likely to have been referred to as standard, even by me in the distant past, but I do not recall doing so since Unity started calling it Built-In Render pipeline, and anyone calling it standard now is just using words that existed before Unity decided on the naming for these things.

Unity's plan for this is "Universal Render Pipeline" (URP) now with HDRP for the high-end stuff.

BiRP - does not use SRP
URP - uses SRP
HDRP - uses SRP

 

Hopefully someone doesn't mention LWRP.

 

I think that's what they were going for back when it was LWRP and HDRP, but I'm pretty sure they've changed their minds on this. Now URP is supposed to be a scalable one-size-fits-all renderer that can do desktop and mobile. It's more like the built-in render (hence the name change from LWRP to URP). HDRP is only for those who need crazy AAA-quality graphics. I think the intent now is that most people will use URP from now on.

URP and HDRP are still relatively new and people have different ideas about whether these renderers are "ready" or not, so the Asset Store is still something like 80%-90% built-in renderer for now. If the description of the asset doesn't specifically say it's for URP or HDRP in the description, then it's almost definitely for built-in.

 

There are also missing features.
https://docs.unity3d.com/Packages/c...l/universalrp-builtin-feature-comparison.html
https://docs.unity3d.com/Packages/c...efinition@13.1/manual/Feature-Comparison.html

For URP the annoying thing is limit on total number of lights. The restriction is on the level of First Hardware T&L cards from early 2000s.
For HDRP the problem is lack of stacking. Plus lower number of VR devices is supported.

Also, shadergraph does not support "clip" instruction, meaning shaders are less hackable.

 

Forward+ fixes this as does deferred. If you were using that many lights in built-in on forward, your framerate would be far less than URP. I honestly don't get your reasoning at all.

It is like saying car A goes faster in first gear than car B. Why would either remain in first gear?

 

2021.2 already has deferred rendering, that supposed to eliminate the light limit (trading for other problems, BiRP also has). And the Forward+ is in progress which hopefully will eliminate most of this tradeoff.

 

The way I see it, the newer version of pipieline should be able to do everything the old one can do, and that means having no limit on number of lights. If there's an inherent limitation, then the limitation should be dealt with by the framework and not by the user.

Seeing a light number limit in 2020 brings back memories of the hardware T&L cards. Back when vertex lighting was the most common way to do it, a hardware T&L card could support 4..8 simultanoues lights total. Software T&L, however supported 256.

 

If we are talking features, then built-in got left behind a long time ago. And T&L wasn't even the actual lighting, merely acceleration structures that no longer exist in modern GPUs for any engine having been replaced.

Both engines and GPUs have had to move forward. That is why Built-in is a poor fit for many forward facing features. I do not see any value in built-in once Forward+ arrives for URP and people start using BRG API.

 

I agree. The problem is that URP isn't a newer version of the BiRP.

 

Of course it will, just not any time soon to matter to me and you.

I would say we have about 2-3 more years of active development on URP and HDRP before they are left to rot while Unity works at some new replacement for another 5 years.

 

Got to wonder why Unity chose to with clear decision making, to make two graphics engines and not share the work between them even though both are based on SRP.

For example with Universal, they made the decision to support hardware that includes compute shaders and did away with the really old legacy support, yet they do not want to bring raytracing to URP.

Instead they do that work in HDRP. So you cannot have a project that scales from low to high and we all know in hindsight, Unity could've done it.

So no, I don't think you made a stupid comment.

 

Was it clear? In the very beginning, I was under the impression that HDRP was supposed to be a highly customizable more modern new built-in with plans for it to support everything except the very low end mobile which would be left to LWRP.

Now URP is supposed to be the new built in, with HDRP only for the very high end / non-gamedev markets.

So I don't think their decision making and planning was clear at all.

 

Everything Unity does is a clear decision, not an accident. An accident means they're incompetent or incapable of planning anything.

Logically that means I do expect Unity to be on the ball and treat each decision they make with respect. And Unity should want that accountability if they want to earn even greater sums of cash.

 

How pretentious expecting that they can't make a mistake...

LWRP was a mistake. They recognized that they got it wrong, they corrected. End of story.

 

Oh, I do expect them to make mistakes. What you are missing here is that if we expect Unity to make a mistake, it will (unlike the past) be one they took their time over and gave the proper respect without rushing. That means things will take longer.

I'm sure you're aware that the fallout from the LWRP sample -> Unity official LWRP SRP -> Unity official LWRP to URP -> Asset store -> customer tears.

<snip>

That's the kind of mistake made if you rush or try to make opportunities. Unity needs to take their time, make important decisions well.

 

Well, I was here, with everyone else, including you and advocated for more professional evaluation: if any of the SRPs in the current states, when the conversation happened, fulfilled the professional needs of one, then use it, otherwise stick to the BiRP and keep an eye on the development of the SRPs (so in the future one can make an educated decision on using them or not). Instead of endlessly crying on the forums that Unity is making something new.

It's not like they took away the BiRP so we didn't have a choice to stick to the familiar and generally useable solution. If anything, they dropped the ball harder on the entire real-time GI situation which they deserve everything they got and getting for.

As always, IMHO, of course.

 

LWRP wasn't a mistake, early URP was
LWRP was crystal clear in its intent that justified its limitation, early URP was serving no one, current URP is a bastardized solution who is fighting the limitation of LWRP that doesn't make sense for the services it supposed to provide.

 

I guess the question is, if the current situation is not a mistake, if they did a mistake in the past (3 years ago) and they corrected, is the current situation good / are we moving towards a good situation? I'm not so sure.

We still have a weird gap of HDRP not scaling down enough to be useful, and URP not getting enough actually new features. A lot of features that would benefit both ( FSR? ) are put in HDRP only.

The original HDRP for everything except low end mobile was a much better concept frankly. Maybe they couldn't do it?

There was a period when I thought HDRP was the future and URP was more to tide us over until hardware catches up / HDRP gets optimized enough. Now I feel like HDRP is sidelined and is aimed at less than real time uses (arch viz? movies?), but it also doesn't feel like they've put their full weight behind URP. I honestly can't see what we are heading towards.

 

Apparently we see these things vastly differently. I see all these things in progress. Like FSR for URP?
IDK what you're basing your statement about HDRP, but I see the opposite. It is more and more usable and more and more easy to use, even I was able to set up HDRP with proper lighting and all after I read their manual and the best practices leaflet they are distributing as an e-book. And I am very bad at graphics and art in general.
Running HDRP, importing assets into it feels proper to me, nothing "not intended for real time" feel at all. Frankly, it is barely complicated than BiRP at this point since they implemented the wizard and most potential problems can be detected and even fixed automatically. My strong middle ground PC (at this point) runs HDRP without a hitch, I guess a top of the shelf CPU and GPU runs even better. Also most of the features lands on HDRP first which make sure HDRP can be run properly on many platforms as possible.
URP on the other hand starts from the average, also making sure, runs on everything and slowly get features which allows to stretch it more upwards to the higher fidelity.

For me, it absolutely makes sense. But again, it's maybe just me.

 

Minus various annoying bugs / glitches, I never thought ease of use was a problem for HDRP, so I think we are looking at completely different things for it.

 

HDRP development is active, you can find many new features and optimization's in GitHub (many have landed already)
Volumetric clouds, full water solution, all built-in.

in contrast URP's development is slow. Extremely slow. URP is shader variant hell in 2020.3 and 2021.
There's no LTS in existence with point light shadows. Basic things you'd expect are still missing.
no SSR, no TAA, no LOD crossfade, no volumetric fog. These have been in HDRP for years.
Many features that have been in built-in for a long time have been recently added to URP with the same limitations.
You'd think they'd improve on it, but it's the same or worse.

I use HDRP, and I've done many tests in my own large project and others and noticed that HDRP performance is fairly close to URP once your scene is big enough that you target 60 FPS.
The exception would be very small projects, empty projects and so on where URP can have very high FPS, HDRP can't as easily partly due to the render graph which has a CPU overhead.

This isn't to say HDRP is performant and that's it, I do believe it still needs a lot of work. BRG is a welcome change but I'm hoping it'll be a bigger part of HDRP/URP by default. And it is true that HDRP struggles with low-end hardware more than URP/built-in.

URP has issues with features it recently got:
For example URP SSAO (even with 2021.2 improvements) is 3-4x the cost of HDRP SSAO, while having much worse quality.

 

HDRP is probably going along better because high end machine is probably less fractured than the low to mid end, where solution has to be weighted against the various hardware format without breaking compatibility.

 

For me, all the shiny new features do not really change that there are things that built in could do, while the SRPs cannot.

And all those "raytraced xyz" is not very useful during never-ending GPU shortage.

In case of HDRP, one thing they really should patch back in is camera stacking. This feature can be very useful.

Regarding URP/LWRP, I had pretty negative experience with it due to low number of lights it supports. There was that night scene with large terrain chunk and passing cars with headlights. Had to pull out fake lights from 2000s to make it work. The way I see it, there should be ready to use tools for this sort of nonsense.

 

They would be useful if you wanted to release on consoles though. Design your game for Switch, then on PS5 / XBox etc add a bit of raytracing (some more dynamic lights and what have you) and you suddenly have something that feels more at home in these more high powered consoles.

Camera stacking is back in, it just isn't intended for game dev, it's intended for arch viz / offline rendering etc.

https://forum.unity.com/threads/hdr...n-top-of-the-background.1148603/#post-7381664

 

Except HDRP does not support Switch since 2019, URP doesn't have ray tracing, and you can't toggle between URP and HDRP on the same project.

 

Yes. My point is that raytracing would be a useful feature to have outside HDRP (so, URP / built-in), despite the GPU shortage, for the reasons I mentioned.

 

The reason I've harped on about bringing DXR simple features - albeit often expensive to URP is because it's just insane quality of life. Even if your game doesn't use it, your promotional materials do. You even get to use some of it. Perhaps you have a cute mobile title with cute little tiles in isometric. But then you want to port to xbox and xbox won't take it. But if it had gorgeous GI bounced reflective little tiles of DXR then yeah they would.

I guess I want my game to run on everything smoothly, and non-optimally scale up to beefy hardware. That's something built-in is the best at.

 

Yeah, but I still think scaling HDRP down to also cover Switch would have been preferable.

Because now we are in a situation when if we want to port (with significant upgrades) a mobile game to consoles, either we have to do the port twice (to HDRP and URP), or just use URP which is really unexciting to me features wise.

 

Speaking of which HDRP doesn't support Quest either.

https://docs.unity3d.com/Packages/c...efinition@13.1/manual/Feature-Comparison.html

 

I believe it did do so at one point for a short period. It wasn't pretty but a simpler game running at 20-odd FPS would be more than doable. The problem is that's still not fast enough for something like Quest, or compatible with a whole bunch of mobile phones.

In the long term, Unity will face having 3 active renderers that cover all hardware, two of which will be redundant and costing them resources, decision flexibility and money (BiRP, URP) because by that point, most devices will support HDRP. Even if we get to that point, Unity will find that because of the availability of all 3 pipelines they'll have too many projects by customers to deprecate any of them.

I hope Unity has a plan for that.

 

Historically, that plan seems to be "suddenly announce the deprecation of at least one of [THING IN QUESTION] and that a half-baked replacement is in the works that you can only get from github also it doesn't work by the time you're done reading the announcement anyway."

 

That's not a plan, it's a habit.

 

At this point I have to assume they have it written down on a whiteboard somewhere.

 

In terms of features, I agree, URP could have some brighter features, after all, only its big brother is gaining interesting features (HDRP). Still, I don't think HDRP is just for ArchiVix, it's useful for any game. but not for all platforms, and that's where the URP comes in. (A lot of people forget, but the idea behind the URP is to be compatible with ANY PLATFORM, not any graphic)

And thinking from a graphical point of view, I think of the URP as something scalable from basic to intermediate-advanced. As for HDRP, it's only good for modern consoles and PCs. (Of course, you could have better graphics in URP or some of the brilliant features of HDRP, but that takes away from the idea that it's scalable to all hardware, you can release a mobile game that runs on PS5 and WEBGL, and it just works, but still, it would be nice to have some brilliant features in it)

Also, I'm waiting for the DOTS renderer to integrate with the SRP, the performance gain of the SRPs with it should be much more interesting, and remove the CPU performance problem already mentioned here before.

 

We have 3 pipelines and each of them has at least one breaking issue.

Built-in is in maintenance mode.
URP is meh features wise.
HDRP doesn't support enough platforms.

Unity is the only engine AFAIK with this issue. Other engine that will not be named is able to scale from mobile to PS5 high end, while also having more feature-pizzaz than HDRP

 

Thing is that's already been changed. It started to change when LWRP was changed to URP. URP will soon have Forward+ and that means compute shaders to figure out tiled lighting, and at this point we cut out half the mobiles in the world and ES2.0 devices. That's a change that has to be accepted. It's also a purely optional one the user can configure.

But wait, there is more. HDRP also broke the rules like this by splitting what HDRP could support with similar rationale and intention: HDRP originally did not support DXR and Raytracing, something that the majority of HDRP devices still don't have hardware support for.

So URP and HDRP both have quite high device fragmentation. That's something you can't avoid and should engineer for and accept from day one. Unity tried to avoid it and failed to do so. Because if they kept avoiding it, they'd bleed customers to other engines.

So both pipelines are already polluted with hardware feature fragmentation. This should not be feared but welcomed or we have an URP that's too slow and a HDRP that's too slow. Keeping things all one hardware capability feature set is the death of any modern engine.

There is absolutely no reason why URP can't have high end features that remain optional, after all that's exactly what happened with HDRP, and purely optional to enable.

I understand Unity's engineers shaking their heads at this post, but it's purely a post about customer rationale, not the challenges of keeping that software healthy, or even the shader permutation hell that they'd burn in.

 

When I first read about the "scriptable rendering pipeline" concept, I expected something highly modular. Like a menu for every target build with a bunch of checkboxes describing features like transparent surfaces, unlimited lights, DXR etc. For mobile you'd obviously disable many of those entirely and for desktops you'd toggle the features through a graphics-settings menu at runtime.

Then in your code and when designing materials, you'd have to provide fallbacks for when certain features are unticked and the pipeline automatically uses the fallbacks when needed, otherwise providing maximum features.

That would be the dream of usability in terms of scalability and not require to decide for a specific pipeline...
Too bad that appears not to be possible.

It's in this threat that made me look up that the Unreal Engine actually supports mobile? Always thought they were higher-end machines only. How did they manage the scalability without multiple pipelines?

 

Extremely poorly.

 

Guess there is no silverbullet for this kind of problem then..

 

Garena free fire has some word for you

It's in a south park episode:
- announce random feature
- ???
- PROFIT!!

 

But source license. At this point nothing matters, and all conversations become moot. What matters to us as indies is how much work will Unity do for us?