physics-tuning

1# Physics tuning
2 
3Most "bad physics" is not a bug in the engine — it's a mismatch between the
4**fixed-timestep simulation** and the **variable-rate render loop**, or untuned
5mass/drag/CCD/layer settings. This skill covers the engine-neutral knobs that
6make physics stable and responsive; pair it with `godot-physics` or
7`unity-physics` for the concrete APIs.
8 
9## When to use
10 
11- Use when motion jitters, objects pass through walls (tunneling), stacks
12  explode, or movement feels floaty/sticky/laggy.
13- Use to decide what goes in the fixed (physics) step vs the render frame, and
14  how to interpolate between them.
15- Use to tune gravity, mass, drag, restitution, solver iterations, sleeping, and
16  collision layers/masks.
17 
18**When *not* to use:** for an engine's exact physics nodes/components and
19collision callbacks, use `godot-physics` or `unity-physics`. For *movement
20decisions* (when to jump, AI steering) use `input-systems` and `game-ai`. For
21platformer jump-feel specifics like coyote time/jump buffering, that's input/
22controller territory — see `input-systems` and the `platformer` genre.
23 
24## Core workflow
25 
261. **Run physics on a fixed timestep.** Simulate at a constant rate (e.g. 50–60
27   Hz). A fixed `dt` makes the simulation deterministic-ish and stable; a
28   variable `dt` makes integration and collisions inconsistent.
292. **Put physics work in the physics callback**, not the render frame. Apply
30   forces/velocities and read collisions in the fixed step (`FixedUpdate` /
31…