Rigidbodies, Forces and the Physics Step

There comes a point in every developer's apprenticeship with Unity when a crate is given a Rigidbody for the first time and, released in midair, falls. It is a small thing, yet it feels uncanny: the object has acquired weight, and the developer has written no code at all. Gravity, collision and momentum have arrived together, as if the crate had been quietly handed to another authority that now decides, without consultation, where it shall be.

That impression is exactly right, and much that follows depends on taking it seriously. A Rigidbody is the component by which a GameObject is surrendered to the physics engine. From that moment its position and rotation are computed by the simulation, which advances in its own regular steps, applies forces, resolves contacts and writes the results back. Scripts may still influence the body, but they must do so in the engine's own language, through forces, velocities and a few sanctioned methods.

What follows describes that language patiently: the properties that give a body its physical character, the four ways of applying a force and the arithmetic behind them, the kinematic mode for bodies that must move by script, the rhythm of the physics step and the interpolation that hides it, and finally the habit that causes more trouble than any other, moving a physics body by writing to its transform.

Mass, drag and gravity

The first properties of a Rigidbody describe how it resists change. Mass is the most familiar. It does not make an object fall faster, since in Unity as in the real world gravity accelerates every body equally regardless of its mass, but it determines how hard the object is to push and how much it pushes others in a collision. A crate of mass ten, struck by a ball of mass one, barely moves; reverse the masses and the ball is the one that stops dead.

Drag slows linear motion and angular drag slows rotation. They are not faithful models of air resistance, which grows with the square of speed; they are simple damping terms that remove a share of the velocity on every step. A little drag makes objects settle convincingly, while a large value makes them move as if through honey. In Unity 6 these properties were renamed linearDamping and angularDamping, and velocity became linearVelocity, though older code and tutorials still use the earlier names.

Gravity is applied when useGravity is enabled, using the vector set in the project's physics settings, by default a downward acceleration of 9.81 metres per second squared. After one second of free fall without drag, a body is moving at about 9.81 metres per second, whatever its mass. Gravity can be switched off per body, which suits floating platforms or a ghost drifting across a graveyard, and can be changed globally for a whole game set on a smaller, lighter world.

Four ways to push

The usual way to move a dynamic body is AddForce, which takes a vector and an optional ForceMode. The mode decides two things: whether the push is spread over time or delivered all at once, and whether the body's mass is taken into account. Those two choices give four combinations, and each one corresponds to a distinct physical idea that is worth keeping clearly in mind, because choosing the wrong mode is a common source of motion that feels oddly heavy or oddly light.

ForceMode.Force, the default, is a continuous force measured in newtons and divided by mass. It is meant to be applied on every physics step, the way an engine pushes a cart. Its effect in a single step is small: with the default fixed timestep of 0.02 seconds, a force of 10 newtons on a body of mass 2 adds 10 times 0.02 divided by 2, which is 0.1 metres per second. Held for fifty steps, one full second, it adds five metres per second.

ForceMode.Impulse delivers the same kind of push all at once, still divided by mass. An impulse of 10 on that same body of mass 2 changes its velocity by 5 metres per second immediately, exactly what the continuous force achieved over a whole second, because an impulse is simply force multiplied by the time over which it acts. Impulses suit sudden events such as a jump, an explosion or the strike of a hammer, and they should normally be applied once, not every frame.

The remaining two modes ignore mass. ForceMode.Acceleration is the continuous version: an acceleration of 10 adds 0.2 metres per second per step to any body, light or heavy, which is how gravity itself behaves. ForceMode.VelocityChange is the instant version, adding its value directly to the velocity, so a VelocityChange of 10 adds exactly 10 metres per second regardless of mass. These are useful when a designer wants a dash or a knockback to feel identical on every creature, whatever its weight.

Kinematic bodies

Not every object that interacts with physics should be pushed around by it. A moving platform, a swinging gate on a fixed hinge, a character driven precisely by player input: these need to affect other bodies without being affected in return. Setting isKinematic on a Rigidbody achieves this. A kinematic body ignores forces, gravity and collisions; nothing in the simulation can move it. Yet it still takes part in the world, pushing dynamic bodies aside when it moves into them and generating contact information.

The proper way to move a kinematic body is MovePosition and MoveRotation, called from FixedUpdate. These methods tell the engine where the body should be at the end of the next step, and the engine moves it there in a way that dynamic bodies understand: a crate resting on a rising platform is carried upward rather than left hanging in the air or flung away, because the engine knows the platform moved and with what velocity. Interpolation, discussed below, also works correctly with them.

There is a temptation to make everything kinematic, keeping full control and using physics only for detection. Sometimes that is the right design; many character controllers work this way. But a kinematic body never responds to impacts, so it will not be knocked back, will not stop when it meets a wall and will happily pass through other kinematic or static objects. Whatever the simulation would have provided must then be written by hand, collision by collision.

The rhythm of the physics step

Physics in Unity does not run once per rendered frame. It runs at a fixed timestep, by default 0.02 seconds, which is fifty steps per second, and the engine performs as many steps as needed to keep pace with real time. On a frame that took 0.05 seconds, two steps may run; on a fast frame, none at all. FixedUpdate is called once before each physics step, which makes it the natural place for code that applies forces or moves bodies.

The reason for fixed steps is stability and repeatability. A simulation advanced by uneven intervals behaves differently on fast and slow machines, and large intervals cause objects to tunnel through each other or bounce with impossible energy. With a constant step, a stack of crates behaves the same way whether the game is rendering thirty frames per second or two hundred. The price is that physics and rendering run to different clocks, and that mismatch must be handled somewhere.

Code that reads input should still run in Update, because input arrives with frames, and a key pressed and released between two physics steps could be missed if checked only in FixedUpdate. The usual pattern is to record the intention in Update, a flag that jump was pressed or the current movement vector, and to act on it in the next FixedUpdate. Continuous forces belong there too, since applying ForceMode.Force in Update would make the total push depend on frame rate.

One more consequence deserves mention. Collision messages such as OnCollisionEnter are delivered as part of the physics step, not the frame, so they arrive at the physics rhythm. A script that logs a value in Update and another in OnCollisionEnter may see them interleave in ways that seem odd until one remembers that two clocks are running. Keeping physics logic together, on the physics side, avoids most of that confusion.

Interpolation and smooth motion

The difference between the clocks shows itself as stutter. On a display refreshing at 144 frames per second with physics at fifty steps, there are about 2.88 frames for every step. Most frames therefore draw a body at the same position as the frame before, and then it jumps forward when a step occurs. A camera following such a body makes the effect worse, since the whole world appears to judder around a subject that is moving in small, uneven leaps.

The interpolation setting on a Rigidbody addresses this. With Interpolate selected, Unity draws the body at a position blended between its two most recent physics states, according to how much time has passed since the last step. The motion becomes smooth, at the cost of showing the body slightly in the past, at most one step behind. Extrapolate instead predicts ahead from the current velocity, which removes the lag but can overshoot when the body changes direction or strikes something.

Interpolation is usually worth enabling on the few bodies the player watches closely, the character, the camera's target, a ball in flight, and leaving off for the hundreds of crates and debris that nobody follows with the eye. It only works if the body is moved through the physics system, however. A script that writes directly to the transform overrides the interpolated position, and the smoothness disappears along with several other guarantees.

Hands off the transform

This brings us to the most common and most damaging habit in Unity physics: moving a dynamic Rigidbody by setting transform.position each frame. It seems natural, since that is how objects without physics are moved, and at first it appears to work. But the physics engine is not consulted about the change. The body teleports, its velocity knows nothing of the move, and if it lands inside another collider the engine must push the two apart violently on the next step.

The symptoms are familiar to anyone who has fought them: characters that jitter against walls, objects that pass through thin barriers at speed, stacked items that explode apart, and interpolation that stutters for no apparent reason. Each comes from two authorities giving contradictory orders. The script says the body is here; the simulation, which had its own idea, tries to reconcile the claim with its contacts and velocities, and the result is neither what the script nor the engine intended.

The remedy is to choose one authority and speak its language. For a dynamic body, apply forces or set velocity and let the simulation do the rest. For a kinematic body, use MovePosition and MoveRotation in FixedUpdate. When a body must be placed somewhere instantly, as when a character is set down at a spawn point at the start of a level, setting Rigidbody.position once is acceptable, since it is a deliberate teleport rather than a pretence of motion. Respect that boundary and the simulation becomes a faithful servant instead of an unpredictable rival.