Different physics behavior on server and client when tested on "weak" PC?

[Hackmet]

Hey guys,

Iam currently working on a GTA2-type game (see link in my signature) and am currently setting up my car behavior for multiplayer. In a nutshell, my CarMeshes are simply pushed around by AddForce and turned by AddTorque (with additional force for grip and rolling resistance). These physics actions are run on the server and then replicated to the clients.
When Iam testing it it seems to work generally quiiiiiite well… However, I have the dull feeling that the car response is slightly more “slow” or “sluggish”, when Iam on the client, while simulating two players. However, when I print to screen the parameters that I see critical for car handling (i.e. damping, applied forces/torques) I cannot see any differences. Argh, it is a bit difficult to describe, as I didn’t find a way to put the experienced car response in numbers^^ But for instance, I have the feeling that it is easier for the server to turn the car 180 ° on one street as for the client…

My question: Is it possible that the differences in physics response are due to computational power limits of my PC? It’s not superslow but also not the best one: AMD FX6300 (6x3.5 GHz), 8 GB RAM, AMD R7 370. I also tested with “dedicated server” enabled and only one player for having to render only one game window but there it seems to be the same or at least a similar issue…
What I forgot to try (have to do this whenever I find time again, real life is relatively intense at the moment^^) is to decrease graphics settings for a better performance…

Iam grateful for any thoughts/comments/experiences on that topic

Best wishes,
Hackmet

[BoredEngineer]

Physics simulation relies heavily on stability of delta time. If you use “vanilla” approach of calling AddForce/AddTorque functions on tick then whatever values you tune to get correct behavior won’t be correct anymore if game is running at different FPS. The remedy is to enable physics sub-stepping, use Physics-sub-step event instead of Tick for physics calculations, AddForce and AddTorque functions with Sub-step parameter (c++) and getTransform getLocation that work directly with physics bodies. And to limit maximum FPS as well.
Had to go throw this myself - basis of MMT code is concern with this, link is in signature.

[BoredEngineer]

Another possible issue is how your controls are handled. They have to take into account delta time. Like if pressing left/right rotates a steering wheel then amount of rotation should be proportional to delta time, otherwise you get issue where with low FPS your controls become less sensitive than at high FPS.

[jonimake]

Physics simulation is a form of numerical integration and it’s always an approximation and the values always depend on the number of data points how sparse they are (data points in this case are the ticks).

If you want to read more: Integration Basics | Gaffer On Games

[Hackmet]

@BoredEngineer

Physics simulation relies heavily on stability of delta time. If you use “vanilla” approach of calling AddForce/AddTorque functions on tick then whatever values you tune to get correct behavior won’t be correct anymore if game is running at different FPS. The remedy is to enable physics sub-stepping, use Physics-sub-step event instead of Tick for physics calculations, AddForce and AddTorque functions with Sub-step parameter (c++) and getTransform getLocation that work directly with physics bodies. And to limit maximum FPS as well.
Had to go throw this myself - basis of MMT code is concern with this, link is in signature.

Thanks for your reply! I will have a look if the sub-stepping is giving any advantage, if I cannot handle the performance issues…

@BoredEngineer

Another possible issue is how your controls are handled. They have to take into account delta time. Like if pressing left/right rotates a steering wheel then amount of rotation should be proportional to delta time, otherwise you get issue where with low FPS your controls become less sensitive than at high FPS.

Sounds legit! However, Iam not sure if it applies in my case. My inputs only take the axis value (which is -1, 0 or 1) and use that to scale the applied force, if any force needs to be applied.

[BoredEngineer]

@Hackmet

Sounds legit! However, Iam not sure if it applies in my case. My inputs only take the axis value (which is -1, 0 or 1) and use that to scale the applied force, if any force needs to be applied.

That could be the source of your problem. Lets say you have two PCs, one runs game at 30fps and another at 60fps. Player holds button for exactly two seconds. First PC will receive 30x1x2=60 input units and second PC will receive 60x1x2 = 120 input units. 1 here corresponds to a maximum of input axis value.
If you add scaling by delta time then on first PC, idealistic delta time will be 1/30 = 0.0333 sec and on second one 1/60 = 0.0166
Now if we take delta time into account, first PC will produce 30 x 1 x 2 x 0.0333 = 1.999 control units and second one 60 x 1 x 2 x 0.0166 = 1.999 control units, meaning that scaling your input by delta time makes it less dependent on FPS.

Worth noting that axis input (unlike button presses) is an even that happens on each frame, not only when controls are active (it just sends 0 when axis input controls are not pressed). Most likely they are tied to a tick event, otherwise there would be a setting somewhere where we can set frequency of axis input updates to be independent from fps.

[Hackmet]

Hey, of course, that makes absolutely sense! I have never seen it that way but of course it comes down to how often the force is applied (as a consequence of the fps).
Thanks for the hint - i applied the correction that you proposed and it seems to work smoothly Plus, I decided to format and reset my PC… I didn’t do that for 3-4 years and it became considerably slow^^