Interface SolverBodyAccess

§26 body.applyAngularImpulse(angularImpulse) about +Z.

§26 body.applyForce(force) — newtons, at the centre of mass.

§26 body.applyForceAtPoint(force, worldPoint).

§26 body.applyImpulse(impulse) — newton-seconds at the centre of mass.

§26 body.applyImpulseAtPoint(impulse, worldPoint).

§26 body.applyTorque(torque) — newton-metres, about +Z in a plane.

Visits every live body in creation order, which is ascending SolverBodyAccess.getBodyId because ids are monotonic and never reused.

This is the iteration §33 requires: destroying a body removes it from the sequence and creating one appends, so no destruction can permute the order a checksum is taken in.

Visits every live collider in creation order.

The §31 CCD mode the solver is actually running for this body — read back from the solver rather than remembered, so it reports what the solver does and not what the descriptor asked for.

Reads the body's world-space centre of mass into out (§25).

As the solver holds it after mass-property resolution — collider offsets, densities, and authored overrides included — not a re-derivation. The centre of mass differs from the transform origin for any off-centre or compound body, which is exactly when a caller wants it: §113's centre-of-mass display was staged on the absence of this member (DEBUG_DRAW_STAGED, 2026-08-02) and unblocked by it (2026-08-04).

In a "2d" world out.z is 0 (§21). Rapier serves this directly (RigidBody.worldCom(), verified against the installed 0.19.3 typings, WP-10.3).

The monotonic id §33's checksum orders by.

The body's mass in kilograms, as the solver computed it (§23, §25).

§23 derives mass from collider density when it is not authored, and that derivation belongs to the solver (plan §6d, 2026-08-01): the world reads it back here after registration so RigidBody.inverseMass stops reporting NaN.

Reads a body's world transform — the read §42's "physics" authority publishes onto a node.

In a "2d" world outPosition.z is 0 and outRotation is the pure Z quaternion equivalent to the solver's scalar angle (§21).

Reads linear (m/s) and angular (rad/s) velocity into out parameters (§23).

The body a collider belongs to (§24, §37).

The collider's monotonic id, ordered like SolverBodyAccess.getBodyId.

§32 sleep state, as the solver holds it after the step. The transitions are also reported through drainEvents; this is the state the world publishes onto RigidBody.sleeping.

Clears the accumulated forces and torques (not impulses, which change momentum at the moment they are applied).

§26's rule is that a force acts for one step; solvers commonly keep user forces until they are reset, so the world resets before it re-applies the step's command buffer. An implementor whose forces are already per-step may implement this as a no-op.

Teleports a body (§37 "teleports").

Use SolverBodyAccess.setNextKinematicTransform for a "kinematic-position" body that should push dynamic bodies on the way: a teleport moves the body without deriving the motion that a contact response needs.

Re-types a body in place — §22's four simulation models, swapped on a body that already exists (plan P7-3).

In place, and why that is the whole point

The body keeps its handle, its monotonic SolverBodyAccess.getBodyId id, its position in SolverBodyAccess.forEachBody's sequence, its colliders, and its mass properties. Nothing is destroyed and nothing is created, so §33's checksum stream is taken over the same bodies in the same order before and after the switch: two runs that differ only in when a body was re-typed still hash identically up to that step. Destroying and re-creating the body would append a new id and permute nothing but would still change the id set, which is exactly what §33 forbids a mid-run control-mode change from doing.

What the solver keeps and what it drops

The pose survives every transition — a body re-typed while falling is exactly where it was. Velocities are a solver's business: a body switched away from "dynamic" stops integrating, and a body switched to "dynamic" resumes from whatever velocity state it holds, which is usually zero. PhysicsWorld.setBodyControlMode is where §19's velocity inheritance seeds that (an activated ragdoll continues the motion its animation had), through SolverBodyAccess.setBodyVelocities; this method never invents a velocity of its own.

wake

true (the default, as on SolverBodyAccess.setBodyTransform) wakes a sleeping body, so a body activated into "dynamic" starts simulating on the next step instead of staying asleep at the pose it fell asleep in. false leaves the §32 sleep state exactly as it was.

Re-typing to the type the body already has is a legal no-op apart from wake.

Writes both velocities (§23). This is also how a "kinematic-velocity" body is driven (§22).

Sets a "kinematic-position" body's target pose for the next step (§22).

The solver derives the motion from the current pose to the target, so dynamic bodies in the way react to it — which is what distinguishes this from SolverBodyAccess.setBodyTransform.

§32's explicit sleep command, queued by RigidBody.sleep().

§32's explicit wake command, queued by RigidBody.wake().