I’ve ran into an issue with movement on the character movement component that seems to be showing signs of not performing frame rate independently. This issue has NOT been exclusive to multiplayer, and was actually first noticed in single player on a standalone build.
Unfortunately, as I was trying to debug the issue, I simplified a lot of my project to narrow down what might be causing this, and this made it more optimized in terms of FPS, so it’s a slight bit harder to notice in this build than it was before. So in turn, I sped up the movement controller, as this makes things more noticable again, and displays some other issues.
Since I’m using a simplified template, this should confirm the issue being related to the character movement components. Here’s a screenshot of the movement blueprints:
Here’s what I tested and the results, including some videos trying to show the issues in the order I discovered it:
First discovered jitteriness as I moved around in a single player, standalone build, I had never noticed it in the editor window earlier. Was at first unsure if it was a problem exclusive to standalone. - Video: Issue Example 1 - YouTube
Jitteriness can be noticed when moving below the platform. Once past the platform, stabilizes. I display this twice in the video.
Then I wander around a bit, having only minor issues, until moving towards the platform again, and showing same jittering when going below the platform.
I tested it next in the editor window. From a smaller sized editor window it either was not perceivable, or wasn’t happening, with frame rate solid at 120fps.
I tested it with a full screen editor window, which does not show FPS values (I do not know how to enable them here). But it has the same exact results as the video from #1.
I had toyed around in multiplayer builds earlier and hadn’t noticed this issue. I was curious if it would be happening there now. This is where the issues with frame rate became more obvious. - Video: Example 4 - YouTube
With the editor window as server, and a client window default (same) size, on the server window FPS was around 120 in the open, and 80-90 facing the platform. When at 120FPS it seems to run perfectly. When facing the platform, the jitteriness is noticeable.
I switched to the client window. ~100FPS in open, 70 facing platform. Jitteriness noticeable at all times.
I maximized the client window. ~70FPS in open, 40 facing platform. Jitteriness more violent.
Minimized client window, now the server window is running similar to the client. ~70/40 FPS. Jitteriness more violent on server as well.
Since there seemed to be a relation between frame rate and the jitteriness, I decided to try to play with t.maxfps set to 60. - Video: Example5 - YouTube
With max FPS set to 60, and the server never dropping below 60, no jitteriness at all.
With the client, same result. Never dropping below 60, no jitteriness at all.
I now manipulated the size of the windows. Leaving one at 60, and one below 60.- Video: Example 6a - YouTube
As long as the server stays above 60FPS, it runs perfectly. If it goes below 60 even a little bit, it begins jittering more violently.
As long as client stays above 60FPS, it runs perfectly. If it goes below, it begins jittering more violently.
I decided to try to set max fps to 50
It is now performing well at 50, and jittery below 50.
Result: it seems that the issue is not related to single player nor multiplayer, client nor server, as it occurs in any of them. Testing seems to indicate that the level that t.MaxFPS is set at is the “ideal” FPS for the project. Any time either the server OR the client go below this, the movement is becoming jittery?
I don’t understand these results… isn’t the character movement component supposed to be frame rate independent? Based on these results, it seems that isn’t the case?
Can anyone explain the behavior I’m seeing here, and/or have a solution for how to resolve this?
Server tick rate default is 60Hz. If your game has large maps and/or heavy processing you’ll want to lower the server tick and the character movement component replication rate.
To find the proper tickrate use t.maxfps in PIE. Once you get a stable rate set it in the Engine.ini
[/Script/OnlineSubsystemUtils.IpNetDriver]
NetServerMaxTickRate=30
Open your character class and set the “Net Update Frequency” under Character Movement component -> Replication. Value should be equal to or less than the servers tick.
Try to enable Update Rate Optimisations and set Net Update Frequency to 60.
However, I think you have different problem here and it’s camera.
Do you have any code in tick for camera? Try to disable it and test it. Also, attach your spring arm / camera to mesh (if its not already attached).
Regarding the camera, absolutely no code in the camera at all. Spring arm/camera are currently attached to the capsule component. I could try it on the mesh instead!
It applies to both. In SP you are essentially the server and the client. Any calculations the server would normally do is being done by your client. In all the test you ran you where the server and the client (same system running both). For true MP testing you need to have the host (server) running on a different physical machine.
Try occlusion testing. Create a large ceiling out of a single cube mesh and place it under the large platform. Your stuttering only happens at specific points under the platform which I assume is a single mesh. You could also create a wall with an opening to pass through out of two cube meshes to occlude distant objects/components.
Interesting, I wondered if that may be the case but I hadn’t known that was the case for single player!
The platform isn’t a single mesh, it’s just a bundle of different cubes. Nothing that should be too intensive. It does seem to happen at specific points under it, but I attributed that to frame rate issues rather than related to the mesh itself.
I am now thinking it might be the regular pauses are related to the FPS and the frequency of the pawns rotation. I played around with the t.MaxFPS setting and seem to have made it much less noticeable.
I had not, because the level itself isn’t too complex, and the framerate is still pretty high without 2 windows/clients open. Framerate doesn’t seem to be hitting such a low point that problems should be arising from that.
Also, since frame rate being low seems to be the deciding factor (even when not facing the level, with 2 windows open, the issue still happens) I don’t get the impression that it’s from the level.
Might not hurt to test, I just haven’t prioritized it for these reasons. I should get a chance to work on the suggestions a bit over the weekend and I’ll post results!
That does sound very similar, and since I’m also using a camera/spring arm, it may be the same issue!
Well at least this is a bit of relief as I’m not the only one this is happening to. I’ll make sure to post results to see if I could get things resolved!
Try to remove all materials from meshes and test it.
Have you tried to test without platform above?
Also, remove material from landscape/floor and set landscape position to 0,0,0
EDIT: set fixed FOV for your camera to 90 (also test with various values), do not change FOV or spring arm length while moving.
Try with camera lag enabled too. It’s hard to debug this kind of problem so you need to try various solutions.
A little bit late, but for people that face this problem in the future, the problem is the camera lag in the spring arm. I removed the jittering by disabling the camera lag. you can keepthe rotation lag.
