Recording Chaos physics in Unreal? Lock the frame rate first

I build Physics Exporter, an Unreal Engine 5.8 editor plugin that records a running Chaos simulation with Take Recorder and exports it as animated USD, with GLB and FBX as options. This post is about one thing I learned building it, and it applies to anyone who records physics in Unreal.

The short version: if you record physics while the editor is running slower than real time, you can lose simulated time without any warning. The fix is one project setting, plus one Take Recorder setting.

The symptom: the take plays back slow

Nothing crashes and nothing shows in the log. You record rigid bodies falling onto a floor, play it back, and something feels off. Objects hang in the air and impacts land late. No single frame looks broken, but the whole take plays back in slow motion.

In my test, a take 5.02 seconds long held only 0.40 seconds of fall. The simulation had advanced less than a tenth of the time the take covers, in a scene that was not especially heavy.

Why: frame-coupled physics only simulates the time a frame allows

By default, Chaos steps along with the game frame: each frame hands physics a delta time and physics advances by that much. With short, even frames, this works fine.

Recording makes frames long. A heavy scene, plus the overhead of capturing transforms every frame, can push each frame past real time. Unreal does not let the physics step grow without limit. The Physics project settings document Max Physics Delta Time this way:

"This is the maximum time step that a simulation can take. If this is smaller than the tick of the engine, physics will move artificially slow in order to increase stability."

That is the whole problem in one sentence. When a frame takes longer than the physics step is allowed to cover, the extra time is not carried forward. It is dropped. Wall-clock time passes, the recorder keeps sampling, but the simulation advanced less than it should have. Add that up over a few hundred slow frames and you get my 5.02-second take with only 0.40 seconds of fall in it.

Substepping does not rescue you here. Epic's sub-stepping page describes it as taking "the total frame time" and dividing it into sub-steps, with Max Substeps capping how many. It makes each frame more stable. It does not create the time a frame never handed over. The same page notes that Max Physics Delta Time "limits how long a physics step is permitted to take."

The fix: use a fixed frame rate while capturing

Stop letting wall-clock time decide how far physics moves. In Project Settings > Engine > General Settings > Framerate, turn on Use Fixed Frame Rate ("Specifies whether to use a fixed framerate") and set Fixed Frame Rate ("The fixed framerate to use").

With a fixed frame rate, every rendered frame advances the world by exactly one fixed step, no matter how long that frame took to compute. Match it to the frame rate your take is recorded at.

There is one more clock to tame. Take Recorder stamps each sample with the timecode provider's reading, and by default that is a wall clock. So even with a fixed frame rate, a slow capture can come out stretched to real time: in one of my tests, 10 seconds of simulation landed in a 20.4-second take. Turn off Take Recorder's Start At Current Timecode for the capture, or use a timecode provider that counts engine frames, and each sample lines up with exactly one physics step.

The trade-off is the point. A heavy scene now records slower than real time: a five-second fall might take fifteen seconds to capture. That is fine. A slow capture is a correct capture. It takes longer to record, but no simulated time goes missing. Once I switched, the objects fell at full speed and landed on time.

Turn the setting off again when you are done. You do not want a fixed frame rate during normal editing, and Epic's own XR guidance, for example, recommends disabling it for VR work.

Unreal also documents an async physics path, Tick Physics Async with Async Fixed Time Step Size, which runs physics on its own thread at a fixed step. Epic marks both as experimental ("Certain functionality might not work correctly"). For recording, the fixed frame rate is the simpler answer.

Two more things that bit me

Take Recorder's automatic starts and stops. Take Recorder has a Countdown setting that waits a number of seconds before recording begins, and a Stop at Playback End setting that ends the take when the sequence reaches its end time. Both are useful for performance capture. For physics, the simulation may already be running during the countdown, and an automatic stop can cut the take off before the action finishes. I set the countdown to zero, start the simulation and the recording together, and stop the take myself.

Actors driven twice. If a physics actor is placed in the level and is also bound in a Level Sequence that plays during the capture, both systems try to move it. In one scene the sequence reset the balls every frame, so each step they fell 0.26 cm from rest, which is g times dt squared. The motion looked like physics but was not. Anything you want Chaos to simulate should not also be animated by a sequence during the take.

Checklist for recording physics in Unreal

1. Enable Use Fixed Frame Rate and set Fixed Frame Rate before you record.
2. Record Take Recorder at that same frame rate, and turn off Start At Current Timecode (or use a frame-based timecode provider), so one sample equals one physics step.
3. Expect the capture to run slower than real time on heavy scenes. Do not "fix" that.
4. Set the Take Recorder Countdown to zero, and check whether Stop at Playback End will end the take early.
5. Make sure no simulated actor is also bound in a Level Sequence that plays during the capture.
6. Check the result against a known value: a drop height and fall time, or a landing frame you can compute.
7. Turn the fixed frame rate back off when you are done recording.

Further reading

• Take Recorder in Unreal Engine
• General Engine Settings in the Unreal Engine Project Settings
• Physics Settings in the Unreal Engine Project Settings
• Physics Sub-Stepping in Unreal Engine
• XR Best Practices in Unreal Engine