Discussion List of Steam HDRP games

https://steamdb.info/tech/SDK/UnityHDRP/

Looks like a healthy and growing list. Some of these games will no doubt have HDRP experts wincing at the questionable settings, but much love to how many HDRP-powered games there are out there!

 

Such growth deserves more resources behind HDRP. After all, that's good business.

 

I created that list (there's also unityURP)
Biggest issue is it doesn't show il2cpp games, many HDRP games use il2cpp, out of memory some popular games using HDRP with il2cpp: Metal: Hellsinger, V-rising, Road 96, Car Mechanic simulator 2021

Although you can find il2cpp games listed in the more general Unity engine list

 

Look at all those indie games that'll never get a Switch port, even though most of them look no more complex than the average looking Switch game.

 

So are these all the HDRP games on steam? Is there better detection (not sure IL2CPP has anything to do with it as it improves CPU perf.... and probably not enough to port to switch haha)

 

yeah all games on steam are automatically detected no matter how big or small it is, including public demos
it does it by reading file names (HDRP has certain files only available when using HDRP), with il2cpp none of these files are available by default so it can't detect them as HDRP/URP, but it can still tell if it's unity or not

 

Unity dropped support for mono on consoles back in Unity 2018. The only platforms where you can still use mono are Windows, Mac, and Linux (you can build for Android using mono but can't publish as it's only 32-bits).

HDRP also stopped supporting Switch in the 2019 cycle. The Switch Nvidia GPU does support all features required by HDRP, but since HDRP ridiculously high main thread CPU cost just kept growing with each new version, the weak Switch CPU probably couldn't keep up. It's an issue even on PS4/XB1, where getting 60fps with HDRP is near impossible.

(You can get HDRP to run on Switch by modifying it, but I personally never tried it myself and never dove deep into its source code to see if there's anything that can be done about the wild main thread costs without access to the Unity source itself).

Though now that URP has deferred rendering it's at least possible to migrate over in case push comes to shove, even if it's a major hassle.

 

CPU is definitely becoming the bottleneck, with next gen GPU's coming in a few months, CPU will become more of a problem, at least on PC...

 

Wait the latest Syberia are using HDRP? Kinda surpising since the previous game was using UE4, make me wonder why they switch

 

Because it's way, way easier to make games in Unity? I love all engines, but Unreal is a pig to dev in, and would harm indies. Same for my choice of using HDRP vs URP: HDRP is a lot less work for a small dev to make something look good with 4K support.

It sucks at anything <PS4 but since day one, HDRP staff have patiently explained it's for PS4 and above. Docs reflect this. So if indies need an easy time and aren't targeting switch or mobile they're good.

HDRP running space ship demo on PSVR2 was eye opening for me. Literally, since it uses eye tracking to reduce bandwidth.

 

Well i can't say much regarding UE though, since i never dive deep into it.

Interesting , i mean i know that HDRP can run on PS4 but the part where it runs on PSVR2 is an interesting information, i didn't know that.

 

I disagee with the staff member that HDRP requires a bigger team. It doesn't, as you know from that steam list. I believe they aren't actually making games and simply assumed with that comment that the games would be mobile level, in which case yeah URP is easier. For 2D or basic platformers etc.

The reason HDRP is easier for any visual title, is because of a few things:

• it's easier to get lighting correct. everything is explained, everything has a matching exposure and lighting preset. Match those up and it instantly looks fantastic
• no fighting of assets or 3rd party stuff - hdrp has all you need
• no optimising woes as you can control HDRP extensively
• way better documentation and video resources

I'm having a much easier time making things look good than in URP, and I'm saving substantial time avoiding rolling my own tech, or reproducing missing things in URP.

Having said that, I'm not a typical user so what is trivial to me may be a big gap for someone else. So I guess that's the context.

 

Assuming it's all correct, some entries on this list are pretty interesting as they aren't going for the photo-realistic style so I'm curious what benefits HDRP gives over built-in? For example if you're running a PSX styled game, you don't really need super detailed shadows or lighting, so what benefit does HDRP give you that you'd want?

 

any hard data on that?

 

None that I can share, but last time I got a prospective port of an HDRP game it wasn't certain if even a PS4 would run it since by just sitting on the main menu with nothing going on HDRP would use 8ms of main thread time by itself. Not to mention using almost 1GB of RAM on shader variants.

The current gen consoles and their vastly improved CPUs are blessing for such Unity games.

 

Remember that it wasn't until Unity 2021 where URP got crucial features like point light shadows, decals, deferred rendering and a few more. So if you wanted shader graph in a project you started using Unity 2019 and 2020, HDRP was the less limiting choice, specially when many people see built-in as "deprecated".

 

VFX graph's being ported from C++ to DOTS at the moment.

For HDRP to follow suit, that'd fix the problem. The amount of CPU side work HDRP has to do was predicted pretty much from day 1 by Seb Lagarde on these forums. He said that there wasn't much the could do to increase HDRP performance on CPU until other parts of Unity improve.

Sounds like we're still waiting for that. But it sounds to me that means porting SRP to it or at the least, calling out into DOTS land for culling, sorting etc.

 

8ms empty is a lot. I thought that SRP batcher took care of most of it, keeping the cooked geometry on the GPU and only sending transform matrices, now I'm curious, did seb say which other parts of Unity need to improve?

 

it was moved to the "under consideration" portion of the roadmap, so no promises there unfortunately

 

High definition rendering. Phisical correct shaders, lighting, volumetric lighting, etc etc

Spoiler: images

It looks like it's unity 4. People don't understand why they need HDRP and the minimum recommended requirements for such games are "8 cores, 16 ram, gtx 3060". It's a joke? WTF?

 

CPU in relation to SRP / HDRP. It's the limiting factor, try searching for his posts from the beginning of time when the world was young and PBS was a distant glimmering dream.

That's a developer and not engine problem though. Plenty of others are making sexy stuff. My own stuff is tested and running open world at monitor refresh on a 980. So it can do very nice things. I think it's fair that badly made games are bad in any pipeline.

 

What the SRP batcher does is reduce the amount of render states set between draw calls of different materials which use the same shader variants. The SRP batcher itself is implemented deep in Unity's C++ rendering side.

The SRP main thread performance problem comes from the fact that a render pipeline needs to do a heck lot more than send transform matrices to the GPU to get things rendered, and the bulk of the C# APIs used to do those can only be executed in Unity's main thread. This includes everything that goes on inside the ScriptableRenderPipeline.Execute() method, which is itself run in the main thread: place a breakpoint there and keep pressing F11 (or enable deep profiling) to see just how much code it execute every frame. While Unity does the the actual graphics API calls from other threads, preparing the data needed for those API calls is done by SRPs via managed C# code running on the main thread, and it can add up pretty fast on lesser CPUs.

Meanwhile all sorts of things which Unity can only do on the main thread (like updating the more-expensive-than-it-should be new input system) are blocked waiting for the SRP to do its thing, unless the bulk of your game logic runs in parallel jobs. But since jobs can only be scheduled from the main thread the more time is spent inside ScriptableRenderPipeline.Execute() the later in the frame your jobs will be scheduled, having less time to complete if you want their results to be used in the same frame.

It's clear that this isn't very scalable.

Finally, DOTS can't help much there: a lot of what it's doing is calling functions on managed objects (some being UnityEngine.Objects) which in turn invoke internal C++ functions in Unity, which is not what DOTS is about at all (processing a bunch of simple data using SIMD). You can't jobify things allocating a temporary render target or toggling shader keywords, for example. While you can use jobs to copy data like vectors and matrices to a ComputeBuffer/GraphicsBuffer, you can only lock said buffers for writing (which might require calling a low level graphics API function under the hood) from the main thread.

A proper solution would be to have ScriptableRenderPipeline Execute() and other callbacks all run in a separate dedicated SRP thread. This would require a lot of refactoring in the C++ side, with probably a whole new branch of the C# graphics APIs or a complete breakage of the existing ones. Having some way to schedule jobs from this "SRP thread" for graphics would also be necessary (maybe a separate job queue?). Until then I'm afraid the CPU requirements for both SRPs will continue creeping up with each version.

 

Absolutely right. I have used HDRP with teams big or small.
And I am using it almost exclusively for all my personal projects.
Except mobile ones of course.

I like it a lot exactly for the reasons you mentioned.

But also, to be honest, in most of these titles I cannot see why they used HDRP.

Many people feel that by using HDRP their assets will look better. They don't.
Broken aesthetics are broken no matter what graphics technology you use, and if the artistic value is not there, it will not magically appear with HDRP.

 

I agree with you but URP can look really bad. Especially with aliasing. HDRP has DLSS so, it it super sharp clean. Then go URP my eyes melt down....

 

Does that list include released demo?

 

The list includes demo but also excludes the majority of games in HDRP that use ILC2PP so it's a crap list

 

Not really, you won't find any list out there with more accurate games that use HDRP, so it's the best you can find currently.

Worth noting if a game ever releases a build that doesn't use il2cpp it'll be added to HDRP list, even if it goes back to il2cpp.

 

Yeah there's just a fair few there I know that are higher profile and not listed, as IL2CPP is mandatory for HDRP games. This will usually happen with higher quality titles because the developers know about the CPU hog and will do all they can to minimise it.

What detection parameters are there, could you have overlooked one?

 

It's based on file names, il2cpp hides it and steamdb is unable to do anything more then checking existing file names.
In the future, steamdb might have a custom il2cpp list where users add URP/HDRP games based on user findings (dumping il2cpp) Steamdb admin was interested in that idea when I did this list.

 

100% agree. its sad, but none of those games look better than built-in render pipeline with the usual good looking assets from the unity store for sky+fog+lighting+GI+water+etc