Who is using HDRP in production?

I had found that using a single terrain is much faster than using multiple terrains... So i use fewer,but very large terrains of 100km² or 25km² and pixel error set to maximum and with that performance isn't that bad without any major differences in the scene quality.... Yes I agree the terrain system is not at all artist friendly and does not provide AAA class performance and you need to build a lot of systems and tools yourself for that or buy asset store tools which are generally expensive!!! I had asked about the exactly same issues like yours for literally many times on the terrain tools forum but the devs just don't want to talk about it and simply ignore it... And most annoying thing is how slowly the terrain tools are being developed which makes me think that there are only 1-2 people developing it... There is literally no transparency in the development of this tool

 

And also i am not a big fan of the terrain sample.. it's just not that great!! The textures are ridiculously of low resolution, trees don't look that great and definitely the performance aswell

 

I really wish we had gone with UE4 before starting our large project, we did a limited port of one of our large city maps to evaluate UE5 and get 120FPS, butter smooth, not even using nanite, the equivalent in Unity HDRP gets around 50 with frequent drops to 20.

Have done some limited testing with DX12/Raytracing but it's incredibly unstable.

 

V rising: just released (minutes ago) +20,000 players made in HDRP
I had a feeling it was using HDRP from the trailer, built-in/URP has quite the different look when it comes to lighting. Checked game files and it is indeed HDRP.
Now on to play the game..

 

The same here, I've started porting codes to UE5, so C# -> C++ and everything aside, performance and rendering has been rock solid.

My gut feeling tells me that HDRP can't even match performance/rendering to UE4 and I am pretty concerned that this trend will continue. We will see.

 

Both SRPs have a major bottleneck: the bulk of their C# layer can only run on Unity's main thread, competing directly with your game logic. Since HDRP does a lot more than URP, its impact on the main CPU thread is also larger. In Unreal pretty much everything related to setting up rendering commands goes on a dedicated render thread: it's a lot more verbose to use, but won't bottleneck your game logic thread. Not to mention the accumulated optimizations resulting from having to make Fortnite scale all the way from mobile to RTX.

There's a very early beginning at Unity in making APIs that can be used outside the main thread, aimed at future versions of the hybrid renderer, but IMO it needs a lot more. For example, being able to build command buffers in other threads.

 

Didn't they optimizing the cpu usage now by moving HDRP stuff to job system?

 

There's a new experimental API which allows you to "register" some managed objects like Mesh and Material instances and get raw pointers to them, which are then used to build draw lists in jobs. They also now write some GraphicsBuffer/ComputeBuffer data in jobs. But a lot of this is only used via the hybrid renderer, and there's still too much that can be done only the main thread.

The new API is also very "low-level-ish" and really not for the faint of heart, but this is the cost of making it performant. For example, writing custom rendering code or modifying the existing one in Unreal is quite complex due to the fact the system is written favoring performance over convenience.

 

Oh you mean the BRG?

 

Yeah BatchRendererGroup, the name escaped me, thanks!

 

I hope that one goes well to be honest, since the creator of brg are leaving unity already. If i'm not mistaken their last plan was to add BRG support for HDRP (first) then URP for non hybrid renderer, not sure how did it goes now. . .

 

I think only Sebastian Aaltonen left... Others are still there for BRG... Are u saying this about GPU pipeline??

 

Yes the GPU Driven Pipeline, i haven't check it for a while so idk what's the current status of it

 

Sebastian Aaltonen has been posting a lot of his work on Twitter since joining the new company.
The section on performance optimization is very groundbreaking.
I didn't even know he had such a high level of execution.
Be nice, the Unity HDRP team should consider bringing him back.

 

I tried out 100km² terrain (just terrain with materials in HDRP with 4k height map... Shadow distance 5000m) and it ran at 100fps on 1650, ryzen 5 laptop and i doubt that mesh could have done anything better, instead i think it would do worse than this... And batch count was around 100 (including HDRP ones)

 

Did you try the HDRP terrain demo?

 

This was a separate test i did in empty HDRP project... I have tried the demo scene

 

400km^2 terrain on 1650ti, Ryzen 5 laptop

is terrain performance really that bad??? Feels like quite suitable for openworlds... just replace the shader with microsplat and use a performant placement tool (not the unity one's as they suck down performance)

 

90FPS for a bare terrain, try generating a large terrain in Gaia Pro with a biome and check your FPS, that's before you even want to add characters/animators/AI etc.

 

I can't even get more than 45fps in the terrain demo. i mean, i know 1070 are fairly old gpu, but really??!!

 

The terrain demo is very badly optimised, the grass is unnecessarily very dense which makes the triangle count go very high, around 60 million and sometimes around 200 million!! Second thing is that the grass assets are a bit high poly and the demo uses various single grass mesh instances instead of a joint cluster.... The terrain in the demo is split into too many small chunks which is bad (for unity terrain) in above test of 400km^2 i used only 4 terrains....I don't recommend anyone to use unity's tools for placement because they don't have any optimisations ( paint details is quite great performance because of being indirectly instanced but they don't align to slope which is a pain especially for grass), instead use asset store alternatives like vegetation studio or GPU instancing or develop a custom streaming for your vegetation and other assets.... Does Gaia do anything in terms of performance??

 

I was stress testing the terrain performance only

 

Terrain details can be made to align with the slope. There is a slider in the setup for it.

 

Can u plz tell me where exactly its located?? If possible can u send me a screenshot??

 

Terrain>Details Tab>Edit Details>Edit>Align To Ground %

 

Can you tell in which are these made in: Built-in, URP, HDRP or UE4 ?

 

The answer is

Spoiler: Built-in

, using just one 3rd party system for volumetric lighting.

Performance 34-40 fps on ultra settings with shadows on high, anisotropy per texture 1080p on a 5 yo 1050 Ti and i7 CPU.
Can get to 44+ just by reducing trees density so using GPUs beyond GTX 1060 should easily reach ~60 fps.

 

Sure you can overload built-in with 100 assets but every asset is a ticking time bomb in your project that will sooner or later explode. Even if it looked the exact same quality as HDRP, it would be way better to have them on a "stable" platform. If you just want to render a cool forest and not make a full complex game thats no problem tho.

 

I literally said "just 1 3rd party asset used".
I agree with you on the stability part, the issue is that you don't get all the benefits of HDRP without its cons.
So it's a tradeoff in the end when choosing between one or the other.

 

Interesting, could you please share which asset you are referring to?
I have one year of experience with Unity and I am still learning a lot of new things. How come adding those kind of assets in built-in may affect the project stability?

 

any asset potentially compromises your build stability and adds technical debt. We went very minimal on assets, knowing this beforehand and being very careful, yet it has been a disaster regardless and virtually everything had or needs to be ripped out and remade. Also never ever use something like Bolt, this will outright kill your project once it grows a bit larger if you use it as a scripting replacement.

 

The asset is called "Aura 2" for volumetric lighting but depending on the Unity version you're using I recommend you check alternatives first because it has some mild though inconvenient bugs in Unity 2022 (in edit mode only if you enable preview in view scene, runtime works fine) and hasn't been updated accordingly yet by its author.

As for project stability well I've been using Unity since fall 2018 and I can tell you that I've added a lot of assets & 3rd party tools/systems in my project across the years and I haven't had any significant stability issue.
Generally when there's one the author would point it out in their documentations and provide a reasonable work-around so make sure to read them when a problem occurs or do a google search.

The only time I recall I had one I couldn't solve was when I added Unity's AutoLoD package from github which was and probably still in preview (in Unity the term "preview" means potential issues/instability for a feature/package) and it caused a 3rd party auto-save asset to not work. Since then I removed that package and the auto-save now works fine.
A more recent conflict I had was between GPU Instancer's terrain detail component (asset) and Unity's built-in projectors (decals) and I was able to solve it easily by following the docs and even edited a short part of the 3rd party code to make the solution automated. Now since version 2021 Unity added GPU instancing for terrain details so I no longer need to use that component anyway.

The thing is if you're working on any project beyond low complexity level you're gonna have to use at least a couple of 3rd party systems/tools regardless of the render pipeline you're using and whether you want to or not and that's simply due to the fact that what Unity offers by default is not enough to fulfill your development needs and it's a common, well known quirk in the community.

Now if it were up to me I'd like to use HDRP but the upgrade from built-in would break pretty much most of the assets I'm using and fixing them one by one would be SO tedious that I'd rather add a few visual enhancement assets and continue on a smoother development than having to deal with all the headaches that upgrading entails. Also HDRP comes with a significant performance overhead (intended for better scaling) essentially barring out a good chunk of potential PC players from playing my game.

 

Thanks, i will avoid Bolt from now on!

 

Thanks for sharing you experience. Of course I'm a newbie, but few months ago I was messing around with Gaia in HDRP and I got like 10FPS. Of course was just a test and I didn't optimize the scene, but I was scared about the very low frame rate on a 3060.
So I started using URP, even if of course it doesn't have the same visuals, but in this thread I'm reading that the difference is not that much with HDRP in terms of frame rate, optimization and overall problems.
I have no project and I'm still learning, but to be honest I'm a bit confused: of course I don't have to compete with AAA studio's but I would like to have good graphics without the necessity to become a NASA engineer just to make HDRP optimized and running on a fairly new machine.

For a newbie may be better/easier to use built-in/URP and then use some plugin to have better visuals in your opinions?

 

I don't know if you've seen them yet (I only recently discovered they existed) but there are free official ebooks available. Here's one for HDRP.

https://forum.unity.com/threads/upd...ing-in-the-hdrp-e-book-available-now.1284254/

And one for URP.

https://forum.unity.com/threads/new...pipeline-for-advanced-unity-creators.1323774/

URP is definitely easier to set up and create assets for but you still have to learn how to optimize your scenes and terrain is one of the heavier things you can have in a game. Third party assets can somewhat help to make up the difference but you're still limited compared to HDRP.

DOTS too. It's one of the best showcases this engine has right now.

 

SRP = Scriptable Rendering Pipeline which can refer to either URP or HDRP as I'll be using this term a bit.
It's worth noting that you can start with a built-in project then upgrade it to URP or HDRP anytime you want, idk about the other way around though. Which one you should choose will depend on the following:
-All the assets you need are compatible with the version you intend to use for your project or you can and don't mind going through each one and upgrading them manually.
-There're enough resources and documentation online about most things you need to know.
-The rendering pipeline has the features you need in good condition.

HDRP is clearly meant for high fidelity rendering, has a lot more native features for that purpose but also requires better hardware from both dev and users cuz it has performance overhead. I don't know anything about URP nor why we would wanna choose it over built-in. Unity claims it runs better on mobile for example but I read posts saying that it runs worse than built-in on that platform (could be the default settings when using the sample scene template) and that you need to do extra efforts for it to run properly. Maybe it improved now idk.
All I know is that Unity wants to replace built-in with URP in the future as the new standard pipeline and so they no longer intend to add major features to built-in. That means a lot of the new stuff generally comes to SRPs but Unity still made things like terrain detail GPU instancing, Shader and VFX graphs tools now available to built-in so yeah go figure.

The issue with SRPs is that they lacked fundamental features even about 1 or 2 years after deemed "production ready". For example URP didn't have shadows for real-time point lights until a while ago. HDRP didn't have a solution for terrain vegetation details until some time ago as well. Now they have both significantly improved but the issue is that you may not know what it's lacking down the road once you've started working on a project until you reach a roadblock later.

In my case I have a big asset library a lot of which isn't compatible with SRPs and would be a headache to convert manually and at least I know that built-in is the most stable, consistent and have plenty of online resources for it since it's been around for way longer than the others.

 

Scenes made in Gaia's older versions aren't optimized and I haven't used it in about a year and half so I still need to test the newer ones but the first times I tried it I also had bad fps some of the reasons were a lot of Particle Systems running even when out of sight (I know they added a culling system later) and detail density was higher than it needs.
Besides in the Gaia manager they give you presets that affect performance depending on the desired generation quality.

I can give you a few tips on some of the common big performance offenders:
-If you have a lot of trees try reducing their number and make sure the terrain turns them into billboard when far away.
-Terrain detail density is too high when there's a lot of terrain vegetation and rendering distance is a bit high (try detail density of 0.35, 0.4 and a distance of say 55, you can increase these if it doesn't hit performance).
-Textures with anisotropy > 1 when they don't need it (basically things that the player will generally not look closely at like grass and small details or not from a steep angle don't need anisotropy).
Also avoid setting it to "Forced on" in the Quality settings unless you really need it.
-Not using occlusion culling when you have a lot of big occluding obstacles (e.g walls, buildings, hills).
-Not using culling in Particle Systems and Animators (they have a simple popup list to enable it).
-Some 3D models have very high tris count (e.g > 100k tris for an otherwise simple model).
-If you have many real-time lights in your scene use Deferred Rendering (cref).

When you don't understand a term just google it, usually what you have to do to deal with it is much easier than the technical descriptions & definitions you may find about it.

 

@Ryiah @StellarVeil
Thanks a lot for the advices, all very useful!
I will probably experiment a bit more with all three pipelines, hopefully some of the major problems with SRP will be solved in the future. Or I will go with built in, less fidelity but less problems apparently..
Thanks again!

 

Unity is between a rock and a hard place
Built-in is 2005 era and you gotta do all on your own or overload your project with assets which are ticking time bombs waiting to go off. URP is completely undercooked for PC games and you again need to do it all on your own. HDRP is quite complete but requires more skills and does not support mobile or switch. If you don't have high demands on graphics or go for a stylized look, built-in might still be the best option. This all has been critically mishandled.

If you make a serious larger PC or even PC/Console project you need to stay away as far assets as you can. Think very carefully what you really need and only take that. Avoid big assets that do big important things as hard as you can unless its absolutely a must and not doable by yourself. If you have your pathfinding, serialization, audio, AI, shaders, editor tooling, save and loading, localization, level creation, networking all depend on assets you will sooner or later have a really bad time when you reach or find out their hard limitations, issues or unsolvable performance or editor performance issues slowing you down to a crawl.

 

I'm a Unity newbie, but from what I've seen it's not possible for a solo or a little studio to work without the asset store. Of course I try to do as much as I can on my own, but there are things I cannot do without, like 3d models or shaders. I mean, I can do anything but not with the time I have since I have a 40h/week job.

At my point in the Unity's learning curve I can't really understand what you mean. For "assets that do big important things" you mean like character controllers? Level creation you mean at runtime right? What's the problem with save and loading systems? Can't someone understand if they are reliable or not after few tests during development?

 

What? xD lol are you sure you know how to use those features? i did not read your entire list tho

i don't know Rick... looks fake

 

Rendering does not matter anymore: it's not a brainer for a small, skilled team of artists to come up with a realistic environments using both technologies.

The problem is elsewhere: Unity tech is underbaked in many places (also being extremely well built and designed in others). This makes iteration times unpredictable - i.e. from today: upgraded to a new version, using UnityHub my HDRP project - everything exploded in unity owned packages! Downgrade? The same effect, which makes me waste a ton of time getting project to a workable state again.

This goes for Unreal as well - there's lot of problems w/ Nanite and all other new, shiny tools (as reported by folks from a friendly AAA studio).

Iteration times are the king - are you able to work in a stable environment, focusing on content development and integration OR you're constantly battling editor: whenever it's you on your own or a dedicated team of support team - time you're waiting for this to be resolved it's a time you're not making a progress.

Multiply this by console platforms, which bring their own compatibility problems and you got full picture.

Wrapping this up: for 3D, hi-fidelity projects we're screwed: none of a big tech: Unity or Unreal guarantees a stable experience.

Solution: as a developers community we should not be easily distracted by the hacked demos and promo-videos but demand from a companies to give us stable, pipeline optimized, well-documented tools. Or else!

 

This is why is you do not update to a newer version when you are in production, this is a very well know topic, also for 3d artist as well, also is common sense.
EDIT: I really don't understand why user get mad at unity when they update (for example) 2021 LTS to 2022 or 2020 LTS to 2021 LTS in production and the project explode everywhere. That is the common way 3d software works. I think Unity devs needs to work on communicating that because i've seen many user blaming unity for that (but that is not exactly unity's problem/fault either)

 

That last image looks very cool

 

Thanks for an advise bro - yeah, these new versions, like fixing bugs, and improving stuff you use daily are there just for fun and make download list long!

Your comment is totally valid for betas and alphas - that's the risk you take, in a sandbox, etc. Now version in question is not that, that first thing. Second thing: it's not about some feature now working after upgrading. It's about upgrading to the stable version f*cks up your whole project, breaking UNITY own packages! That's why people get mad.

It's a matter of being serious with your paying customers - you ship it good, or you don't ship it at all!

 

Maybe i did not understand your point, if you are working (for example) with 2021.1 LTS and update to 2021.3 LTS and you have bugs, then you are right, those are rare cases but you can send a bug report with the unity tools, i'm sure they will fix your problem.
But if you are talking about 2020 LTS to 2021 LTS then you are not right, let me give you a simple explanation for that:

There is an internal logic that you don't see on any program but that code is the reason things works, on 3d programs that internal code describes how things are showed, for example, how the shaders are rendered, how poligons are rendered, how each tool comunicate with other tools etc... When you create a project in 2020 LTS your project has a code, that was made with that version of unity, it is a lenguaje, your project is talking with the "internal" code of unity 2020 LTS and asking for orders and words, now if you take your 2020 LTS project with its 2020 LTS languaje and use it with a 2021 LTS version of unity, the lenguaje is different because in order to make updates you need to change things that were "bad" in the previous version like how shaders are rendered, how poligons are rendered, how each tool comunicate with other tools etc... all that to make things prettier and faster so the lenguaje now is a bit diferent (for the changes unity devs made) now, your project is 2020 and he is wating for some 2020 "words" or "orders" to make things but the words and orders he is receiving are different so he can not work, that is why the bug exist.

So, Again: This is why is you do not update to a newer version of unity when you are in production even if you a changing to a new LTS version, this is a very well know topic, also for 3d artist as well, also is common sense.

EDIT: also is very important that you make a copy of your project before making updates even in the same LTS version, in fact, unity show a message saying exactly that and you have to click a button accepting that message to update, so is not that side's fault if you waste a lots of hours

 

Let me correct you.
You do upgrade to a new version.
Just make a backup first, you might need it very very soon.

And let's be realistic in here, vast number of companies doing projects longer than 1+ year do upgrade to newer versions even during production.

 

There is this game called Escape from Tarkov, is the most complicated fps in the market, i think they are using a very optimized HDRP, but i can be wrong

 

AFAIK they're using highly optimized built-in renderer - they started project before HDRP and I didn't hear anything about them switching rendering pipelines recently (I'm not following this project closely though).

 

They made an update with a new version of unity last year and i think they mentioned HDRP...