# Skate 3 physics engine for Zero
`skate_physics` integrates a reconstructed Skate 3 physics engine into Zero. Use this package for Skate 3-style skateboard and rider physics, or use its custom rigid-body solver components independently. It exposes a reconstructed Skate 3-derived Rust solver through editable entities, components and assets: physical bodies, collision volumes, joints, constraints, motors, forces and simulation state. It is a reusable simulation system, not just a skateboarding controller or a park scene.
## Why use it?
Build and tune connected physical assemblies without first writing the integration between a custom solver and Zero. Inspect velocities and forces, change mass and inertia, configure joint limits, and drive mechanisms with spring/damper or hard motors. Motors apply impulses through the solver rather than teleporting bodies. The general body/joint/drive layer does not require a rider or animation clips.
The package connects physics authoring, fixed-step simulation and entity presentation. Use it to experiment with constrained bodies, motor-driven mechanisms and vehicle assemblies; the skateboard and rider are included applications of the system, not its definition.
## What it provides
- `World`: authority-gated fixed-step simulation and publication of solved entity state.
- `Body` and `CollisionVolume`: editable mass, inertia, forces, velocities, primitive/compound collision geometry and bounded static-mesh collision.
- `Joint` and `Drive`: body references, local frames, linear/angular limits and independently configurable motors.
- `API`: in-engine authoring helpers and an explicit-state solver interface.
- Input and actuator components for device-driven or scripted physical assemblies.
- An integrated skateboard/rider system with control maps, rig mapping, visual bindings and animation-slot overrides.
- Example scenes, a modular park, an authored skateboard, and the `GettingStarted` guide.
## Where to start
Read **GettingStarted** for the distinction between the general physics components and the specialized rider integration. The low-level **Demo** workbench illustrates bodies, joints and a vehicle assembly. **SampleScenes** exposes rider, vehicle-only, self-propelled, scripted-control and physics-tuning examples. The world's default **RiderFidelity** scene demonstrates the coupled rider/board system with Zero's avatar and the authored park.
## Integration boundaries
Static mesh collision has documented size limits; see `Body`. The specialized native rider/board integration requires a fixed body layout; that restriction is distinct from authoring assemblies with the general body/joint/drive API.
The rider demo retains converted reference animations for testing, replaceable through normal Zero assets and animation bindings. These are not required by the general motor component. The default showcase uses the authored skateboard and Zero avatar; unused reference character and board models are excluded from publication. See the component documentation for supported shapes, units and solver-specific conventions.
# OriginalLeftBackWheel
Adapted inside Zero from NIGHTGRIND rig.module (Claude_test_nro_2 / Deata), MIT; source asset faf046ff-0fc5-49a5-8d15-f4fc32ffe7ee, published commit 01M1Q630DYAHD1QP359S0BPDN0. Physics is separate.
# OriginalBackTruck
Adapted inside Zero from NIGHTGRIND rig.module (Claude_test_nro_2 / Deata), MIT; source asset faf046ff-0fc5-49a5-8d15-f4fc32ffe7ee, published commit 01M1Q630DYAHD1QP359S0BPDN0. Physics is separate.
# OriginalFrontTruck
Adapted inside Zero from NIGHTGRIND rig.module (Claude_test_nro_2 / Deata), MIT; source asset faf046ff-0fc5-49a5-8d15-f4fc32ffe7ee, published commit 01M1Q630DYAHD1QP359S0BPDN0. Physics is separate.
# VehicleFinish
Original authoring-workbench material. No game content.
# OriginalBoardGrip
Adapted inside Zero from NIGHTGRIND rig.module (Claude_test_nro_2 / Deata), MIT; source asset faf046ff-0fc5-49a5-8d15-f4fc32ffe7ee, published commit 01M1Q630DYAHD1QP359S0BPDN0. Physics is separate.
# OriginalBoardDeck
Adapted inside Zero from NIGHTGRIND rig.module (Claude_test_nro_2 / Deata), MIT; source asset faf046ff-0fc5-49a5-8d15-f4fc32ffe7ee, published commit 01M1Q630DYAHD1QP359S0BPDN0. Physics is separate.
# BoardGripFinish
Original PBR surface for replaceable board visuals.
# OriginalLeftFrontWheel
Adapted inside Zero from NIGHTGRIND rig.module (Claude_test_nro_2 / Deata), MIT; source asset faf046ff-0fc5-49a5-8d15-f4fc32ffe7ee, published commit 01M1Q630DYAHD1QP359S0BPDN0. Physics is separate.
# OriginalRightFrontWheel
Adapted inside Zero from NIGHTGRIND rig.module (Claude_test_nro_2 / Deata), MIT; source asset faf046ff-0fc5-49a5-8d15-f4fc32ffe7ee, published commit 01M1Q630DYAHD1QP359S0BPDN0. Physics is separate.
# BoardMetalFinish
Original PBR surface for replaceable board visuals.
# BoardWheelFinish
Original PBR surface for replaceable board visuals.
# OriginalRightBackWheel
Adapted inside Zero from NIGHTGRIND rig.module (Claude_test_nro_2 / Deata), MIT; source asset faf046ff-0fc5-49a5-8d15-f4fc32ffe7ee, published commit 01M1Q630DYAHD1QP359S0BPDN0. Physics is separate.
# World.component
Authority-gated fixed-step driver; reads and publishes ordinary Zero entities.
Bodies, joints and drives sort by their editable `solverOrder`, then entity ID.
Existing default-zero orders retain the prior behavior. Presets can preserve
native registration order across clones instead of depending on generated IDs.
## Fixed-step publication
`maxSubsteps` (1..16, default8) bounds fixed steps per publication. Entered NativeGround `body_commands` updates can batch because each step derives fresh native observations from the preceding state. Entry, exit, observe and externally supplied Ground observations stay single-step. Animation/other external targets are sampled before the request and held through its batch; choose1 when a caller requires new external targets each step.
New live body command values apply to the next request and do not invalidate already solved motion. Changes to body state, geometry, configuration, topology or authority still reject stale work. `receivedSeconds`/`simulatedSeconds` reset with restoreState; `droppedSeconds` and `rejectedResults` remain cumulative. `lastStepCount` names the last publication's step count. `onStep` fires once per publication, and readContacts returns the final substep's contacts.
# PresentedBody
Attach to a separate visual entity, set `body` to its simulated Body, and put
your models and camera target underneath it. Keep the proxy outside the physical
body hierarchy: solver publication must not move the rendered pose after the
camera sampled it. The World buffers solved poses for `presentationDelay`
seconds (default 0.1), interpolates all proxies on one clock, and updates them
before the camera. The physical Body remains authoritative and editable.
Use zero camera positional damping when exact relative framing is wanted.
Interpolation adds visual latency; it does not alter the solver or extrapolate
through collisions. A worker stall can exhaust the buffer and freeze presentation;
`World.presentationUnderruns` exposes this rather than hiding a stall.