Question Empty Scene Low FPS

These are the FPS in an completely empty scene inside a build.

In the editor, the max I can get is ~65fps.

Why?
I played with the default settings, quality settings, disabling different features of the HDRP but the result won't change.
Based on such low numbers in an empty scene, it is almost impossible to use the unity recoder in scenes with actual content inside them.

In Editor Profiler Screenshot:


Any idea what causes such low FPS in an empty scene?
Turning off PostProcessing didn't help much, just 1-2 fps more.

The "Stats" inside the GameView show the same fps, like the profiler does - the numbers from the screenshot are from the "LiteFPS Counter" Asset, which always was pretty much on point with the numbers in previous tests.

Could you share how many FPS you get in an empty scene? ^^
Also if someone can explain this, please do so, I have absolutely no clue whats going on.

Fps should be ~3000 (running on my 3070), not ~65.

And as it is above 60, there is no limit, sometimes it reaches 72 for a few frames, then falls back to 65.

(VSync is turned off btw.)

 

I have been noticing a lot of posts recently and in most of them the major cause for the slowdown is the new render graph feature

Although I really have no idea about how it works

(in your case though it also seems the main culprit is that you have turned on deep profiling)

 

Yea but deep profiling won't run in an release build, right? And ~230fps in release build is far too low for an 100% empty scene (except direcitonal light, camera and the UI with the fps counter)
As said, it should be around 3000 fps.

Turning off Deep Profiling, still does not increase the recording performance. (I think it doesn't affect the performance at all when the profiler is closed?)

"Render Graph" - I'll have a look at it.

 

There's an option to enable it in the build settings window

 

You have to stop recording, not just close the window afaik

 

was this solved? I have a similar problem with only 200fps in an empty scene...

 

The problem with an "empty" scene is that you're still rendering lighting and shadow in an infinite space too.
If you're using HDRP, the scale of this lighting in real-world units is all computed in real-time as well, hence generally the baseline of HDRP is much higher because of these additional operations.

• It's important to understand that the HDRP asset will compute everything that is enabled. so if you have all of your post-processes, depth checks etc they're all still computed
• The HD camera costs around 1ms by default.
• it's also important to note that most of these processes are CPU based instructions so your GPU wouldn't even matter in this case as it'll likely be rendering the empty scene in 1ms anyway.
• the 1000+ FPS isn't much of a thing anymore because the package scripts more often than not assign 1000 hertz on the CPU (1ms) this will basically make the editor run between 2/3ms with everything else added on a build this should be much lower.
• profiling has a cost and Deep profiling is expensive because of the script checking.

This in turns means that HDRP should be running ~200fps at stock and 300-400fps with most processes turned off that aren't being used to render an empty scene.

by comparison, a live projects empty scene with a tuned HDRP asset and project settings. You'll see that there isn't all that much difference

Hope that helps to better understand some things.

 

You confused "FPS" and "ms", right? ^^

 

Hehe I did, thanks for pointing that out.

Has now been corrected.

 

Higher than 60 fps is not too much valid
Your blank scene can run at 60 fps
Your complete game can also run on 60 fps

 

I tried doing this but still 2019 LTS version performs much better than current versions sadly

 

I'm sorry to hear.
You are able to write performance benchmarks on the editors themselves using

Unity Test Framework

This would enable you to tests performance differences between large editor versions like 2019.4 and 2020.3.
This is especially helpful when making large project jumps to validate its worth.
There is another method but it sadly escapes me.

Regarding 2019.4 - 2020.3, some specific unity HDRP differences may affect the performance, the incremental holds for example, but it shouldn't be too fundamental.

Maybe it's worth creating repros and report it if the engine versions you're experiencing are grossly different.

 

Question: did you guys try to remove the sky?
if i have my editor open on my 4k windows setup, then scene view / game view is nearly 2560x1440 fullscreen.
if i have a nice cube map sky sphere running, i am at 6ms for "nothing else" (not even a directional light), to my surprise doesnt matter if forward or deferred rendering.
if i choose the simpler default sky "material", it gets to aprox 5ms, but if i set the sky to NONE, then i am at 2ms (which is still quite slow).

all this with unity 202.3.11f1 LTS

so, basically what i believe happens is this: rendering on all pixels, takes time. we can see in the profiler that it waits 3-4ms on the semaphore to finish rendering. so filling all pixels atleast once, with whatever shader (here the skybox) takes time.

if i set it to none, then add my game with terrain, foliage, opaque objects, i have barely a few hundred pixels rendered by the sky cube map. so now if i switch it on or off the difference is barely a quarter ms at most.

so if you want to measure what unity engine is doing in an empty scene, like checking setups and configurations, use black screen (NONE sky). if you want to measure basic overhead of rendering pxiels, like MSAA on or off or ANISTROPIC forced, then you can see the results already with the sky

 

What you see in a build is appropriate for this render pipeline. HDRP is designed to scale to very large scenes but the way it achieves that results in very high overhead. An empty scene will perform far worse for it than built-in or URP but when you scale up to that very large scene it will perform better.

Concerning the editor my first thought is that you're being held back by that CPU. A 5820K was seven years old at the original thread date (eight now). A budget processor (5600X) from 2020 is easily 67% faster (PassMark) with newer budget models (i5-13400) being almost double. A top of the line (i9-13900K) is around 2.5x.

On my system (5950X w/ 3070 @ 1440p) the editor (2021.3.6) has the same performance that you see in a build.

 

Alot of good points here, but the main thing is....its an empty scene. You cant judge anything by an empty scene. The engine is used to create games and other content, not build empty scenes. Why are you doing this test in the first place?

Your testing the waters before working with HDRP, or your really worried about the fps/ms performance of HDRP. The only way to test that is to build a scene, and see how it performs/works. Also, its posted all over the forums and widely known, newer/latest releases of Unity are not the best versions to use. 2019 LTS is what i and most devs use, for many reasons.

Its more solid/stable. The other big thing is compatability with assets. 2019 LTS supports 90% of store assets, but the newer assets are mostly for 2020+. So if you use a 2020+ version, you cant use most (some work) older assets (2017 - 2019), but you can use the limited newer assets.

HDRP is a great SRP, things change as you build your project, and you adjust/optimize it just like BuiltIn, URP, or any other engine.

 

This was more than one year ago and as mentioned, I couldn't play the game with the recorder running, it was lagging too much. So I checked if I have to remove things (meshes, shaders, lights) and therefore checked the performance in an empty scene.
Even adding just some objects (terrain + few meshes) to the scene would shrink the performance so drastically that the recorder cannot be used without lag.

At the end, we just bought the "Fullscreen Editor" Asset and recorded our trailer footage with OBS and in the Build with NVidia Shadowplay.

Also I made a video about all the optimisations and workflows we discovered for this game:

 

John Leorid, could you tell the target hardware for your game (as seen in your youtube video) ?

 

Everything you do in this video is exactly what i do, and even more (no joke). I also pre-optimize every asset as they are added. Ill take say a tree, and optmize the model, textures, material, and shaders. I also prefab everything, easier to make one change to a root object, and have all of them in scene update the change at once.

Ive used SECTR on many projects, for years. The main point is for any large open world games, you MUST use a terrain chunk streaming solution, as Occlusion Culling is useless. Camera settings is another big thing you didnt touch on, as i find many newer users forget that what the camera sees is what it will render (per near/far plane, etc. settings). A simple mistake, but a costly one with performance. The camera only renders what you tell it to...

 

Nope, this needs testing. But it did run fine on my dad's PC which doesn't have the greatest graphics card, nor any gaming CPU. I don't know any specifics.
Or do you mean the hardware of my PC to make the game? GPU was very important here, it lagged a lot with the 980Ti, then I bought a RTX3070 and all Scene View Navigation Issues basically disappeared.

 

Not sure if I should start a new thread or not but I'll tack it on here

I'm sorta finished my last major game, With this running in the editor 1620p I get 80-100fps standard pipeline (can be 1000s of objects rendered)

Same PC, I start a new project blank canvas from the template. Just has Sun & Sky and Fog Volume but nothing rendered FPS = 24.
OK thats a non starter, haha.
So I disable Sky & Fog Volume. Performance is a lot better at ~150fps

I realize with HDRP theres gonna be some fixed overhead per frame, thus performance should NOT start dropping off rapidly when I start adding stuff, but still is it reasonable like only ~20% lose of performance compared to standard pipeline, or is it that HDRP is still only really aimed at ppl with high end graphics hardware, mine like medium (nvidia 1650 ~4 Tflops )

 

Your light and fog are essential infinity unless you tell it otherwise or put things in the way, since these are mostly per pixel costs, you can probably see why a seemingly infinite void gets expensive.

Similarly you'd still need to tune the pipeline asset.

Base your project needs to the pipeline asset. Build stuff then worry about your initial benchmarks and optimisation passes.

If you want to bench the editor performance build and use Unity Test Framework instead.

 

Cheers mate. I'm not prematurely optimizing (I've been programming over 40 years now thus arent so foolish to do that )

I guess I was asking is HDRP really aimed at normal gaming PC's or does it really expect the end user to have a semi decent PC?
I'm starting a new project thus I want to start with the pipeline that I will be using.
About 3 years ago I converted my game over to HDRP, spent a few days on it which ultimately was a waste of time as in no way or form was HDRP ready for general usage, thus I discarded it and kept using the standard pipeline. Its now years later, I assume HDRP has improved a lot since then and also the average persons PC has improved.
Perhaps you know of a HDRP free game/demo on steam I could try out. On my PC (and also my PC with inbuilt graphics)
Thanks again mate

 

No worries.
HDRP's scope and scale differ dramatically depending on your fidelity and scale of the project, like older workflow and engine days where the better graphics were much smaller levels and loops.

With HDRP there's a lot more gain for applying scalability in your planning stages, so if you are starting a new project and going back into R&D for it, you can apply it there.

Scoping your hardware range based on your target hardware should give you and idea of what you can and can't attain visually.

For example, you should be able to scale up Book of the Dead, but you would have to adhere to the lighting practices and level design to stay withing realtime budgets within 16ms.

If you haven't investigated that recently, it still uses a baked process but it is APV based light probes this time instead of lightmapping and legacy light probes.

In your term of this industry, if you're used to working with dedicated teams or studio/freelance hires HDRP should benefit you there. Just be mindful that people without that skill set typically struggle the most.

I don't know of demos off the top of my head unfortunately, but the last I checked there are above 1300 steam games made using HDRP, around 60 drops a week. It might take some browsing but you may find some demos, or for sure a large enough pool to R&D/market research a similar style and genre to your own current ideas.

This could help you potentially find more hints into it's viability for your project three years later.

Hope that helps.

 

Biggest games came to mind are Sons of the Forest, Cities Skylines 2 (this one is pretty badly optimized), Metal: Hellsinger, Syberia the world before.
As for demos in early 2018 Unity released Book of the Dead, impressive small scene with vegetation

 

would love to play or browse through those ... how do you know this numbers, how can i find HDRP games made and released?

 

https://forum.unity.com/threads/list-of-steam-hdrp-games.1301931/

To keep things forum related .

 

thanks a lot. the "top" games on that list look surprisingly poor: https://steamdb.info/tech/SDK/UnityHDRP/

is there a list of AA/AAA quality-like games using HDRP? i am not saying AAA production value or team sizes or anything ... just the visual quality, even if its just a "fun racer" or something ... because none of these games in that list do look good (i mean none do look better than usual built-in render pipeline games with HDR+usual postprocessing + lighting + fog + sky "assets" from the store, good assets)

i expected more

 

In my experience, few if any have released extremely high fidelity games, outside of Japan using HDRP, this is mostly due to lack of experience or transfering skill sets from the other pipelines, though there are some, since unity hasn't ever been renowned for it it's a rare find. It's one of those things programmer tech artist and artist need to come together on ( and solid team of course) as for stylised choices, take your pick there are many.

Other than my own teams stuff, I've grown quite fond of Fire and steel and Ferocious' approaches. Especially for the small team/solo dev side of that.

Lego builders, for a brand you shouldn't not recognise

 

thanks for the points.

i believe Lego builders is a really good example for HDRP, as they look really top notch (although we dont know what was custom implemented and whats out of the box), but they are limited in their view. i mean, they all just have very few content in front of the screen ... neither are they "fps levels" nor "rpg dungeons" nor "open world" ... so it seems like they do the right choice: go high fidelity with HDRP but no performance sacrifice as they simply dont show much (talking about amount here).

 

I've been using HDRP for a couple of weeks now, performance is definitely slower than the fixed pipeline in the stuff I'm doing. I think I've disabled most things. The funny thing is the game I'm working on now is quite simple thus doesnt really need HDRP, but its nice to learn new ways and its more futureproof, So I'll stick with it. It definitely is a lot more work getting HDRP looking as good as standard pipeline never mind looking better. I was actually expecting it to be easier as in, since its closer to reality you shouldnt have to muck around as much but no I'm finding I have to do a lot of tweaking.
Personally I think Unity should just move forward only with the scriptable pipelines, make 2023 the last fixed pipeline version, sure update the LTS with bugfixes etc but do have the fixed pipeline in 2024 (or whatever the next one is gonna be called)