HDRP vs URP what is the tradeoff?

capability vs performance?
accuracy and precision vs less?

greets

 

I personally so far use HDRP.

HDRP supports less platforms. No mobile, no switch, and it's gonna be pretty tough to get it to run on old gen consoles (PS4/xbox).

If you intend to target players with fairly weak hardware, HDRP is not a good idea.
HDRP has a lot more graphical features than URP. (Volumetric fog, Screen space global illumination, SSR, fancier shadows, tesselation, Temporal antialiasing, etc)
From my experience, the GPU lightmapper does a worse job when using HDRP, where If i switch to built-in or URP, it's mostly fine. (using auto-UVs)

HDRP uses realistic lighting, exposure can be a pain sometimes. some people don't bother with realistic values and do things the old way, until it feels right.

If your project is 2D, you'd be better served with URP.
My main issue with URP is the unbelievably slow development. Hopefully TAA lands in 2022, along with improved SSAO since currently it not only costs 2-3x compared to HDRP, its quality is pretty bad. I won't even talk about volumetric fog

The trade off basically is HDRP has more graphical features built-in, comes with the engine and isn't held back by weak platforms such as mobile. Performance requirements are a bit higher. Development is a lot faster compared to URP.

URP, less so, more of a blank slate but it's also more customizable (especially when it comes to lighting from what I hear, where in HDRP it'd be quite a bit tougher) URP would probably be a good choice if your a shader wizard and plan to make many fancy graphical features by yourself. URP also supports switch, mobile. And has less CPU overhead compared to HDRP, this becomes less important once your project passes a certain size/performance threshold.

In the end, the only truly proven render pipeline so far is the old built-in RP.
May it rest in peace.

 

The two SRPs are divided by your target platforms. If you think of graphical features being whatever the targets support then you are on the right track.

The absolute wrong way to decide on an SRP is to think about what features you want, because if the hardware can't do it then it's tough luck. With HDRP you need compute shader hardware that also needs to be good at compute shaders, bandwidth etc. Memory consumption is dramatically different with both pipelines too, which bites people late in development.

URP can and will still make use of compute but you can fall back gracefully and support any platform without it, so porting is actually not a problem unlike HDRP where it may not be possible to port without a massive undertaking indies probably can't manage.

URP recommended
PS4, PS5, xbox, nintendo, PC, laptops, mobiles, etc - basically everything.

HDRP recommended
Simulations, Arch VIS, movie making, high end PC and console only.

 

Fixed for you. On PS4 and Xbox One HDRP uses over 8-10 milliseconds of main thread CPU time on an empty scene. It's a performance nightmare.

 

I wonder how they optimized BOTD and fountainbleau to run on PS4 and Xbox one

 

Because they are just small scenes with zero game logic and physics going on, so they can just burn the remaining ~20ms of main thread rendering stuff at 30fps.

A renderer shouldn't use that much CPU, this is bad design at a fundamental level.

 

Sad thing is right back in the early days (before RT) it ran pretty well for a time. I think it'll stay a problem until 2022 DOTS 1.0 Hybrid Renderer.

 

yea,one nightmare for me is Unreal people are running dense vegetations on a gtx1060 in 1080p 60fps while i can't even get a similar HDRP scene without grasses to reach a stable 60fps on same graphic card.

 

Lets tag @pierred_unity and @chap-unity for awareness...

 

unity needs a GPU driven terrain and indirect instanced tree rendering soon.... The performance of the new terrain demo sucked a lot didn't ran well on high end aswell

while the uniengine one runs buttery smooth!!

 

The terrain demo is not optimized almost at all. The amount of triangles is insane. For a public demo it's weird they thought it was okay to release it in this state.

There's also some TAA ghosting/blurriness on all the foliage which happens because motion vectors are lost when using instancing, which the terrain does for trees/detail objects.

Honestly you can get pretty dense forests with billboards/imposters for trees, and indirect instanced grass. For the terrain just use a good pixel error value, and keep an eye on triangles.

 

Chugs more than Thomas the Tank Engine.

 

Wow I forgot how pathetic Unity had become! 3 F***ing incompatible renderers!
Anyway, thanks for the low-down, guys, I'll forget HDRP even exists.

 

7 incompatible renderers and counting

 

Steady on, that's a bit extreme, no? URP is fine, Built-in is fine, just HDRP needs some room to do it's work and it can't if it's held back by other issues.

Obviously not for asset authors.

 

I don't think Hybrid Renderer is the solution, because Unity is still stubbornly clinging to CPU-driven rendering. While (AFAIK) Hybrid Renderer does use indirect instanced rendering, the indirect data is produced by the CPU. Even if it uses jobs to do so, even a modest GPU can churn through at least one order of magnitude more data than a 4~8 core CPU. We are one year into the 2nd console generation since the industry started moving towards GPU-driven rendering.

And Hybrid Rendering is a system built on top of SRP. It won't help about the massive overhead you get from an empty scene because both URP and HDRP have a fundamental flaw: the bulk of their C# work can only be executed in the main thread. It's worse in HDRP because to URP does much less stuff right now, in comparison, but merely preparing CommandBuffers every frame adds up pretty quickly when you're not on high-end CPUs and since the process involves managed Unity objects (ComputeBuffers, RenderTexture, etc) none of it can be offload to a separate rendering thread.

Being able to do rendering on another thread is one of the things that should have been addressed at the beginning of the development of the SRP architecture. The new render batch API is a first step towards that, but I can't help to feel having to "register" meshes and materials to get an IntPtr that can be used on jobs doesn't feel very elegant.

 

URP isn't fine. It's been more than 4 years and it's still lacking compared to built-in, with a ton of shader variant issues.
If the only benchmark for a RP is that it runs, then something's wrong already.

Then there's URP's SSAO costing 3-4x that of HDRP while providing lower quality.

 

They are all fine. As an asset store developer, I work with all of them on a daily basis, with all 7 . And I would say it is a problem for game developers too if they rely on the asset store. If not, you will be fine.

For instance, I start a project in URP 2020.3 LTS because that's what unity advises you to use, and use some water shader from the store, then decide to move to 2021.3 LTS in a few months because I want to use the new terrain detail system. If for some reason, the water developer doesn't update it, I'm stuck to 2020.3 or I need to find another water system or I need to fix it myself, costing development time.

So one will need to think not only about the render pipeline they choose but also the version they choose, the resources available (built-in features, assets, tutorials) for that pipeline/version.

 

In my experience and perspective:
HDRP is Unreal Engine
URP is the Unity Default
Standard is Frostbite game engine

I am speaking about lighting and graphics

So:
Default unity users can use URP
Standard fanboys can still on the built-in pipeline
UE4 fanboys can use HDRP and don't thing about its performance

 

I can't help but think there's a lot of detail that would change your mind but everyone is entitled to their own opinion.

Said like a soldier in pain putting a brave face on. Fear not, I do very much know the pain asset authors go through. Some of them even monetise that very pain point because if they didn't, Unity wouldn't address it!

 

HDRP was in this state not too long ago, but it's much better now as the pipeline has matured. Not so many breaking changes anymore. I was able to update from 20.3 to 21.2 (for the clouds) without any shaders breaking.
Started this project on Unity 2018. I think I'm done updating now haha

 

Hello, apart from "shipped with" HDRP shaders and premade configuration options, is there anything one can achieve or has with HDRP and URP one can't by custom shaders in Standard built-in?

 

Not sure, but all the graphical features like volumetric fog/lighting, clouds, etc are possible with custom shaders.
The way you extend both RP's is different though, I believe URP has some limitations or lacks some rendering info that you'd need for some shaders where HDRP has it, but I don't know much about that particular case so for extending render pipelines you'll be better off hearing about it from someone else.

 

https://twitter.com/iamspikebor/status/1535911316942376961 seems like unity has improved the main thread performance... Did anyone got any performance boost in the new versions??

 

If you have expert render engineers you can probably almost achieve the same
HDRP has very good scaling for high demanding scenes. You can use deferred and forward at the same time

Overall HDRP has about all the graphical things you need on high quality and is quite stable (although 2021 LTS now broke TAA and Decals, 2020 LTS is stable and feels quite complete) but HDRP has quite the CPU Cost and no switch support.

In terms of GPU, HDRP looks way better than built in + assets or URP, and these don't have DLSS so its likely even less costly on GPU than those (once it works I guess)

You can buy in a lot with assets but assets are generally ticking time bombs and the more you have the more unstable your project. URP seems like the worst of both worlds. With HDRP you can at least compete with Unreal, with URP why would I pick this engine over unreal or Godot if im not making mobile.

 

Because you are professional in Unity but in Godot or UE, you are zero and you dont want to start over.

 

People that moved to Unreal say they need about a month to be able to get up to speed and feel as productive.

 

Learning C++ on the senior level and UI workflow taking 1 month ? Yeah sure.

 

I don't know why you think you need to learn C++ to a senior level to make a game in Unreal.

Also, the things you should be becoming professional is game design and art and learning how to learn things, and those transfer regardless of software. The rest you can pick up.

It's not as if continuing to use Unity doesn't invalidate old know-how. I know how to bake good lightmaps in Enlighten, I can shove that knowledge up my arse now.

And if I want to do high performance big worlds in Unity in the future, I need to deep dive in the whole DOTS ecosystem.

Knowing where the buttons are and how the menus are organised is not that big a deal.

 

Provided that you are thinking of using HDRP for realistic graphical style,

In my experience, the ultimate difference between HDRP and URP is graphical fidelity.
HDRP -> DLSS
URP -> TAA, things just breakdown when camera is moving

The second major difference is how reflection looks really dated in URP.
HDRP -> Bent Normal Specular Occ + Physically based sky + RTReflections
URP -> None (but maybe it can be implemented?) just PBR sky + reflection probes

Lastly, enabling raytracing just keeps the two SRPs a good generation apart
HDRP -> RTGI, Reflection, Shadows(Huge difference)
URP -> Best you can do is apply some Screen Space AO

Few things that made me not give up on HDRP

• HDRP does have a higher overhead, especially CPU, but same scene in URP performed about the same. Maybe like 10% higher FPS in some angles. But it had more stutters. Didn't spend too much time on it so fingers crossed. I feel like URP is just faster on an empty/small scene. Add a realistic amount of environment and I think HDRP outperforms URP (Provided they are doing the same graphical work) as long as you offload as many things to the GPU. It might be more accurate to say that URP doesn't perform in bigger scenes but I digress.
• Having a building interior with proper realtime lighting (Time of the day) in the middle of an open terrain is impossible in Unity unless you go HDRP + raytracing.
• HDRP requires less third party assets to do basic stuff (volumetric fog, water, SSS) hence no need to spend time making multiple assets work together. Unity HDRP keeps everything working.
• Provided that Raytracing is to be supported, (if not, then just go URP) HDRP performs surprisingly well.
• DLSS3 will probably come to HDRP only which will largely workaround the CPU overhead anyway
• No lightmap baking with SSGI (really meh but still) or RTGI + RT shadows
• Decent Subsurface shading
• Crappy stuff on HDRP is also crappy on URP - like terrain, terrain details

Here is a screenshot of my wip open world game (projected shipping date of late 2024 earliest) running at 1440p. RTGI, RTR, RT Shadows. DLSS quality. Its on a 4x4km terrain. It is in early level layout stage so only big objects placed. Not optimized at all - just basic LOD at 50% scaling per screenspace size. All high quality assets, 2k~4k textures (Diffuse, Mask, Normal, Thickness, Bent Normal and Detail).




The best part of HDRP (Raytraced) is that things look natural just out of the box. No need to add in excessive post processing, no need to shove SSAO hard to make it look less "empty" or overpower normal strength. No need to make things too shiny to retain "reflectiveness". As long as the material's physical properties are within reasonable range, the end result simply requires good composition. The ride is just smooth enough.

But it doesn't mean that it doesn't have issues - it has major problems like terrain- but it is the same with URP anyway, so yup. Take it with a grain of salt.

Bonus (Time of the Day) by just changing sun angle - nothing else. No baking, no nothing other than change angle in the editor inspector

 

If you want to make supermario in unreal then yeah, you dont need senior level of coding. If you want to make an RTS or space-sim, you better be senior level.

 

Coolio.

 

Nice. Do you have any fallbacks for people without RT cards? Lumen, RTGI etc. are cool, but one thing that sorta scares me is how big an impact they have in terms of gameplay, paired with how few who will/can use it.
Its a non-issue when talking about things like reflections, but in the case of GI, a room might become pitch black without - or vise versa.

 

Yes, it can use the default unity SSGI, but

the game won't run very well on older cards anyway, so chances are we will not support non RTX cards. For example, 1080Ti won't be enough, no matter how hard I try - unless I make a potato version of the game. VRAM alone just won't cut it. Also, AMD cards will run like crap anyway with RT anyway as well.

Also, imho, lumen is meant to work with hardware Raytracing, in software mode, it is as crap and slow as Unity SSGI. Just look at the latest UE5 games and their performance. Realistically, realtime GI really needs RT hardware. So, really, in that sense, I don't really see a performance/quality difference between UE and Unity. There is Nanite but I think it is a bit hard for indies to reach. The tech is nice and easy, but the assets required is just too far away at the moment. Especially for foliage.

The project - at least for its target window - assumes that the user has a decent RT-able card. It would be in the region of RTX3080, RTX4070 now for the minimum (for 1080p, 60FPS+ experience), but that is in 2 years and probably 3. So, I am not too worried about the hardware requirements.

I am developing this project with a RTX4090, and my internal goal is to achieve 120FPS (dlss quality) @ 1440p with this rig - under maximum settings. My gut tells me that I won't be able to keep this goal, and probably will have to adjust but at the moment that is the target performance goal.

 

Why so high ?
Do you plan to make it for VR later ?

btw. Awesome results you have.

 

I'm adding my grain of sand to the discussion, as I've done the opposite jump: from UE5 to Unity. Maybe it can be useful to some, as UE is not all that shining gold some speak about.
Some time ago I decided I wanted to create my own open world game. I've been a software developer for over 20 years (mostly C#, but also C on Unix a long LONG time ago). But had 0 experience with games whatsoever (actually I had developed a small game in 1997 with turbo C, but it was another thing). After looking at both UE and Unity and I've understood that Unity would be more familiar because of C#, but Unreal (UE5 was just launched back then) had a lot of tools for open worlds that would make my life easier, so I decided to study UE. Of course UE5, because, and this was not that clear to me back then, now Epic is deprecating UE4 and less and less marketplace assets support it. So I bought a number of courses (actually a Humble Bundle, very convenient) and started off my journey. Which at the beginning was awesome. All that good stuff out of the box, Lumen, and Nanite and World partition. Wow. Awesome... on paper. The reality is that when you start digging a bit, you realize 2 main things:
1) Unreal optimization is a nightmare
2) Unreal engine 5 is a freaking bug with an engine around it.
Terrain LODs are not working. As simple as that. And world partition relies on LODs to stream the terrain. So the whole basis of the open world is not working. I was never able to build LODs from the engine. Tesselation is deprecated in UE5 in favor of Virtual heightfield Mesh, which, again, is buggy and not working as expected. Moreover, after spending some good bucks in awesome assets, Epic updated the engine, and you need to wait for the assets to update to the latest version, or you can't install them. Same goes for DLSS, which was updated to UE5.1 right after UE5.2 came around.
You can work around some of the bugs only if you dig in the engine source code, which means you either are a AAA studio or you are f***d. Nanite foliage is awesome, until you add some wind, in which case, Lumen needs to rebuild the whole shadow cache and FPS plummets of a good 30%. The engine native tools to build big terrains is ridiculous, and you must rely on external tools. Procedural tools are adding up, but they take time and effort to be used properly. I thought my biggest problems would be on the C++ side, but I was wrong. That is actually pretty easy (if you know your way in C or C++ and once you get familiar with the libraries). I was really frustrated regarding the barebones of the engine.

So after spending some good money to buy the assets for my game, I am coming back to Unity. Giving it a chance. And I find that overall, even if productivity in UE5 is definitely higher (you can do more in less time), Unity is more stable. It doesn't mean there is no bugs or limits. But you are able to overcome them thanks to some things you can only build yourself in UE5: optimization tools. Surprisingly, from the marketplace, I was able to find awesome tools to overcome some of the engine limitations like terrains, floating point on big maps, lack of optimization etc. After giving a try to their free versions, I decided to invest in some awesome tools (some of them 50% off atm) and optimizers, which help to overcome the base engine limitations. I am now able to build more or less the same 8k map I built in UE with even slightly better performance (1040p) but so much faster! I still find UE5 a notch above Unity (especially nanite is truly awesome, and also Lumen with no wind in the scene), but Unity allows a solo developer to do what you can do only with a bigger team or a lot of expertise in UE. Oh, and not to mention I have tesselation back

So yes, this Unity has some limitations and bugs, but there's ways around it without you to be a NASA engineer. At least this is my experience on both sides of the force

 

fair on you. Any product that has to be as flexible as a game engine is will have pros and cons for a game, and/or person/team. I tried unreal, there were some things I did kinda like about it.. But to me they kinda are a pair, its like ones metric ones imperial, neither necessarily better or worse than the other, but if you look at small sections perhaps UE does that better, or unity this.. Sadly no ones taken both, mushed them together and taken out the best of both.