# 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.

# BoardFeedback The reconstructed board post-physics phase using actual solved reports, not speculative contact candidates. Assign a World and its seven physical parts. Before each solve it runs the original wheel-line query against that World's static mesh surfaces. After every body has integrated it runs native report selection, ground-normal/contact classification, acceleration sampling and contact-time update. Contact-dependent wheel angular drag is then written for the next step, in the original phase order. All history and output are in the synchronized, readable state field. Contact counts, normal and time without contact are also visible directly. Disabling this component stops its updates; while active it owns wheel angularDrag. No rider, animation bank, game-disc pack or hidden WASM actor is created. The up vector, ground-angle limit, probe length and wiping-out mode are explicit inputs. A matching reference profile must supply matching values; 60 degrees is an authoring default, not a claim about all game modes. Dynamic-body collisions are still solved, but this native ground classifier consumes static-world reports, as in the preserved runtime.

# Drive An editable Skate solver motor between Body A and Body B in the selected World. Local anchors and frame quaternions describe frames the motor tries to align. Animate either frame to drive a limb, suspension or steering assembly. The motor applies impulses through the same solver as contacts and joints; it never teleports the bodies. Linear and angular drives have independent disabled, soft and hard modes. Soft mode uses spring and damping. Hard mode uses maximum correction velocity. MaxStrength limits each solver axis; zero provides no motor force. Disabled ignores the saved tuning values, so toggling it preserves tuning without applying impulses. The reconstructed solver retains its original drive coefficient conventions. All fields synchronize through Zero. No rider or animation clip is required. Strength values retain the Rust engine's native coefficient convention. They are not a direct force in newtons or torque in newton-metres. The solver limits each row using `dt * dt * maxStrength * inverseEffectiveMass`; the latter is the reciprocal of the row's inverse-mass/inertia denominator. In particular, a small-inertia body needs a larger angular strength number to support an offset load. Check the complete connected assembly, not just a free body. A native regression uses a 2kg, radius-0.15m root supporting a fixed 10kg load 0.5m to its side. At 120Hz/64 iterations, angular hard strength 1000 saturates; 10000 holds the orientation. This is an explanatory test, not a universal humanoid tuning preset. Changing collider dimensions changes inertia as well as contacts; tune limits against the mass properties of the intended body.