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.
https://www.youtube.com/watch?v=CAjuq08gZig
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.
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.
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.
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.”