"In May 2019 the team set out on a mammoth task to explore and switch Rust over to Unity’s HDRP pipeline. HDRP boasted many visual fidelity improvements and new tech, best of all it was said HDRP was more optimized resulting in better performance. Switching and updating all our assets over to HDRP was months of work but we figured it would be worth it in the end. Long story short after months of work, testing and profiling we never saw the performance gains we expected from HDRP, in fact, it was worse. "
Rust is pretty high-end, seems like HDRP didn’t scale as well as we were told. They got even worse performance. Although this was in 2019, i doubt the performance Improved. Anyone has any perf benchmarks for the different HDRP versions?
One of the biggest problems with Rust’s “switch” to HDRP was that they added a lot of improved models, textures and shaders rather than just a straight up port. The initial stats iirc were actually even better on high end rigs just the time to load took longer.
They’re moving all these improved models & textures to the current build in rust (built-in pipeline), and they’ve mentioned that the performance shouldn’t be any worse when it happens. It’ll be around the same, so I’m not sure if that really made a difference. I believe it’s already on the public staging branch (publicly accessible). Although I haven’t checked it out, so I can’t confirm if the perf is the same.
Well, you are wrong. At 2019, it was HDRP 5-6 or something, now with the 2021 releases, both performance and graphics are pretty good and a lot more stable. Especially with HDRP 10+ releases, it is significantly faster from my experience.
I use it in production with 4 different projects to 3 different clients. So have no trouble.
Yeah, well from the gameplay videos out there so far it looks like there will be a slight decrease in performance but we will have to see (the public branch is open on the 7th btw). Garry himself said that he didn’t think the additions they added would affect it too much but did also think they should have worked on just the port itself a bit more to see the actual difference.
I guess it’s also important to note they started working on HDRP while it was still very experimental, and I could be wrong on this but I’m pretty sure the whole point of HDRP isn’t to just make FPS better but allow you to do more unique and graphically intense things.
Don’t know, I shipped one project with HDRP 7~9 and is in the middle of another right now (Using both HDRP11 and 12)
My experience is that “it is not significantly faster”. Period.
The HDRP7 and later has been slower than most expected and the performance improved a bit around 11 but still it is not faster than built in and it is not significantly faster than older iterations of HDRP. It just isn’t.
Now, am I saying that HDRP is garbage? No, absolutely not. It has its merits. One of them being quality.
Here is q screenshot of my current open world project.
The terrain is 64km^2
It has 500000 rocks, about 150000 trees and more than 5 million grass objects.
Draw distance is 800m which is much longer than most open world games.
Grass vegetation draw distance is around 300+ and evidently grass-to-texture transition is hardly noticeable unlike in most open world terrain.
All this, in an 8core RTX2080 rig, I get 60+FPS in editor and 80+FPS in standalone build.
All textures are 4k and it features high polygon objects in general. Characters range in 40~80k triangles and 1m^3 objects average in 10k polygons.
There are towns (around 300k poly and 50~80 4k textures for each town) with character NPCs and there are roughly around 5 towns in this map. I still haven’t gone through detail pass which will tweak/add/remove stuff to enhance visuals but the stress level already is where it would be for the final build.
So, do I think HDRP is good? Yes. Because it is faster? No. Then why? Quality.
Is it faster than built in? Definitely no. Can it do stuff that built in can’t? Definitely yes.
What are they? (Specific for open world environment)
Camera relative rendering (This is huge as it allows you to avoid floating error issues mostly)
Virtual Texturing (This is essential to have points of interest in the world map to avoid GPU getting clogged up)
Material Quality (HDRP Lit wins everytime against Built-in, even custom shaders by a mile)
Then why do people say HDRP scales well?
This is a funny thing, but most Unity games made with builtin have this strange behavior whereby the performance doesn’t improve with better rigs after a certain point. Good examples are RUST, and Tarkov. These games are heavily CPU bound but in a strange way. CPU usage is low, but it wants more CPU power. I have no idea why Unity Engine works like this. On the other hand, upgrading GPU doesn’t improve the performance in a linear fashion as one expects, it improves a little but not as much as you’d expect. And for CPU, it doesn’t improve like GPUs after each generation, so it is moot to discuss this point. The end result with more powerful GPU is higher average FPS, but similar lowest FPS with a weaker GPU. Anyway, this worsens as your projects gets bigger and more performance demanding.
HDRP on the other hand, is relatively GPU bound, it is still CPU bound but in my personal opinion, it almost has this fixed amount of CPU needs and a 5 year old 4core can work just as well as a brand new 16core. GPU usage often hits above 99% so I am happy there. But how does it scale? Well, if you throw in a stronger GPU, performance increases in a linear fashion (not exact but better than Built in).
So what does that mean?
In an open world environment like my project the following conjecture can be made based on my past experiment/experience
Provided that all rigs have a decent 8 core gaming pc with sufficient RAM and SSD. The values are a mix of my experience with time differences but to interpolate in rough estimate. @ means more poly and textures, so higher stress level.
In the order of (1080p/1440p/1080p@town/1440p@town) Built in (With many stutters randomly)
GTX 1080 - 80FPS/65FPS/60FPS/40FPS
RTX 2080 - 85FPS/69FPS/65FPS/58FPS
RTX 3080 - 89FPS/75FPS/68FPS/64FPS
HDRP is heavy but so are other engines like UE4. However HDRP is heavier then the competition on main thread time for comparable work. It hasn’t had anywhere near the real world exposure and tuning yet, so that is sort of to be expected I think. Also splitting up the pipelines I think inherently puts less emphasis on optimizing HDRP. If you have a single pipeline it forces optimizations that HDRP can reason away as well it’s a high end platform.
At some point the best bang for the buck is stop optimizing HDRP and start moving your own logic off the main thread. Unity uses a rendering thread but the main thread still has to synchronize with it. Gpu bound is a term I hate because it’s not helpful on it’s own. At what point does gpu bound happen? Because Update has to wait? If the main thread isn’t doing much else that might not be a big deal, it’s all relative to what else is going on.
For instance our game runs at 70fps on a 1050. It’s more stylized but we have upwards of 200k instanced draw calls, thousands of colliders, AAA ocean water, several dozen animated characters, and some pretty heavy ai going on. But we have under 3ms main thread time that is non graphics related. So Update is indeed waiting a lot with a 1050, but it’s still all good.
A lot of people tend to think of scaling from their specific view point as well.
For a solo developer or indie, all pipelines engine etc are on the table and you can plan to your specific scale.
for teams and studios, you really have to thinking about scaling on every level all the time, but again all pipelines are availble for the scope and scale of the project.
Why HDRP has better scaling is mostly that of physically based priciples and that has a large affect for teams, or someone who already has a background in it.
This helps develop full pipelines integrating teams across many mediums incredibly efficient, thus scale.
I come from a film, music, lighting and photography background, having to translate all of those skill sets to something like URP or standard and then communicate it to a team that has only used built in and other industry players would be an absolute nightmare of an onboarding process.
What we’ve noticed is generally short and long term engine users or built-in days have struggled the most adopting physically based principles, and that lowers their performance in engine a lot, even if they’re overall more engine proficient.
if i place someone who’s say green towards the engine leverage their photography//vfx/cinematic skills they adopt engine use slowly obviously, as they have no engine background, but their end results and ability to communicate changes and team collaboration is much much much higher.
this of course help create better project enviroments , solve ideas and problems in a way that would be really really hard to otherwise because of so much conversion on, normilized numbers and features , workflows and standard practices.
in the end you could potentially have better tuned communication, team dynamic, performance etcetc.
The engine itself does take a lot of tuning and planning, but it doesn’t have to be as complicated as it’s often made out to be.
in the end, find the best steps to resolve your goals in the quickest, efficient manner, and if possible solve problems together, help each other find solutions.
food for the thought and hope it helps some people
In the same interview:
Most of the new visuals were developed alongside the transition of the game to the High Definition Render Pipeline of Unity (HDRP) that we subsequently dropped after unsatisfactory performance results. We didn’t want to waste the efforts made to make the game look better during that time and ported them to the current version of the game instead.
