This question was created in reference to: [Character Movement CPU [Content removed]
We are trying to optimize our Character Movement Component’s CPU usage with suggestions in the referenced article above.
We’ve already achieved some gains by reducing the frequency of calls to SmoothClientPosition_UpdateVisuals() and disabling GenerateOverlapEvents flags on proxies, but the code provided to override SimulateMovement() appears to be too dated for UE5.
Is there an applicable approach for UE 5.4 or anything that can be salvaged from the article’s implementation for more recent versions of the engine?
Hello there, it’s not possible to get the thoughts of the person who wrote that article since they’re no longer working at Epic - but I’ll provide my thoughts after reading the article and looking at the latest state of SimulateMovement().
Do I understand correctly that you’re asking about the idea of not forward predicting simulated proxies to save costs on those? Basically the logic inside the following code block in CMC::SimulateMovement, which handles the forward prediction and indeed does collision checks and floor penetration resolution that’s costly:
// May only need to simulate forward on frames where we haven't just received a new position update. if (!bHandledNetUpdate || !bNetworkSkipProxyPredictionOnNetUpdate || !CharacterMovementCVars::NetEnableSkipProxyPredictionOnNetUpdate) { ... }
Or the ground penetration detection only:
// find floor and check if falling if (IsMovingOnGround() || MovementMode == MOVE_Falling) { ... }
It appears to be not neatly possible to intentionally skip that code block, because bHandledNetUpdate is a local variable and that alone is enough to enter that code block. You will have to make an engine modification or override and copy the whole function without calling the Super:: function.
I’ll ask the character movement system owner whether we would consider exposing a game project-controllable method to contextually disable (parts of) forward prediction. But since those modifications are easily made with a one-liner engine code change, I expect this will be very low priority to work on.
Do keep in mind that if you disable all forward prediction, if a player’s game client stops sending movement updates due to their bad connection or game freeze, their character will appear to be frozen in the air on other clients. Alternatively if you extrapolate movement but not floor collision checking, they may forever stay in the wrong state (MOVE_Falling even if they hit the ground) edited to add: until the owning game client sends a movement update again that prompts the server to send the latest position + mode to other clients. For a more nuanced solution like only disabling forward prediction while on the ground, I think you will need to make considerable engine code changes to UCharacterMovementComponent::SimulateMovement.
Glad to provide those thoughts. I’ll close this case.
Thank you for the response.
You are correct in regards to us trying to avoid forward predicting simulated proxies to save costs. Given the caveats you pointed out and our release timeline, it’s too risky to make considerable engine changes.
Our overall goal with this post was to glean for more quick performance gains from the referenced article, but it’s understandable if there are none left due to engine updates since then. If time permits, we may consider revisiting the suggested approach in the future.