ReadonlyangularAccumulated angular impulse in newton-metre-seconds (§26
applyAngularImpulse).
ReadonlyforceAccumulated linear force in newtons (§26 applyForce).
ReadonlyimpulseAccumulated linear impulse in newton-seconds (§26 applyImpulse).
ReadonlypointHow many entries of RigidBodyCommands.pointForces are live.
ReadonlypointPooled applyForceAtPoint entries; see the record documentation.
ReadonlypointHow many entries of RigidBodyCommands.pointImpulses are live.
ReadonlypointPooled applyImpulseAtPoint entries; see the record documentation.
ReadonlysleepThe last RigidBody.wake or RigidBody.sleep of this step, or
null.
Last call wins rather than two independent flags: a body told to wake and then to sleep within one step has to resolve to something, and "the most recent instruction" is the only resolution that does not depend on the order in which the world happens to read two booleans (§33).
ReadonlytorqueAccumulated torque in newton-metres (§26 applyTorque).
What a body has been asked to do since the world last drained it (§26, §32).
Read-only view of live, body-owned storage: the vectors and the pool entries are the body's own instances, so a reference taken here reflects later accumulation and is reset in place when the world clears the buffers. Nothing in this record is simulation state — it is a queue of requests.
Clearing semantics
The world consumes the whole record once per fixed step, hands it to the adapter, and clears it. That single rule produces the two behaviours §26 describes:
applyForceevery step (from afixedUpdatelistener, §10) — the buffer is empty again by the time the next step begins;Point loads are pooled
pointForcesandpointImpulsesare pools that grow to the high-water mark of a single step and never shrink; only the firstpointForceCount/pointImpulseCountentries are live. Clearing resets the counts, not the arrays, so a steady-state body accumulating point loads every step allocates nothing (§7b, plan D7).