Performance / Frame rate bottlenecked by game thread

[Dr_Chat]

The game is running rather slowly on my machine, so I figure I'll make a thread to document my adventures in profiling and what I find.

Scenario

While playing on a 64 player game on Daybreak, I noticed that I was running at 48fps. This is constant no matter what my graphics settings are set at.
I ran through some basic profiling guides from Epic. Doing so reveals that RenX is bottlenecked on game logic rather than graphics.

As seen in the following picture, the FrameTime and GameEngine tick lines are aligned.

 

Drilling down with another tool reveals that we're wasting time ticking a bunch of pawns, and notably all of these pawns were not visible when the trace was taken (I was repairing inside the Obelisk):

 

For vehicle pawns, this is likely from updating vehicle treads and other graphical effects without checking "`TimeSince(LastRenderTime)" (if the object was visible within the last frame).
Ditto for player pawns (Rx_Pawn), where the server/client logic should be split more carefully to avoid performing updates on invisible objects. Most importantly, a lot of time is spent calculating movement for these objects (Move Actor Time).

 

Actor relevancy
Epic also details actor relevancy here. Notably, it looks like RenX is configured to indicate that all actors are always relevant, which bypasses UDK engine optimizations.
See bVehiclesAlwaysRelevant and bInfantryAlwaysRelevant in DefaultRenegadeX.ini.

This causes all actors to always be replicated to all clients, and all clients will subsequently tick every character and vehicle present in the match.

 

GameEngine Tick <self>
There's also a ton of time attributed to GameEngine tick itself. Using a kernel-mode profiler, it looks like the game is hammering on the GetPerformanceInfo syscall in the main loop, wasting about a quarter to a half of its processing time in this function.

Fortunately, Microsoft provides another function called GlobalMemoryStatusEx. This provides the same information that the game is interested in, and it's infinitely faster.
It's trivial to patch UDK.exe to call this function instead, and that shaves off roughly 6mspf.

Edited January 1, 2021 by Dr_Chat

[yosh56]

Most of this is known (not to downplay it). There was a push to utilize the native relevancy checks in UDK though 2 issues came of it: 

 

A) You can tell it was built around something like Unreal Tournament, with tight corridors and plenty of walls to easily tell if people were visible to one another, as opposed to RenX that has rather large fields with comparatively huge lines of sight, but also obstacles as thin as light poles or small rocks that send false positives of rendering. (A notable issue we had was people being invisible through something as simple as a fence).

B) Not having access to any native code means we're kind of stuck with Epic's implementation of Actor relevancy. A MAJOR issue there is it wasn't built to have 64 Pawns + vehicles. That leads to the server getting saturated with traces (or so I've been told). 

 

There are some other possible alternatives; there just hasn't been a whole lot of time to study and test them yet. Basically it's just getting around all of the native calls, which requires some finagling. 

[Dr_Chat]

Hm... perhaps visibility issues caused by transparent or thin objects is a mapping issue? Like they should be marked as transparent for line-of-sight tests in the editor?

Saturating the server with line-of-sight traces could be a problem as well. Is there any way to configure the settings so that they're done asynchronously?