Physics based racer pawn questions

Hi, I have been working on a racer that moves exclusively through calls to AddForce and AddTorque. Things are going pretty well and I have built a fun little racer but I have some issues and concerns.

I should start by laying out how my racer works. It is a blueprint pawn with the following component hierarchy (there’s more to it but these are the relevant components):
(Scene component) - Root
–(Static mesh component) - Physics simulation is enabled
----(Racing simulation component) - programmed in c++

The racing simulation component is coded roughly like this:

parentComponent->AddForce(gasInput * MaxGasStrength);


FVector currentLinearVelocity = parentComponent->GetPhysicsLinearVelocity();
FVector hoverForce1 = CalculateHoverForce(currentLinearVelocity , lineTraces, etc);

FVector currentLinearVelocity = parentComponent->GetPhysicsLinearVelocity();
FVector hoverForce2 = CalculateHoverForce(currentLinearVelocity , lineTraces, etc);


FVector currentAngularVelocity = parentComponent->GetPhysicsAngularVelocity();
FVector yawTorque = CalculateYawTorque(currentAngularVelocity , lineTraces, etc);


Each frame I make around 10 AddForce calls and 2 to 4 AddTorque calls.


  1. I have experimented with turning on physics sub-stepping and I am getting strange results. The racer behaves similarly for linear movement but differently for angular movement. I suspect that this might go away if I were to only call GetPhysicsLinearVelocity and GetPhysicsAngularVelocity once at the beginning of the tick and if I then applied all forces sequentially at the end of the tick. However, I tried this once without substepping enabled and the racer behaved erratically. This leads to another question.

  2. Do calls to GetPhysics…Velocity on the same tick ever produce a different value? If so, can a call to AddForce be responsible?

My gut says that the answer should be no when sub stepping is off and yes when sub-stepping is on.

I jumped into the source code of the AddForce call and noticed that it really just calls the FBodyINstance’s implementation of AddForce and that it has hard coded the bAllowSubstepping parameter to true. I’m not sure if this is relevant.

I realize I could test this but I’m afraid I may just get a false negative.

  1. Does anyone have a good way to test the consistency of my simulation when given the same player inputs? I want to test consistency across sessions where the frame-rate is stable (at 60 fps) and consistency between sessions where the framerate is low. By taking focus off of the editor I can drop the framerate to around 3 fps and things appear to behave correctly but then I can’t test with player inputs.

  2. What issues might I run into with accurately replicating racers if I decide to add networked multiplayer?

  3. I have had some weird reactions to collisions where it seems to launch my racer away from the collided object. I have double-checked that it is not due to any of the forces I am adding (I cap the magnitude of each force immediately before it is applied). At first I thought it might just be a current known/unfixed bug with landscape(I’ll try to find the link to the post that made me think this but it was dated 2014). I’m not so sure now though since I have, less frequently, encountered this when colliding with static meshes.

This is the mesh that I am testing with and its collision box:

Collision settings:

Physics settings:
Project physics settings:
I am using a physics material with friction set to 0 and reciprocity set to 0.

Please let me know if there is any more information I can provide.

Help with any of these questions and concerns would be greatly appreciated. In the meantime I will continue to try and answer my own questions and update this post with any discoveries.

  1. Regarding physics sub-stepping. Enabling sub-stepping improves accuracy and stability, but as you are calculating your own physics inputs into the system those calculations should be done on sub-step level as well. Otherwise your forces are still calculated for a delta time of rendering frame not delta time of physics update, which would be more granular with sub-stepping enabled.
    Check this thread for example of how it can be done: The Re-Inventing the Wheel Thread - Community Content, Tools and Tutorials - Unreal Engine Forums

  2. For this you can use t.maxFPS 10 console command

  3. Regarding objects being propelled by collision, from my experience the higher the mass, the more stable interactions will be and take into account that kinematic objects such as Character are treated as objects with infinite mass. Avoid intersection of collision volumes, especially if they belong to the same object.

Thank you for the advice BoredEngineer. I haven’t tried your suggestion for #1 yet but #3 works great.

As for #5 that did the trick as well. My only complaint would be that all of my units make real world sense (sizes, velocities, etc.,) except for the mass of my racer which is now huge. I can live with that though since things feel so much better now.

Hmm, are you sure that your units are right then? For example forces need to be applied as Ncm instead of Nm.
The other potential issue - taking into account that you apply forces yourself, you can get similar bug when force is applied to an object which already collides with something. Like for example rocket engine propels rocket into a wall, if rocket hits the wall and engine keeps pushing it, it can get propelled into infinity.

I’m not sure what you mean about the units. I just meant that, before, my racer was roughly the size and weight of a real life car (1600kg), and now my racer is the same size but roughly 20,000kg. As I do more testing I’m finding that I’m still running into issues when coliding with the landscape. If I turn off my hover force this is easily reproduced regardless of my mass. When I thrust forward along perfectly flat ground I will randomly get jolted. It sounds like I might be experiencing the issue you mentioned where a force is applied during a collision but I can’t reproduce it on a static mesh.

My orientation relative to the landscape seems to have an effect. If I’m going “south” the jolts are much less likely to happen. Also If I’m upside down the jolts almost never happen.

I found the post where it appears another person is having the same issue:

An Epic employee mentions it was not fixed but that was over a year ago.

Edit: This thread seems to indicate that that issue was fixed

Definitely not fixed yet. You can lessen/eliminate the jolting by making the landscape quads bigger. My guess is that the jolting is due to colliding with many quads at once.