I have a project in 5.2.1 which runs at a pretty stable 55-60FPS in Standalone currently.
I open a copy of the project in 5.3.0 (and 5.3.1, and 5.3.2, it isn’t fixed still) and the frame rate absolutely tanks, to below 30FPS, whenever I start moving my character in a new direction during Standalone play. After some fiddling around in my AnimBP, I’ve realized that this result can be eliminated if I take my idle-run graph and make it bypass a blend-poses-by-bool node that’s used to flip between the run and skid-stop blendspaces depending on whether the player is pressing a move input.
The blend poses by bool is on the fast path (all the nodes in the chart are); the only thing that I can figure is that the blend poses by bool node uses interp times, and perhaps there’s something really screwy going on with the interpolation phase? It seems like once it’s finished interpolating fully, the framerate stabilizes, but any time that bool is flipped, the framerate hits the gutter.
I tried reducing the complexity of the setup to isolate the issue: if I used a single 2D blendspace, I never dipped more than 5FPS; as soon as I added a single blend-poses-by-bool after this blendspace (the second node of which is just a single looping animation, no additional blendspaces or complexity), I started seeing temporary 20-30 FPS drops whenever that bool was flipped. I have no idea why this should be happening, am I the only one seeing this? Is this unique to my project?
I’ve done some more digging and while I don’t know if I’m closer to a solution, I DO know that the problem disappears when in PIE. Now, I know PIE profiling is not a good idea, it tends to overreport usage, but in this case, it UNDERreports it. I get better game thread frame time in PIE than I do in Standalone, and the dips that occur when executing AnimBP logic do not seem to crop up.
I should note that I have isolated the cost of this to the game thread, 100%… currently trying to figure out how to use Unreal Insights with a standalone session to see if I can figure out the issue, it’s far more complicated than the old profiling tools but I imagine more robust. But I am beginning to suspect the issue has to do with how worker threads are allocated or utilized in Standalone for 5.3 because of the fact that standalone runs its own process(es), and the fact that the biggest thing that AnimBP optimization/fast path does is hand off animation calculation to a bunch of worker threads. If 5.3 Standalone doesn’t properly allocate or manage these worker threads, maybe that explains it?
I’ve noticed in testing that I get similar slowdown results when applying additives as well, not just blending poses. It does seem like there’s some sort of issue when the game is trying to simultaneously process many animations at once, which goes away once it “stabilizes” on a single blend state.
You can see here the evaluation time is typically stable/low for all of the relevant animation poses in this graph. What sets off the slowdown is any time I go from NOT pressing the movement input, to pressing it, or vice versa. Almost instantaneously, the evaluation costs for both the RunDirection and IdleSkid blends quadruple, due to the blendspaces evaluating multiple animations simultaneously to find the pose. In addition, this duration is also a moment when the blend by bool causes both spaces to require evaluation. These two things combined mean that any time I start moving, the character goes from evaluating one animation to about 8 for a brief period of time, which coincides with the extreme slowdown I see.
Now for contrast, here’s what the SAME inputs, evaluated on the SAME mesh in the SAME project with the SAME animations and SAME AnimBP, looks like for 5.2:
Why this shows “SkeletalMesh” rather than “CharacterMesh0” I can’t say, and I also can’t say why it shows things broken down as “BlendSpace” rather than naming the asset in question. Perhaps all that additional profiling detail being available is the cause of the slowdown? All I know is that evaluating the ENTIRETY of the SkeletalMeshComponent takes less time than what it reports for evaluating a single blendspace.
In frustration over my inability to diagnose this issue and also the fact that it only occurs in standalone, not PIE, I caved and did a complete packaged build of my game (development build). In the packaged build, the issue went away completely. So this is evidently some sort of issue related to standalone ONLY and doesn’t affect the finished game. It just renders standalone unusable
