Fixed Timestep

Enabling

This is a two-stage opt-in. The feature is compiled out by default.

The compile-time gate exists because the feature changes hot paths in the physics scene, the substep task and the animation physics blend. Projects that do not need determinism should not pay for the extra branches and the double-buffered transform storage.

Console variables

All of these exist only when VITE_PHYSX_FIXED_TIMESTEP is compiled in.

How it works

The implementation maintains a time accumulator. Each game tick adds the frame's delta to the accumulator, then runs as many whole fixed steps as fit. The remainder stays in the accumulator for next frame.

Because a fast frame may fit zero fixed steps and a slow frame may fit several, the system has to handle two things carefully.

Buffers are not rotated on frames with no physics step. Standard substepping swaps the physics target buffers unconditionally. In fixed-step mode the swap is deferred until a step actually happens, which preserves one-shot forces, kinematic targets and custom physics callbacks that were queued during a frame that did not step. Without this, an impulse applied on a zero-step frame would be silently discarded.

Results are only fetched when a step occurred. fetchResults is skipped on frames with no simulation, avoiding redundant work and stale transform reads.

Overload handling

If the game cannot keep up — a long hitch, or a physics load too heavy for the fixed rate — the accumulator grows faster than it drains. Left alone this becomes a death spiral: each frame takes longer, which queues more steps, which makes the next frame longer still.

Two limits prevent that. MaxTimesteps caps steps per tick. Overload beyond that cap accumulates against MaxCumulativeExtraSteps, and when that budget is exhausted, LimitType decides what happens:

Clamping means physics runs in slow motion under sustained overload but remains bit-identical for a given step sequence. Falling back to variable substeps keeps things real-time but sacrifices determinism for the frames where it engages.

Render interpolation

Fixed stepping at 60 Hz while rendering at 120 fps would show each physics state twice without interpolation, producing visible judder. The system stores the two most recent completed transforms per body (PreviousPhysicsTransform and LatestPhysicsTransform) and blends between them using the accumulator's fractional remainder.

InterpolationMode controls how widely this applies:

• 0 Disabled. No interpolation. Bodies snap to the latest physics state. Cheapest, and correct if your render rate matches your fixed step rate exactly.

• 1 Per component (default). Interpolates only bodies whose bInterpolateWhenSubStepping flag is set. The engine clears this flag for bodies where interpolation cannot be observed — kinematic query-only bodies, for instance — so this mode gets the visual benefit without paying for bodies that do not need it.

• 2 Always. Interpolates every body unconditionally.

Interpolation applies to both rigid bodies and the skeletal mesh physics blend, so ragdolls and physics-blended animation stay smooth.

Choosing a step rate

DeltaTime is the central tuning decision.

Physics cost scales linearly with step rate, so 120 Hz stepping costs about twice 60 Hz. Pick the lowest rate that keeps your fastest-moving simulated bodies stable, and use CCD rather than a higher step rate to solve isolated tunnelling problems.

When to use this

Use fixed timestep for deterministic replays, networked physics where client and server must agree, automated tests that assert on physics outcomes, and any game where identical input must produce identical results across machines.

Do not use it for projects with no determinism requirement. The default variable-step path is cheaper and the compile-time switch defaults to off for that reason.

See also

• PhysX

• Compile-Time Switches

• Instanced Physics Subsystem

• Profiling