You really need to look at timings and not FPS.
5.3 doubled TSR and Lumen GI cost when reflections were reduced by half.
They make things faster and slower, it’s been a constant equilibrium.
I suggest adding some clouds to your scene in 5.5 and test with other version for instance.
Ok, then the CPU is not bottlenecking the GPU. If the GPU doesn’t go higher is because “it doesn’t need it”. It happens in many games to many people.
I wouldn’t care about editor performance (as much as it works smoothly) because it may depends on many experimental things, symbols, debugging tools, etc.
I haven’t deeply tested 5.5 but read some goods comments regarding performance. If you notice changes, you should make your own Lumen “profile”, for example, to always use the same values for lumen cvars, as they can change default values if they consider they are better to achieve quality of performance, depending of waht they consider.
Ok, then the CPU is not bottlenecking the GPU. If the GPU doesn’t go higher is because “it doesn’t need it”. It happens in many games to many people.
I’m not sure what you mean, it’s concerning in two ways. The base CPU performance when logic and slow BP’s do come into play, and competitive/BFI needed performance.
Again, I’m not going to act like this is a big concern I’m focusing on.
We got worse bloat in different areas.
I don’t use TSR and I don’t use Lumen. I’m using the Forward Rendering pipeline and as little postprocessing as possible. Why it matters, in this context, is I’m using settings designed to maximize performance, and in those pipelines, RATHER than the lumen-nanite-“who cares about performance we’re an archvis company what’s a video game?” pipelines, performance is improving for the first time in about 5 versions.
Editor performance != packaged shipped performance. A lot of the debug stuff adds overhead to things, not to mention the editor is also pretty heavy.
Also, the editor may be capping to your monitor’s frame rate due to vsync, since the editor doesn’t count as something like borderless fullscreen, and if the PC can technically handle much higher frame rates than that, you’ll see both reduced CPU and GPU loads; due to it capping to say 60hz or whatever your monitor’s refresh rate is.
That’s probably because you are looking at average CPU utilisation and not per logical core CPU utilisation.
I have R7 7700, RX 7900XTX and 32GB RAM. My average CPU utilisation is around 65% but some logical cores are constantly hiting 100% utilisation that why my GPU is only at around 60% utilisation.
If it was in a packaged shipping build the CPU utilisation would be a lot better because the editor is a lot heavier for the CPU and also have a lot of tasks running only on one thread so it’s less effective at multi-threading, not to mention that a lot of complex systems are probably running on slower unoptimised path on the editor.
I’m only getting around 100 fps in a very light scene with very few rending and logic running. If it was in a packaged build i would probably run it at 150+ fps.
If your game uses 65% of a 3.8 GHz, 8-Core cpu… do you need help on optimizing your game?
are you putting all code on tick event or something funny like that?
I mean, Red Dead Redemption and Cyberpunk dont use that much cpu, they use like 10% at top unless something is very wrong at your system setup…
for a game 100% gpu usage is normal, but 65% cpu is not… for a video editor or similar 100% cpu would be normal, but not for a game, that is a non arguable fact, not an opinion.
I just opened the content exemple template from Epic Games…
Apparently you didn’t read my message. If it was packaged i’m pretty sure my GPU would hit 98 to 100% GPU utilisation.
you obviously don’t know how it works if you think that you can compare the editor running with compiler optimizations disabled and debug symbols running with a shipped game.
Editor performance != packaged shipped performance.
But I’m talking about Editor Performance.
Ok so its not just me. My game Cepheus Protocol is experiencing horrible build times for the most base aspects of the engine. Navigation build times used to be 20-40 seconds now they run for 5+ minutes. HLOD build times are now 40 mins instead of 3-5 mins. I have no idea what they did but it broke how the unreal engine uses our CPU’s in this latest version. I have none of these issues reverting the project back to 5.4 via source control and launching on that older version. This is a real bummer.
I reinstalled windows and tried a Threadripper and my 12th Gen CPU i9 and they are 70-80% worse in everyway in terms of CPU performance for building data. Our Nanite Landscapes build times are unaffected… This is odd
Are there any bug reports on this? It occurs on Nav building + HLOD building? Any idea if its earmarked for a 5.5.1 hotfix?
Why are you berating this guy when your conclusion is not factual? Just googling various benchmarks for all the games you suggest disapprove everything you just said.
This guy is regularly around 40-70% most of the time playing.
Red Dead is typically 20-30%. But it is a GPU bound game mostly
It seems in 5.5.0 the ability to select and move ISMs is not working - the click is getting to the InstanceVisualizer class then just falling through and passing it to the ComponentVisualizer handler which seems to be returning the parent as the component is selected.
Still can’t do any shipping build with Hardware Raytracing or Megalights on windows. When are we getting a Hot fix???
Let’s wait. It’s preferable a build which works, instead of an another premature release
Devs haven’t talked about it.
I seem to crash both on closing the engine as well as packaging the game, the exact same assertion failed, converted it over from 5.4 but cannot seem to fix it, I have no clue where it is even coming from after a lot of investigating it, anyone have a clue or similar issue?
Assertion failed: ObjectPropertyTrace::TickerHandle.IsValid() [File:D:\build\++UE5\Sync\Engine\Source\Runtime\Engine\Private\ObjectPropertyTrace.cpp] [Line: 310]
UnrealEditor_Engine!FObjectPropertyTrace::Destroy() [D:\build\++UE5\Sync\Engine\Source\Runtime\Engine\Private\ObjectPropertyTrace.cpp:310]
UnrealEditor_Engine!FEngineModule::ShutdownModule() [D:\build\++UE5\Sync\Engine\Source\Runtime\Engine\Private\UnrealEngine.cpp:409]
UnrealEditor_Core!FModuleManager::UnloadModulesAtShutdown() [D:\build\++UE5\Sync\Engine\Source\Runtime\Core\Private\Modules\ModuleManager.cpp:1064]
UnrealEditor!FEngineLoop::Exit() [D:\build\++UE5\Sync\Engine\Source\Runtime\Launch\Private\LaunchEngineLoop.cpp:5181]
UnrealEditor!GuardedMain() [D:\build\++UE5\Sync\Engine\Source\Runtime\Launch\Private\Launch.cpp:202]
UnrealEditor!GuardedMainWrapper() [D:\build\++UE5\Sync\Engine\Source\Runtime\Launch\Private\Windows\LaunchWindows.cpp:123]
UnrealEditor!LaunchWindowsStartup() [D:\build\++UE5\Sync\Engine\Source\Runtime\Launch\Private\Windows\LaunchWindows.cpp:277]
UnrealEditor!WinMain() [D:\build\++UE5\Sync\Engine\Source\Runtime\Launch\Private\Windows\LaunchWindows.cpp:317]
UnrealEditor!__scrt_common_main_seh() [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288]
kernel32
ntdll
Anyone else getting a lot of hitching when using enabling vsync with 5.5?
Yeah, there has to be something up with vsync, maybe it’s a spillover effect from some of the other issues talked about above. Here’s a blank default level in 5.5 with both editor vsync and game vsync enabled, on a Windows 11 PC with nothing else running and an RTX 4070 and a 60 Hz monitor, and it can’t remain stable? Seems very similar to what I’m seeing in packaged builds too…
What build of Windows 11? I know there are a lot of issues with the new 24H2 build that’s being rolled out and it might take some time for Nvidia and Microsoft to hammer things out.
Press start+r, type winver, press enter. The build will be listed as “Version ____”
