Quick answer: Project Settings → Time. Fixed Timestep = 0.02 (50Hz) for typical games. Maximum Allowed Timestep = 0.1 to bound worst-case catch-up. Move non-physics work out of FixedUpdate.
Game stutters under load. Profiler shows FixedUpdate running 4–6 times per Update. The physics rate is too high for what the budget allows; catch-up snowballs.
The Symptom
Frame rate drops cascade into worse drops. Heavy frames take 50ms+ because FixedUpdate catches up the gap, each step doing more work, frame stretches further.
The Fix
Project Settings → Time:
Fixed Timestep: 0.02 // 50Hz, comfortable
Maximum Allowed Timestep: 0.1 // max catch-up = 5 steps
Maximum Particle Timestep: 0.03
Time Scale: 1
50Hz physics is enough for most non-VR games. Bumping Maximum Allowed Timestep down prevents one bad frame from triggering many catch-up steps.
Move Work Out of FixedUpdate
Audit your FixedUpdate methods. Anything that’s not adding forces, calling Move on CharacterController, or running Physics queries should live in Update.
// Bad — runs N times per frame under load
void FixedUpdate()
{
UpdateUI(); // 5ms
ScanEnemies(); // 8ms
rigidbody.AddForce(force);
}
// Good
void Update()
{
UpdateUI();
ScanEnemies();
}
void FixedUpdate()
{
rigidbody.AddForce(force);
}
VR Exception
VR games typically run physics at 90Hz to match HMD refresh. Set Fixed Timestep = 0.0111. Watch CPU budget closely.
Verifying
Profiler → CPU Usage. Look at FixedUpdate.PhysicsFixedUpdate. Cumulative time should stay below 4–6ms per frame at target rate. Reduce work or rate until it does.
“50Hz default. Cap catch-up. Move heavy work to Update. Frame rate stabilizes.”
Related Issues
For Rigidbody2D interpolate, see interpolate. For Rigidbody sleep, see Rigidbody sleep.
Right rate. Bound catch-up. Lean FixedUpdate.