Unreal Engine async physics tick: same feel at any FPS

If your vehicle drives differently at 30 FPS than at 144 FPS, it is almost always because its forces run once per rendered frame, so every spring, force and timer depends on how long that frame took. Unreal Engine async physics fixes that. With Tick Physics Async on, Chaos simulates physics on its own thread in steps of a fixed length, for example 60 per second, whatever the renderer is doing. Put the vehicle’s forces into that fixed step and it handles the same on a slow laptop and on a 240 Hz monitor.

I build Kart Racing Drifting Physics, a kart plugin for Unreal Engine 5, on exactly this setup. This post is what I would tell anyone moving a vehicle onto the async physics tick, from why frame-based physics drifts apart to the settings that switch it on.

Why frame-dependent forces change the handling

A lot of vehicle code starts in Event Tick: read the input, compute the forces, call Add Force. Event Tick runs once per rendered frame, and frame times change all the time. At 144 FPS a frame lasts 6.9 ms, at 30 FPS 33.3 ms, and a hitch can stretch a single frame to 100 ms or more.

Multiplying by Delta Seconds helps less than people expect. A force computed at the start of a frame stays constant for the whole frame while the body keeps moving, so the longer the frame, the longer the physics runs on an outdated force.

A worked example: one spring at three framerates

Take one suspension spring (a car or a kart has four of them). It is stiff: without damping it would swing 7 times a second. It is also moderately damped, with a damping ratio of 0.3. Press it down 10 cm and let go. Solved exactly, it overshoots its rest position by 3.7 cm and then settles.

Now the same spring in a small toy simulation. The force is computed once per frame and integrated with semi-implicit Euler, the simple method most game code uses (Glenn Fiedler’s Integration Basics explains why).

Framerate	Frame time	Bounce past rest
144 FPS	6.9 ms	3.6 cm
60 FPS	16.7 ms	3.5 cm
30 FPS	33.3 ms	11.5 cm
Exact answer		3.7 cm

At 30 FPS the same code bounces three times as far. Make the spring a little stiffer (8 swings a second) and at 30 FPS it never settles: it gains energy every frame until it throws the body away. At 60 and 144 FPS that stiffer spring still behaves.

There is no bug to find in that code. A 33 ms frame is simply too long a step for the spring, so players on a slower PC get a bouncier, floatier vehicle than the one you tuned, and one bad hitch can launch it. Timers suffer too: a boost that should end after exactly 0.5 seconds ends on the first frame after that moment, up to 33 ms late at 30 FPS.

Why UE5 physics substepping only partly helps

Unreal’s older answer is Substepping (Project Settings > Physics > Framerate). It splits each frame into equal substeps no longer than Max Substep Delta Time; in Epic’s example, a 0.05 second frame with a 0.025 second maximum becomes two substeps. The solver gets smaller steps and becomes more stable.

Your own forces don’t get smaller steps, though. Epic’s substepping page states that a force applied for one frame is applied for all N substeps of that frame. The spring force from Event Tick stays frozen for the whole frame, only now it is cut into pieces. Here is the toy model at 30 FPS again:

30 FPS with substeps	Bounce past rest
2 substeps, force computed once per frame	8.9 cm
4 substeps, force computed once per frame	9.7 cm, still 2.7 cm off after one second
2 substeps, force recomputed every substep	3.5 cm

Recomputing the force every substep fixes the spring, but that needs a per-substep callback in C++ (Giuseppe Portelli’s article on Unreal physics walks through it). The substep length also still follows the frame time. With that 0.025 second maximum, a 40 ms frame becomes two 20 ms substeps and a 30 ms frame two 15 ms ones. Glenn Fiedler calls this a semi-fixed timestep. The results stay close, but they still shift with the frame times. There is also no fixed-length step you could number and compare between machines, and networked physics depends on exactly that.

How Unreal Engine async physics works

With Tick Physics Async on, the frame no longer decides the step. Chaos runs the simulation on a separate physics thread, always in steps of Async Fixed Time Step Size seconds, and 0.016667 gives you 60 steps per second. That is only the physics rate; the game still renders at whatever FPS it gets.

The game thread and the physics thread then run side by side:

A long frame lets several physics steps run. At 30 FPS, each frame covers two 60 Hz steps.
A short frame may run none. At 144 Hz there are 2.4 frames per step, so more than half of the frames get no new physics result at all.
To keep motion smooth anyway, Unreal draws each body interpolated between two physics results, slightly in the past. The engine console variable p.AsyncInterpolationMultiplier sets how far back: 2 fixed steps by default, about 33 ms at 60 Hz.

The physics step is always 16.7 ms. At 144 Hz most frames fall between two results, so Unreal draws the body in between. At 30 FPS every frame has to run two steps.

Your code hooks in through Event Async Physics Tick in Blueprint, or by overriding AsyncPhysicsTickActor(float DeltaTime, float SimTime) in C++. It fires once before every physics step, at the physics rate rather than the frame rate. Its Delta Seconds is the step length, so with a fixed step it never changes. An actor only gets the event with Async Physics Tick Enabled on (in its Physics category, or bAsyncPhysicsTickEnabled = true in its C++ constructor).

Move every force, spring and timer of your vehicle in there and you have framerate independent physics: the spring from the table behaves like the 60 FPS row on every machine, whether the game runs at 30 FPS, 144 Hz or uncapped.

Traps in the physics step

Two threads, two copies of the body

The usual nodes, such as Add Force, Get Physics Linear Velocity or Get World Location, work on the game thread’s copy of the body by default. Called from Event Async Physics Tick, they read the interpolated game thread state, which lags behind the step you are in, and a force you add is handed over through the game thread instead of acting on the step that is running. The code looks like it works, but the vehicle feels soft or stutters.

Input crosses to the physics step, results come back and are drawn interpolated. Each side keeps its own copy of the body.

Inside the async physics tick you need functions that talk to the physics thread’s body directly. Alex Craig’s free AsyncTickPhysics plugin (MIT license) has them for Blueprint and C++: ATP_ versions of add force, add torque, get and set velocity, get transform and more. Call them only from the async tick. If a body refuses to move, its README suggests Wake All Rigid Bodies. My plugin ships a modified copy of these helpers under Alex Craig’s license, and they saved me a lot of time.

Keep game thread tools out of the physics step

Timelines, Delay, timers and values you update in Event Tick all move with the frame. One developer on the Unreal forums found that a jump driven by a Timeline inside the async tick took much longer at 15 FPS than uncapped. Count your own timers inside the async tick instead, adding its Delta Seconds every step, so the whole simulation runs on one clock.

Give every value one owner

Frame code and physics step code share variables, and the physics step can run zero, one or several times between two frames. Code that runs on the physics thread itself, such as a C++ physics callback or a plugin’s own async tick, can even read a variable while the game thread writes it. Blueprint has no locks, and developers on the forums report random hangs and crashes from exactly that. Giving every value a single writer avoids most of it:

Player input is written on the game thread and read by the physics step.
Simulation state (speeds, timers, the vehicle’s current mode) is written only by the physics step.
Anything for visuals or UI is a copy the physics step leaves behind, and the game thread only reads it.

Values that step at 60 Hz on a 144 Hz screen

Unreal interpolates the body, but not the values your own physics code produces, such as wheel positions from suspension traces, spring compression or a lean angle from the velocity. Those change once per step. On a 144 Hz screen each one holds for two or three frames and then jumps, so the wheels micro-stutter against a perfectly smooth body.

Do for those values what the engine does for the body: keep the last two step results and blend between them at the moment the engine draws the body (slightly in the past, as described above). Blend at any other moment, for example toward the newest result, and the wheels drift out of step with the body. The last section of Glenn Fiedler’s Fix Your Timestep! explains this kind of interpolation.

The camera needs no physics step values at all. Attach it to the body with a spring arm and let the engine’s interpolation do the work.

The example kart's chase camera sits on a spring arm attached to its physics body, which Unreal already draws smoothly between physics steps.

Tuned for one step size

A fixed step makes the handling independent of the framerate, but not of the step size. Tune at 60 Hz, switch to 120 Hz, and anything that acts per step (a velocity change applied every step, a number of steps you count) feels different. So pick the rate early, write your forces in terms of Delta Seconds, and test again if you ever change it.

60 Hz is a good default for vehicles. It handles stiff springs, as the table shows, and leaves CPU headroom. Each step has to finish in under 16.7 ms of real time on average, or the simulation falls behind.

Why networked physics needs a fixed step

Unreal’s networked physics (Physics Prediction, with the Resimulation replication mode) keeps a history of the physics state for every step. When a server state arrives, the client compares it with its own history “for the corresponding physics frame”, in the words of Epic’s Networked Physics Overview. If they differ, the client rewinds, corrects and simulates again up to the current step.

That only works if frame 1200 means the same moment, with the same step length, on the server and on every client, and a fixed async step gives you exactly that. Alvaro Jover-Alvarez’s guide to networked physics in UE 5.8 lists Tick Physics Async with a fixed step size right next to Enable Physics Prediction, which “synchronizes the client and server physics frames”.

Multiplayer adds one more trap. Event Async Physics Tick still fires, but it does not run again when the engine replays a correction. Anything your vehicle does only in that event is missing from the replay, so the replayed vehicle ends up somewhere the server never was. Plan for this early; I cover it in what makes replicated vehicle physics hard.

How to switch it on

Where	Setting	Value
Project Settings > Physics > Framerate	Tick Physics Async	On
Project Settings > Physics > Framerate	Async Fixed Time Step Size	`0.016667` (1/60 s, so 60 Hz)
Your actor, Physics category	Async Physics Tick Enabled	On, for every actor that uses Event Async Physics Tick
Project Settings > Physics > Replication > Physics Prediction	Enable Physics Prediction	On, only for networked physics

In Config/DefaultEngine.ini the first two settings look like this:

[/Script/Engine.PhysicsSettings]
bTickPhysicsAsync=True
AsyncFixedTimeStepSize=0.016667

A minimal C++ actor that uses the async physics tick:

AMyVehicle::AMyVehicle()
{
	bAsyncPhysicsTickEnabled = true;
}

void AMyVehicle::AsyncPhysicsTickActor(float DeltaTime, float SimTime)
{
	// Super fires the Blueprint Event Async Physics Tick.
	Super::AsyncPhysicsTickActor(DeltaTime, SimTime);

	// DeltaTime is the fixed step. Compute and apply this step's forces here,
	// with physics thread accessors such as the ATP_ functions.
}

A short checklist

Tick Physics Async is on, with a step size you chose on purpose (60 Hz is a good start).
Every force, spring and gameplay timer of the vehicle runs in Event Async Physics Tick and uses its Delta Seconds.
Inside the async tick: physics thread accessors only, no game thread nodes, Timelines or Delay.
Every value shared between the threads has exactly one writer.
Visual values are blended between the last two steps, and the camera hangs on a spring arm on the body.
Test with the console commands t.MaxFPS 30, t.MaxFPS 144 and t.MaxFPS 0 (uncapped): the same jump, stop and turn should look and measure the same each time.
For multiplayer, Enable Physics Prediction is on, and no vehicle state lives only in Event Async Physics Tick.

Skip the hard part

If you are making a kart racer, Kart Racing Drifting Physics is built on exactly this setup:

The whole kart (acceleration, turning, suspension, hops, drifts and boosts) simulates in the fixed 60 Hz async step, so it feels the same at any framerate.
The kart’s C++ class switches on its own async physics tick, and the example project comes with the physics settings already in place.
The upcoming version 1.1 blends the Blueprint values for wheels, lean and the ground below between physics steps, so they stay smooth on 120 and 144 Hz screens. Coming in 1.1
The same version adds multiplayer on Unreal’s networked physics (Unreal Engine 5.7). When the server corrects your kart, the replay includes its drift and boost state. Coming in 1.1

Drive it in the free Windows demo (no Unreal Engine needed), then read Getting started and Visual smoothing. More on the blog: how arcade kart drifting works and arcade kart physics vs Chaos Vehicles.

Unreal Engine async physics: why a fixed 60 Hz tick makes a vehicle feel the same at any FPS