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

# Body.component Editable collider, mass, forces and complete velocity state on an ordinary Zero entity. For static mesh collision, select shape=mesh, enable isStatic and assign a normal Zero mesh asset to mesh. meshScale sets the positive local collision scale; entity position/rotation place it in the world. Primitive sizes remain explicit. Changes to stored mesh geometry refresh collision automatically. No CPU-resident render copy or host files are required. Use the same mesh and corresponding scale for the visual Model when matching rendered and collision geometry. Meshes currently support up to8192 vertices/4096 triangles, static only; triangle winding determines the front face. Large-terrain acceleration remains unfinished. `collisionEnabled` defaults to true. Disable it for an explicit animation/motor target or other noncolliding body. Mass, integration, joints and drives continue to work; only contact generation is disabled. This differs from collisionGroup, which suppresses pairs sharing the same nonzero group. The WASM state field is `collision_enabled`; omitted means true for existing saved states. For `shape="box"`, `halfExtents` describes the unrounded core and `rounding` adds the radius outside that core. An axis's total outer size is `2 * (halfExtents[axis] + rounding)`. The rounding radius may exceed the core's half-height (as it does for the stock deck). Core extents must be nonnegative, and every outer extent must be positive. These are the reconstructed engine's rounded-box conventions; rounding does not subtract from the entered core. For `shape="compound"`, add CollisionVolume components to direct child entities. Their local transforms and shape fields supply the ordered collision volumes; use unique integer orders. The Body's mass is the total compound mass. Changing child transforms or dimensions updates the submitted shape, and collision-disabled children retain their contribution to mass. Positive uniform body/child scales are supported. Position/rotation remain in the authored body frame while linear velocity describes its center of mass. Leave `authoredMassFrame=false` for normal compounds; true is an explicit source-specific override used by the stock deck. `maximumLinearVelocity` and `maximumAngularVelocity` pass the native speed caps through to integration. Defaults remain1000000 for existing bodies; stock board construction carries its native unbounded/ wheel-specific values. Caps must be finite and nonnegative. `solverOrder` controls registration order within the World; entity ID breaks ties. Give assembly parts distinct orders when matching a source construction sequence. The same ordering field exists on Joint and Drive. Enable `customMassProperties` to supply `inverseMass`, principal `inverseInertia`, and `rotationalEnergyCoefficient` explicitly. These replace inferred mass/inertia while retaining the selected collision geometry. All must be finite and positive; `isStatic` still suppresses inverse mass and inertia in the solver. With the switch off, existing geometry-derived behaviour remains unchanged. `massFramePosition` and `massFrameX/Y/Z/W` describe the authored body frame in center-of-mass coordinates, using a unit quaternion. Entity transforms, collision geometry and Joint/Drive anchors remain in authored coordinates; linear velocity is the center-of-mass velocity. The kernel converts input/output poses and constraint frames consistently. This supports the reconstructed skeleton's independently adjusted inertia rather than forcing it into primitive estimates. The JSON field is `mass_properties: {inverse_mass, inverse_inertia, spherical, frame_position, frame_rotation}`; omission preserves old behaviour. This is a body capability, not a completed native character preset or animation controller. Native ground probes now include static boxes with positive half-extents. Rounding uses the original query fatness path. Solid box contacts remain native primitive-pair contacts, so a box does not need a TerrainQuery component; that component is for static triangle meshes. The visible Model and collision definition are independent. This does not add probe support for degenerate rounded boxes, static spheres or capsules.