Selects §31's continuous-collision method on a live body.
predictionDistance is "speculative"'s prediction distance in world
units, undefined for the adapter's documented default; it is ignored for
every other mode. "disabled" must turn off whatever the body was using,
which is what makes this reversible.
OptionalpredictionDistance: numberReplaces §23's two damping coefficients, both >= 0.
Replaces §23's gravity multiplier: 1 leaves gravity as-is, 0 is weightless.
Optionalwake: booleanReplaces §23's mass triple — mass, centre of mass, rotational inertia — on a body that already exists.
mass is in kilograms and is always defined: "derive my mass from collider
density again" is not expressible here, because undoing an authored mass
means restoring every collider's own density, which only the registration
path knows (see PhysicsWorld's drain, which never queues an un-authoring).
centerOfMass (body-local metres) and inertiaTensor are undefined when
the component never authored them, which is §23's instruction to derive
those two from the colliders and the new mass — not an instruction to use
the origin and the identity tensor. An implementor must reproduce whatever
its createBody does for the same combination, so that writing mass and
re-registering the body give the same simulation.
In a "2d" world only the tensor's Z diagonal entry is meaningful (§21,
§23).
Neither vector nor the tensor is retained: both are the component's own live objects, and an adapter that keeps a reference would alias them.
Optionalwake: booleanReplaces a collider's §24 participation: whether it is a sensor, the bit set of groups it belongs to, and the bit set it collides with.
Both bit sets are 16-bit masks (§24). Turning a collider into a sensor mid-simulation changes which §29 events it emits from the next step on; pairs that were already touching are re-classified by the engine, not here.
Replaces a collider's §25 surface properties.
friction and restitution are the effective coefficients the engine
resolved from the collider's own fields and its PhysicsMaterial — an
adapter never re-runs that precedence. density is undefined when the
body's mass is not derived from collider density, in which case the
implementor must leave the collider's mass contribution exactly as it is:
writing a density into a body whose mass was authored would silently
un-author it.
§25's rollingFriction and spinningFriction are deliberately absent —
they are declared through PhysicsTuningCapabilities (PH-14/PH-15) and
neither shipped adapter applies them, so a parameter here would be a
promise no implementor keeps.
The post-registration property writes §37 names and SolverBodyAccess leaves out (§23, §24, §25, §31; PH-1 stage 2, 2026-08-07).
What it is for
Everything in SolverBodyAccess is per-step traffic: pose, velocity, forces, sleep. The six methods here are the rare writes — a mass that changed, a damping coefficient a tuning slider moved, a collider that became a sensor. They are called only for a component that was actually written to since the last step, so an adapter may implement them without any concern for per-step cost.
Optional, and honest about it
An adapter implements all six or none:
supportsSolverBodyTuningis a structural all-or-nothing check, so a half-implemented seam is treated as absent rather than producing writes that reach the solver for two properties out of six. A world whose adapter does not implement it keepsRigidBody's warn-once machinery on (see the truth table at the top ofrigid-body.ts): the write is refused loudly instead of being dropped, which is thePhysicsTuningCapabilitiesrule applied to a whole seam.wakeWhere a method takes
wake,true(the default, as everywhere else on this seam) wakes a sleeping body so the new property is felt on the next step;falseleaves §32 sleep state alone. The two collider methods take none: Rapier's collider setters do not touch the parent body's sleep state, and inventing a wake here would make a filter change move a body.