Thanks for the reply it’s not the reason for the huge performance regression from 5.2 to 5.3, the VSM was set to shadow maps and not using virtual shadow maps for both the 5.2 and 5.3 versions of the same project, the shadows resolution could be the difference but need more testing.
5.3 is too lagging for most cases other than video rendering, waiting for the official 5.4 version to be released, should test some environments from the store with popular settings and return to the similar performance of earlier versions.
Tested several example projects from market place and compared their performance between 5.2 and 5.3, some of the well optimized maps actually get performance boost from 5.2 to 5.3 e.g. Modular Gothic, after setting the default RHI from default to DX11, and the reason is apparently DX12 that’s much slower and more buggy than DX11.
Some of the not optimized environments get huge fps drop from 5.2 to 5.3.
These slow environments generally have more than thousands of actors in the scene, not using enough lods and using too many materials and material slots, seems the draw calls are more expensive in 5.3.
It’s quite disappointing that while the stylish environments get performance boost from 5.2 to 5.3, the better looking and more realistic environments generally get large fps drop from 5.2 to 5.3 even when they’re optimized.
They probably messed some code in 5.3 to cater for the buggy and much slower DX12.
Would suggest keep using 5.2 and DX 11 with SM5, unless really need the advanced PCG from 5.3 and other newest features.
no you must have some sort of issues or settings that changed somewhere because i have slightly better performances in 5.3 over 5.2 in many content exemples/unreal projects exemples.
Moreover sometimes Epic changes some default settings.
Content examples have Lumen and Nanite turned on, Lumen and Nanite were improved from 5.3
My tests were done with these features off, configured for games that need performance
Lumen, Nanite, Mesh Distance Fields, Temporal Super Resolution, Virtual Shadow Map,
Tested with these turned off for both versions and UE5.2 with DX11 outperforms UE5.3 with DX12 by 50% -100%
with any large and realistic environment I bought
Found this explanation from Unreal Source:
“Unreal’s DX12 implementation has been known to be pretty bad, the first version (since 4.9!!!) that actually multithreads it properly is currently expected to be 5.4 and I’m pretty sure it will only be a first pass at it and 5.5 will get it better
it’s kind of insane they went with a single render thread for this long”
My fps is about x2 better in ue4. I’ve opened the third person template from ue4, added 20 scene capture components and got around 100fps in ue4. Same scene then opened in ue5 resulted in 45 fps…
it’s kind of insane they went with a single render thread for this long”, so this.
Pretty over perf. ?
Whatever, I get it, gamers want bling in general, get it. Why not both ;))
OUCH major. Well I went for 5.3 for better huge open worlds, world part, cull distance volumes, etc., lumen nanite!! Nanite is awesome, will be, for beautiful terrains streaming, as nanite allows for finer grained streaming control .
Just leaving some notes here.
I made some other tests with the base FPS template (c++). My results here are only on barebones projects. So they are just indicative or baseline performance. Im using same settings/project across ue4/5 versions
UE 4.27 physx V 4.27 Chaos
When comparing just regular performance (no physics simulation), I was surprised to see there was only a very minor difference in favor to physx.
My conclusion from this is that the major base performance drops are mostly related to 2 things.
Ticking system → Ticks have gotten around 30% more expensive in Unreal Engine 5, apparently because now the engine tries to have more control over tick execution.
Renderer ->After looking more into how Unreal handles rendering I realized that several changes had to be made for how meshes’s proxies are renderer for them to work with raytracing / nanite. This is a change that unescapable even by turning off lumen/nanite.
Material System → Likely, more the material system does more shader permutations because of lumen support
In other minor findings, I found that barebones ue 5.1 projects would perform slightly better than 5.4 projects. (although this changes with regularly sized project)
To go the point the difference in performance between 4.27(chaos) and 5.0 is the following on the ue4 fps template:
4.27 Base 850fps up to max engine fps (1250)
5.0 Base 490fps up to 780fps
I tried to reduce UE5 rendering settings as much as possible and this was the max fps I was able to get. The difference is big indeed.
Did anyone find a c++ way how to revert back UE5 tick to UE4 in case we do not need Nanite/Lumen/VSM/TSR and all these fancy things? Just to keep the UE4-like inside UE5…
I realized that when comparing UE 4.27 Chaos to UE5, UE5 has the PhysicsFieldComponent tick always enabled. I also found that the Camera component ticks even when it’s set to off in the Blueprint, which wasn’t the case in UE4.
Unfortunately, I currently don’t have a working source version of the engine, so I can’t modify the code to see how it runs without these two ticks. The tick list difference between the same project in UE4 and UE5 are these two ticks.
Another thing I noticed is that UE5’s baked lighting has overall better fidelity. On the same level, it generated 32 light maps in areas where UE4 only generated 24.
It’s important to note that the GPU stat is significantly lower in UE5, suggesting that the overhead is likely on the CPU.
I will provide an update after forcibly disabling these ticks in UE 5.5.
You could extend the camera and PhysicsFieldComponent component with a custom class and override the tick, no need to touch the source of the engine.
in physics component it’s virtual and public so you have access to it
ENGINE_API virtual void TickComponent(float DeltaTime, enum ELevelTick TickType, FActorComponentTickFunction* ThisTickFunction) override;
same goes for the camera
ENGINE_API virtual void TickComponent(float DeltaTime, ELevelTick TickType, FActorComponentTickFunction* ThisTickFunction) override;
Well, I did the test with todays version of 5.5 compiled with MSVC (clang didnt compile for me)
Good news is that deactivating the 2 ticks did grant a large performance boost. World Tick Time went from 0.68ms to 0.45ms, it was a consistent -0.2ms. Not sure what issues could cause this PhysicsFieldComponent tick deactivation but the small project was working fine. Also this component was not ticking in 4.27 Chaos so it could be just fine for its tick to be deactivated.
Now, on to the bad news. For some reason GPU times were much higher on 5.5 on Low Settings, so the overall fps were 90 fps less than 5.4 even tho the cpu utilization was lower.
I hope this is related to a new setting that can be deactivated or just something that’s has been overlooked on the current 5.5 code.
However I’m happy about the PhysicsFieldComponent tick finding because it’s the one thing I have found so far that was not there on UE4.
World Tick Time Comparison:
5.4 0.68ms
5.5 ( PhysicsFieldComponent and Camera tick off) 0.45ms
4.27 Chaos 0.26ms
To go into further details, so at this point 5.5 and 4.27 are running the same amount of ticks its just that the ticks are more expensive on 5.5. Here providing a table comparing the tick times, Player Controller and CharMov ticks are the most important since the correspond to a single Actor Tick.
CharMov Tick 4.27 5.5
Idle 0.02 0.03
Moving 0.05 0.08
PlayerControllerTick
Idle 0.02 0.04
Moving 0.06 0.10
Blueprint Time 0.02 0.03
Tickable Game Objects 0.01 0.02
World Tick Time-Tick Time 0.04 0.06
Ticks here ate 50% slower on 5.5, as I mentioned before I believe this is because the tick system in ue5 is more elaborated with the engine trying to manage the tick ordering and tick groups. For example Batched Ticks was not present in UE4. I tried deactivating batching ticks from the console but I saw no difference.
Im currently diving into the soure tick code just to see if something can be done about it.
I’m not sure it’s relevant to compare performance with blank projects.
Perhaps you should add thousands of moving actors to make a proper comparison of CPU performance.
It’s probably the same for GPU rendering, it would make sense for the engine to be heavier for very simple tasks but scales better with high GPU load.
If you read the initial post, then you know most of my testing was done in one of my projects, so I havent tested mostly on “blank projects”.
Yet, its still important to check on very small projects to know how each thing on the scene affects performance, that’s how I found out the tick count difference actually.
I need to make some comments on the upcoming 5.5.
So, I’ve been using the engine for some time, currently running this week version of the engine (thursday).
There has been a large performance regression on 5.5 for gpu times. Im talking about a very visible regression for example going from 1050fps to 820. Im not sure what’s causing this large performance difference but it’s been like that for some time.
Given that 5.5 should be releasing around September-Oct, performance its not likely to change from what it is atm (it doesnt seem like a bug), so better for users to know from now.
Can they return the UE4.25/4.26 performance and stability to UE5.5+?
Would be very interested into digging into CPU perf.
From my quick Stat Unit/ Stat RHI observation, I’m seeing Game-thread perf being lower ue4.27 → UE5.3, in my project. Not sure what in Game-thread is slower specifically yet.
Would be awesome to find out if we can bring back any performance, if it turns out the issue is tick related. Either tick perf itself or as mentioned above, the scheduling/dispatch of the ticks.