Unity: physics and the fixed timestep

Rendering runs as fast as the machine allows. Physics does not. Unity steps the physics simulation on a fixed timestep, 0.02 seconds by default, which is 50 steps per second, set under Edit > Project Settings > Time > Fixed Timestep.

The reason is stability. A physics solver integrates forces over a time slice, and its accuracy depends on that slice being small and predictable. Feed it a variable frame time and identical situations resolve differently on different hardware: a stack of crates that settles on a desktop explodes on a phone that hitched for 200 milliseconds.

So Unity decouples them. However long the frame took, physics advances in uniform 0.02s bites. If a frame took 0.05s, the engine runs the step twice and carries the remainder. If a frame took 0.008s, physics may not step at all.

Everything else in this lesson follows from that one decision.

Two components, constantly confused.

• A Collider is a shape: box, sphere, capsule, mesh. It defines what space is solid. On its own it is static geometry, walls and floors that never move.
• A Rigidbody makes an object dynamic: it gains mass, gravity, velocity, and is moved by the solver.

Collider alone means immovable scenery. Collider plus Rigidbody means a thing that falls and gets pushed. Rigidbody with no Collider means it falls through everything, because nothing gives it a shape to collide with.

A collider marked Is Trigger stops being solid and becomes a detector: things pass through it and you get OnTriggerEnter instead of OnCollisionEnter. That is how checkpoints and pickup zones work.

One performance rule up front: never move a static collider. Unity optimizes on the assumption they hold still, and shifting one forces an expensive rebuild of its data. If it must move, give it a Rigidbody marked kinematic.

The most common physics bug: an object has a Rigidbody, and you move it by writing transform.position. That teleports it. It skips the solver entirely, so it passes through walls, arrives with no velocity, and produces no believable collision.

Once something has a Rigidbody, the Rigidbody owns its position.

private Rigidbody rb;
private Vector3 input;

private void Awake() => rb = GetComponent<Rigidbody>();

private void Update()        // read input on the frame clock
    => input = new Vector3(Input.GetAxis("Horizontal"), 0f, Input.GetAxis("Vertical"));

private void FixedUpdate()   // act on the physics clock
{
    rb.AddForce(input * 20f);            // accelerate
    // rb.MovePosition(rb.position + v); // kinematic-style, still swept
    // transform.position += v;          // WRONG: teleports past walls
}

Note the split: input is polled in Update because a key press lives for one frame, then applied in FixedUpdate because that is where physics listens. AddForce respects mass; MovePosition moves deliberately but still sweeps for collisions.

Physics updates 50 times a second. Your monitor may draw 144. So for most frames, the object has not moved since the last physics step, and you render it in a stale position. The result is subtle stutter, most visible on the object the camera follows.

The fix is one dropdown. Set the Rigidbody's Interpolate field:

• None: render exactly where physics left it. Correct, and visibly steppy above 50fps.
• Interpolate: smooth between the previous two physics positions. Smooth, at the cost of showing a position one physics step behind.
• Extrapolate: predict ahead from current velocity. No lag, but it guesses, so it visibly overshoots on impacts.

The practical rule: turn Interpolate on for the player and anything the camera watches closely, and leave everything else on None. It costs nothing in gameplay terms, since it changes only what you draw, never what the solver computes. Enabling it on hundreds of objects is wasted work.

A bullet travelling 100 metres per second moves 2 metres per physics step. If the wall is 0.2m thick, the bullet is in front of it at one step and behind it at the next. The solver only tests at discrete moments, so it never saw a collision. The bullet passes through the wall. This is tunneling.

The Rigidbody's Collision Detection mode decides how hard the engine looks:

• Discrete: test at each step's position. Cheapest, and tunnels on fast objects. The default.
• Continuous: sweep the shape along its path against static colliders.
• Continuous Dynamic: sweep against moving colliders too. Most expensive.
• Continuous Speculative: cheaper sweeping approach, also works for rotation.

Set Continuous Dynamic on the fast object itself, not on everything in the level. Sweeping is real CPU work, and turning it on globally is a classic way to halve your frame rate for no benefit.

Cheap alternative for projectiles: skip Rigidbodies entirely and Physics.Raycast along the path each step.

Contacts arrive as callbacks, fired after the solver has resolved the step, so the data describes an outcome, not a prediction.

private void OnCollisionEnter(Collision c)   // solid contact
{
    if (c.relativeVelocity.magnitude > 5f) PlayCrash();
    Debug.Log(c.contacts[0].point);
}

private void OnTriggerEnter(Collider other)  // passed through a trigger
{
    if (other.CompareTag("Player")) Collect();
}

OnCollisionEnter gives you a Collision with contact points and impact velocity. OnTriggerEnter gives you only the other Collider. Use CompareTag rather than other.tag == "Player", which allocates a string.

For a pair to report anything, at least one of them needs a Rigidbody. Two static colliders touching produce silence, which is a very common cause of "my trigger does not fire".

The scaling tool is the layer collision matrix (Project Settings > Physics). Untick pairs that can never interact and the engine stops testing them at all. Bullets that only ever hit enemies and walls should not be tested against every pickup in the level.

Physics gets blamed for frame drops it did not cause. The real costs are specific.

The timestep is a tempting dial and a dangerous one. Halving it to 0.01 doubles physics work per second. Worse, if a step takes longer than the timestep, the engine tries to catch up by running more steps, which takes longer still. That feedback loop is the death spiral, and Maximum Allowed Timestep exists to cap it: past that budget physics simply falls behind in slow motion rather than freezing the game.

A rigidbody simulation is the right answer for tumbling debris, stacked crates, vehicles, and ragdolls. It is often the wrong answer for a player character.

Players expect precise, responsive, slightly unrealistic movement: instant stops, air control, no sliding on slopes. A Rigidbody gives you momentum and friction fighting exactly those expectations, which is why so much time is lost tuning drag to stop a character skating. Unity ships CharacterController for this: it sweeps and collides, but it is not simulated, so you move it directly and it does what you say.

The honest rule: use physics where emergent behavior is the point, and hand-authored motion where feel is the point. Many shipped games use a CharacterController for the player and Rigidbodies for everything they knock over.

And a determinism warning: Unity's physics is not deterministic across platforms or even reliably across runs. Never build lockstep multiplayer or replay systems on the assumption that it is.

The engine accumulates elapsed time and spends it in fixed 0.02s steps, so a slow frame runs several and a fast frame may run none. Interpolation then decides what you actually see.