Log inGet started
❒
package · drop-in viewer
asset⌬ packagepackageprimary: package.yaml·originates fromworld 3d0fe004-d…

skate_physics

`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 enti…

by◐Deata·posted 13d ago
What it does

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.

Interface

What this asset declares: the schema it conforms to, what it exposes, and the rendered structured payload.

This asset doesn't declare a schema or structured payload.
⌬ Metadata
descriptionSkate 3 physics system for Zero: a reconstructed custom Rust physics engine with integrated skateboard and rider simulation, plus editable rigid bodies, collisions, joints and motors for other physical assemblies. Start with RiderFidelity or Samples.Rider for skating; World, Body, Joint and Drive for general physics.

Sub-parts

Everything contained inside this part. Assets are composite children (clickable cards). Files are leaf payloads. Expand any row to view its source.

Showing the 199 items nearest this part. It holds more than this page lists.

199+items
▣
module · born here
❒asset
# API.module In-engine authoring helpers for attaching World, Body and Joint, plus a direct explicit-state solver call. `attachBoneBody(target, skin, body, settings)` and `attachPoseTarget(target, world, source, body, settings)` expose the two directions of rig binding. References are assigned through normal component setters so Zero can replicate them. These are the same components the Avatar physical-rig helper assembles; users can author, inspect, or replace them individually. `attachVolume(child, settings)` adds a CollisionVolume to a direct child of a compound Body, chooses the next free order when omitted, and marks the child entity synchronized. Create the parent with `attachBody(parent, world, {shape="compound", mass=...})`, then author its volume children inside Zero. `attachBoardSteering(target, world, feedback, frontDrive, backDrive, settings)` binds the native steering component to explicit existing entities. Steering owns the two Drive frame targets while active; it creates no bodies. Its readable profile/history live inside Zero. It is not the complete ground controller. `attachNativeGround(target, world, feedback, frontDrive, backDrive, settings)` binds the native ground execution boundary. It is inactive until complete native records and entry state are supplied. It is not the unfinished live input producer.
▲ 0↑ born
◇
component · born here
❒asset
# Actuator Connect world and body, then set force/torque at full command. command is a synchronized scalar from -1 to1; input, AI or other Zero components can write it. For a vehicle, one actuator can apply forward thrust and another yaw torque. Choose body space to follow the chassis orientation, or world space for fixed directions. Set command0 to release or active=false to disable. Multiple actuators sum in deterministic entity-id order without overwriting Body.force/torque. Commands are sampled at each World request boundary (up to four fixed steps). They feed the existing Skate solver and do not move transforms directly or add a rider. Input-device bindings stay in normal Zero input components; this asset does not assume keyboard keys, a game genre or a multiplayer transport.
▲ 0↑ born
◇
component · born here
❒asset
# AnimationSource Attach to a skinned mesh entity and choose a normal Zero animation asset. Direct binding matches exact bone names and requires every target bone to have a clip channel. Retarget binding uses Zero's rig profiles and optional sourceRig. It reports matched/total bones and refuses zero coverage. Use one pose-writing animation component per skinned body; remove competing ClipPlayer/AnimGraph owners. The owned entity advances synchronized playhead; replicas sample that same state. playing, looping, speed and playhead are ordinary editable fields. Pausing playing holds the current pose. Clip/rig/binding or skeleton definition changes rebuild the graph; rebind() also rebuilds after an asset's content is edited in place. PoseTarget reads the resulting animated joints for physical Drive targets. No default character, stock animation or rider body is instantiated.
▲ 0↑ born
▣
module · born here
❒asset
# Avatar authoring `require("skate_physics.Avatar").attach(entity, options)` authors the bone tree, SkinnedModel and AnimationSource on an empty Zero entity. Defaults use the project's original mannequin and balance clip, with no retail content. Options accept normal `mesh`, `rig`, `clip`, `material` asset references, `binding` (direct/retarget), `physicsPose`, and `temporary` for test/runtime trees. The supplied rig must match the mesh's joint order and be parent-first. All created children and components remain ordinary editable Zero content. `rebind(entity, sourceAvatar?)` restores the skeletonRoot to the current root entity and rebuilds its animation binding after cloning, on runtimes that do not remap the legacy string skeletonRoot field. This helper does not create a camera, input controller or physics bodies. Compose it into Zero's existing player/avatar setup and add Body/Joint/Drive/PoseTarget/BoneBody only where the chosen gameplay needs them. If the engine clone omitted AnimationSource, pass the original avatar as the second argument. The helper restores only its editable playback fields through the explicit component asset reference. An omitted source is an error in that case. Custom physics components are not repaired by this avatar-only operation. ## Editable physical rigs `attachPhysics(avatarEntity, worldEntity, specs, options)` assembles the physics graph in **edit mode**. The avatar must already have a SkinnedModel and AnimationSource; the world entity must have this package's World component. Author on their owning peer. This creates no hidden runtime or networking state. Each ordered spec has: - `bone`: exact target-rig name; `body`: normal Body settings including explicit positive mass and sphere/box/capsule shape. Dimensions and offsets are in world metres, independent of visual mesh scale. - `parent`: optional earlier mapped bone. It creates a Joint; `joint` supplies normal Joint settings. Default anchors coincide at the child's rest bone origin, with free swing/twist. Set anatomical anchors and limits for your chosen rig. - `offset` and `rotation`: body-local bone position and unit quaternion. The helper initializes bodies and joint frames consistently with these offsets. - `weight`: visual physics influence, default 1. - `drive`: optional normal Drive settings. Creates an explicit static Body with collisionEnabled=false, a PoseTarget sampling the underlying animation, and a Drive to it. Omit drive for a passive body. The caller chooses motor tuning. Options: `rig` must match a custom mesh's source rig (the original mesh defaults to OriginalRiderRig); `parent` chooses the created entities' hierarchy parent (default the World); `temporary` is for disposable authoring checks. Positive uniform avatar and bone scales are supported. Nonuniform or mirrored scales, unknown/duplicate mapped bones, forward physical-parent references, and exceeding the 128-body World limit are rejected. Unmapped bones retain their animation. The return value contains `bodies`, `joints`, `targets`, `drives`, and `mappings` keyed by bone, plus `entities` listing the created entities. Edit these through Zero's inspector/components; no files need to be packed externally. Deleting the physics graph leaves the avatar content reusable. A vehicle needs no call to any avatar helper: author its bodies, joints and controls directly through API. The full-body default skating preset and its tuning are still under integration. This helper does not claim arbitrary motor gains are stable: a small-inertia, hard-motor 13-body test was unstable and is not a recommended preset.
▲ 0↑ born
▣
module · born here
❒asset
# Board construction `require("skate_physics.Board").build(worldEntity, options)` authors the native physics assembly in edit mode: seven physical parts, an explicit noncolliding hook target, six joints, two truck drives and a zero-strength hook drive. There is no rider simulation, camera, input controller or hidden plugin world. The returned root/bodies/joints/drives/volumes are ordinary synchronized entities. Use `result.deck` as the moving board reference, not the organizational root. Options: parent, name, position/rotation (relative to parent), collisionGroup, orderBase, temporary, definition, neutralPose, and visuals. Parent scale must be one. Defaults allocate a free collision group and an order range after existing World members, avoiding unintentional collision suppression between separate boards. `definition()` returns a fresh editable copy of the construction data. Modify it before building or edit the resulting components/transforms afterward, all inside Zero. The construction data is generated from the preserved Rust constructors. Contact materials are explicit host defaults (0.6 friction), truck collisions default off, and World gravity/iterations remain the caller's settings. The test configuration uses 60Hz and32 iterations. Wheel drives are not part of the stock assembly. Default visuals are ordinary Model children on the physical parts. Pass `visuals=false` for physics only, or a BoardVisuals binding map to use your own meshes/materials. No rider is created; avatar attachment remains separate. Saved-scene, cold-load and full multiplayer acceptance are still being verified. Default construction uses a neutral pose derived from the native joint frames, so wheel/truck visuals are aligned before simulation starts. `neutralPose=false` preserves the raw native constructor poses. Supplying a custom definition also preserves its poses unless neutralPose is explicitly true. The pure definition() data is unchanged. This is spawn placement policy, not a solver alteration. `build` also supports an already-owned physics World in play. Construction is synchronous and refuses an ownership/world/mode change. `synced=false` keeps the created assembly local; combine with `temporary=true` for session-only inspection. Normal construction retains the existing synchronized default.
▲ 0↑ born
◇
component · born here
❒asset
# 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.
▲ 0↑ born
◐
material · born here
❒asset
# BoardGripFinish Original PBR surface for replaceable board visuals.
▲ 0↑ born
◐
material · born here
❒asset
# BoardMetalFinish Original PBR surface for replaceable board visuals.
▲ 0↑ born
◇
component · born here
❒asset
# Native board steering Runs the fork's steering tilt, contact-dependent truck targets and normalized truck drive frames at 60 Hz. Bind a World, active BoardFeedback, and front/back Drive entities. All references must belong to that World. The component owns those drive frames while active. State, curves, base frames, input and outputs are editable in Zero; no external content pack is read. This component implements steering only. The complete ground force/state coordinator remains an integration requirement. Do not treat steering movement as proof that skating physics or the package is complete. `turn` and `hardTurn` are normalized input; `switched`, `pushing`, `balance` and `truckTightness` are explicit controller inputs. The native entry history starts with push scalar 1. Empty `baseFrames` uses the fork's stock truck geometry; supply two `{basis,position}` records for another assembly. The drive endpoints must be the feedback's corresponding truck A and deck B. One steering component may own each feedback/drive pair. The inspection scene binds A/D, the left stick and the touch stick to `turn`. Reset restores both retained state and authored drive frames. Releasing input clears turn through the normal Zero input map.
▲ 0↑ born
▣
module · born here
❒asset
# Board visuals `attach(assembly, bindings?, options?)` attaches normal synchronized Model children to the physics bodies returned by Board.build. Defaults use original, replaceable deck/grip/truck/wheel meshes adapted from the MIT NIGHTGRIND geometry module. No rider is created and no visual drives physics. Parent transforms provide the binding, so changing a Model mesh/material or child transform requires no plugin change. Meshes/materials are ordinary saved Zero assets, not runtime-only handles. Bindings map body names to lists of `{mesh, material?, position?, rotation?, scale?, name?}`. Pass actual asset references. A supplied map replaces the complete default map; omitted bodies have no new visual. `defaults()` returns a fresh map for selective edits. `options.temporary=true` is for disposable checks. The return value lists created visual entities; ownership stays with normal Zero entities.
▲ 0↑ born
◐
material · born here
❒asset
# BoardWheelFinish Original PBR surface for replaceable board visuals.
▲ 0↑ born
◇
component · born here
❒asset
# 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.
▲ 0↑ born
◐
material · born here
❒asset
# BodyFinish Original authoring-workbench material. No game content.
▲ 0↑ born
◇
component · born here
❒asset
# BoneBody Map a named bone on skin to an explicit physics body. Enable physicsPose on the skin's AnimationSource. weight blends from animation to the simulated pose; offset is in metres in the body's local frame, with a quaternion rotation offset. Mappings are normal synchronized entities and replicas read the replicated body. One active mapping per bone. This path currently requires uniform positive scale on the skin and bone ancestry; unsupported scale is reported, not silently repaired.
▲ 0↑ born
◇
component · born here
❒asset
# CollisionVolume Put this component on a direct child of a Body whose shape is `compound`. Edit the child's local position and rotation with Zero's normal transform tools. Positive uniform scale on the body and child is included in collision dimensions; nonuniform/mirrored scale is rejected. Shape fields define sphere, rounded-box core, Z-axis capsule, or triangle geometry. Triangle transforms are baked into vertices when the Body reads its state, preserving native mass conventions. Give each child a unique integer `order`. It preserves the authored accumulation order independently of entity IDs. `collisionEnabled=false` suppresses contacts but retains mass. Delete a child to remove both its geometry and mass contribution. The Body supplies material and total mass. It may have at most64 volume children. Use `API.attachVolume(child, settings)` to attach this component and automatically choose the next free order; the child's parent must already be a compound Body. All properties and transforms are ordinary synchronized Zero entity data. ## Native actor bodies CollisionVolume can also be a direct child of a NativeActorPart with role=board or role=rider. One or more volume children replace that body's native contact geometry; parts without volume children inherit their defaults. Removing the last child restores the defaults. Disabled children suppress contacts; use a disabled child when the intent is no contacts rather than inherited defaults. Child local transforms are in the body entity's centre-of-mass frame. No host files are needed. For native bodies, geometry editing does NOT recalculate mass or inertia: those remain separate NativeActorPart fields. It also does not alter the animation or wheel-probe/controller profile. Materials and controller collision gating stay native. Rider shapes retain native mode-dependent enable flags, collision groups and materials. A shape cannot enable a body the current native mode disables. The ready NativeRiderDriver:readColliderDefinitions() method reads current body-local native geometry, including disabled children, for inspection or in-engine authoring. Spheres were checked with actual Zero physical response, reset and restoration. Rounded boxes, capsules with offsets/rotation, and two triangle volumes were also checked against their calculated support height. Disabling the triangles removed their support; deleting them restored all 15 default deck children. Rider sphere authoring, disable/reset/restore and native masking have been checked. Additional rider multi-volume/self-contact scenarios remain to verify. The ready driver readRiderColliderDefinitions() method returns each rider body with its current native enabled flag, volume_group, and body-local shapes. Vehicle-only mode returns an empty rider list and rejects rider shape input.
▲ 0↑ born
◇
component · born here
❒asset
# ContactPair Set the physics World's `contactSelection` to `authored` to use its enabled ContactPair entities as the complete ordered list of collision candidates. Each pair holds normal Zero references to bodyA, bodyB and world. solverOrder sets order; entity ID breaks ties. Reversed pairs are distinct and may both be present, as in the native character solver. Identical directed duplicates and self-pairs are rejected. An empty authored list generates no contacts. Collision enabled flags, static/static suppression and collisionGroup still apply. This selects candidates only; native geometry and material handling determine the actual contacts. Default automatic selection remains unchanged.
▲ 0↑ born
△
mesh · born here
❒asset
# Mesh Mesh asset. `data.zmsh` is the engine-native geometry payload (`renderer.mesh.encode`); consumers reference the asset's guid.
▲ 0↑ born
△
mesh · born here
❒asset
# Mesh Mesh asset. `data.zmsh` is the engine-native geometry payload (`renderer.mesh.encode`); consumers reference the asset's guid.
▲ 0↑ born
△
mesh · born here
❒asset
# Mesh Mesh asset. `data.zmsh` is the engine-native geometry payload (`renderer.mesh.encode`); consumers reference the asset's guid.
▲ 0↑ born
△❒asset
# Mesh Mesh asset. `data.zmsh` is the engine-native geometry payload (`renderer.mesh.encode`); consumers reference the asset's guid.
▲ 0↑ born
·
scene · born here
❒asset
# Demo.scene Content-free workbench: falling body, constrained body and five-body vehicle assembly. All physical state is on editable Zero entities.
▲ 0↑ born
▣
module · born here
❒asset
Explicit authoring helper: build() creates the editable riderless physics workbench in the active scene. The shipped Demo.scene stores its authored entities directly. Run on an empty authoring scene to avoid duplicate examples.
▲ 0↑ born
◇
component · born here
❒asset
# 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.
▲ 0↑ born
◐
material · born here
❒asset
# FloorFinish Original authoring-workbench material. No game content.
▲ 0↑ born
◐
material · born here
❒asset
▲ 0↑ born
◐
material · born here
❒asset
▲ 0↑ born
△
mesh · born here
❒asset
# Mesh Mesh asset. `data.zmsh` is the engine-native geometry payload (`renderer.mesh.encode`); consumers reference the asset's guid.
▲ 0↑ born
△
mesh · born here
❒asset
# Mesh Mesh asset. `data.zmsh` is the engine-native geometry payload (`renderer.mesh.encode`); consumers reference the asset's guid.
▲ 0↑ born
△❒asset
# Mesh Mesh asset. `data.zmsh` is the engine-native geometry payload (`renderer.mesh.encode`); consumers reference the asset's guid.
▲ 0↑ born
△❒asset
# Mesh Mesh asset. `data.zmsh` is the engine-native geometry payload (`renderer.mesh.encode`); consumers reference the asset's guid.
▲ 0↑ born
△❒asset
# Mesh Mesh asset. `data.zmsh` is the engine-native geometry payload (`renderer.mesh.encode`); consumers reference the asset's guid.
▲ 0↑ born
△
mesh · born here
❒asset
# Mesh Mesh asset. `data.zmsh` is the engine-native geometry payload (`renderer.mesh.encode`); consumers reference the asset's guid.
▲ 0↑ born
△
mesh · born here
❒asset
# Mesh Mesh asset. `data.zmsh` is the engine-native geometry payload (`renderer.mesh.encode`); consumers reference the asset's guid.
▲ 0↑ born
△
mesh · born here
❒asset
# Mesh Mesh asset. `data.zmsh` is the engine-native geometry payload (`renderer.mesh.encode`); consumers reference the asset's guid.
▲ 0↑ born
△
mesh · born here
❒asset
▲ 0↑ born
◐
material · born here
❒asset
▲ 0↑ born
◐
material · born here
❒asset
▲ 0↑ born
❒
bundle · born here
❒asset
▲ 0↑ born
❒
bundle · born here
❒asset
▲ 0↑ born
❒
bundle · born here
❒asset
▲ 0↑ born
❒
bundle · born here
❒asset
▲ 0↑ born
❒
bundle · born here
❒asset
▲ 0↑ born
❒
bundle · born here
❒asset
▲ 0↑ born
❒
bundle · born here
❒asset
▲ 0↑ born
❒
bundle · born here
❒asset
▲ 0↑ born
❒
bundle · born here
❒asset
▲ 0↑ born
❒
bundle · born here
❒asset
▲ 0↑ born
❒
bundle · born here
❒asset
▲ 0↑ born
◐❒asset
▲ 0↓ import
❒❒asset
▲ 0↓ import
◐
material · born here
❒asset
▲ 0↑ born
❒
bundle · born here
❒asset
▲ 0↑ born
❒
bundle · born here
❒asset
▲ 0↑ born
❒
bundle · born here
❒asset
▲ 0↑ born
❒
bundle · born here
❒asset
▲ 0↑ born
❒
bundle · born here
❒asset
▲ 0↑ born
▦
texture · born here
❒asset
# Texture Managed texture asset. `data.ztex` is the encoded payload the renderer uploads; compression settings live in `settings.yaml` (`texRef:setSettings({ ... })` to change one).
▲ 0↑ born
❒
bundle · born here
❒asset
▲ 0↑ born
❒
bundle · born here
❒asset
▲ 0↑ born
❒
bundle · born here
❒asset
▲ 0↑ born
◐
material · born here
❒asset
▲ 0↑ born
▦
texture · born here
❒asset
# Texture Managed texture asset. `data.ztex` is the encoded payload the renderer uploads; compression settings live in `settings.yaml` (`texRef:setSettings({ ... })` to change one).
▲ 0↑ born
◐
material · born here
❒asset
▲ 0↑ born
·
guide · born here
❒asset
▲ 0↑ born
◇
component · born here
❒asset
# Grind path Place beneath terrainRoot. Add ordered GrindPoint child entities and move them to the grind line on your rail or ledge. The fork's authored spline provider handles acquisition and grinding. This does not create collision or render geometry: the corresponding surface entity supplies both. A path may be open or closed.
▲ 0↑ born
◇
component · born here
❒asset
# Grind point An ordered child of a GrindPath. Move the entity in the Zero editor to edit the path.
▲ 0↑ born
◇
component · born here
❒asset
# InputControl Select a Zero inputMap, its action name and an Actuator entity. scalar accepts a button/number action; x/y select an axis from a vector action. deadzone removes small values and rescales the remaining range. scale changes strength or sign. The map defines keyboard, mouse, gamepad and touch bindings inside Zero. Only the local control and actuator owner activates input. The World and physical body may be owned by a different peer: synchronized command state reaches that solver authority. Losing command ownership, disabling or destroying the component releases its activation claim. Rebinding resets the previous locally-owned actuator command; stale callbacks are ignored. Use one InputControl per actuator. Multiple forces use separate actuators. feed(value,pressed) exercises the same path for authored tests or synthetic input. This component writes command state, never physics transforms or plugin internals.
▲ 0↑ born
·
inputmap · born here
❒asset
# InspectionControls.inputMap Board inspection controls for reset and pause. These do not implement skating movement.
▲ 0↑ born
◇
component · born here
❒asset
# InspectionSession.component Board inspection controls for reset and pause. These do not implement skating movement.
▲ 0↑ born
◇
component · born here
❒asset
# Joint.component Typed body references, local frames and angular/linear constraint limits. `separateLinearFrame` enables an independent parent orientation for the three linear constraint axes: `linearFrameBX/BY/BZ/BW` is a unit quaternion in body B's authored frame. The angular axes still use `frameBX/BY/BZ/BW`. When disabled, linear axes follow the angular frame, preserving existing joints. JSON callers use optional `linear_rotation_b`; omission uses `rotation_b`. Both frames are converted through the body's mass frame before solving. The reconstructed character requires this distinction for all22 skeleton joints. The private121frame reference comparison checks every consumed frame word and the full96word constraint workspace for all2662joint states. Two unused anchor padding lanes are excluded from frame-byte comparison (native signed zero there does not enter the decoder); constraint workspaces still match bit-for-bit. This verifies joint-frame representation, not complete character simulation. ## Angular modes and independent speed limits `free` permits all angular directions selected by the joint. Native swing mode 3 is exposed as `hinge`, not `free`: it retains a constrained perpendicular axis. `limited_hinge` preserves native swing mode 2. Stock board wheel joints explicitly use `hinge` and retain their original speed allowances. Angular velocity allowances are independent relative-speed limits in radians per second. Zero is a zero-speed limit, not an unlimited value. New generic joints default to 1,000,000 rad/s so an open angular limit does not accidentally act as a brake. Explicitly authored values (including zero) remain authoritative. Migration: stock-board definitions using the former `free` spelling for native mode 3 must use `hinge`. Rebuild the provided scene after changing the kernel and component together. Old generic joints with explicit zero velocity allowances must be reviewed; do not overwrite intentional speed limits automatically. ## Native rider slots A Joint beneath NativeRiderDriver.constraintsRoot may reference two rider NativeActorPart entities from the same physicsRoot. Set world to that physicsRoot and nativeRiderSlot to 0..21. readRiderJointDefinitions() on a ready driver returns the current slot, endpoints, anchors and frames for authoring. Body A is the native child and body B its parent. Preserve the separate linear frame when copying definitions. Each slot may have one override; other slots remain native. nativeRiderAngular defaults to native: mode-dependent normal/ragdoll angular settings still come from the native owner. Select authored to use this Joint's angular fields instead. nativeRiderEnabled=false suppresses that slot's rows. Deleting the override restores the native slot. These edits survive R recovery. Animation drives remain active and can resist contradictory anchor edits. Mixed board/rider endpoints are explicitly unsupported by this adapter. A copied default slot passed the full 520-frame Zero replay unchanged. A 20 mm anchor edit produced approximately 19.1 mm in the ragdoll test; native mode limits, authored angular values, disabling, reset and restoration were checked.
▲ 0↑ born
❒
bundle · born here
❒asset
# BankRamp_100 Original Blender-authored modular skatepark part with static skate collision. Real-world meter scale, smooth geometry and PBR surfaces. 3 render meshes; 616 triangles. See the parent ModularPark README for dimensions and placement.
▲ 0↑ born
❒
bundle · born here
❒asset
# ConcreteTile_600 Original Blender-authored modular skatepark part with static skate collision. Real-world meter scale, smooth geometry and PBR surfaces. 1 render meshes; 300 triangles. See the parent ModularPark README for dimensions and placement.
▲ 0↑ born
❒
bundle · born here
❒asset
# DeckPlatform_150 Original Blender-authored modular skatepark part with static skate collision. Real-world meter scale, smooth geometry and PBR surfaces. 3 render meshes; 900 triangles. See the parent ModularPark README for dimensions and placement.
▲ 0↑ born
❒
bundle · born here
❒asset
# DownRail_360 Original Blender-authored modular skatepark part with static skate collision. Real-world meter scale, smooth geometry and PBR surfaces. 21 render meshes; 2,380 triangles. See the parent ModularPark README for dimensions and placement.
▲ 0↑ born
❒
bundle · born here
❒asset
▲ 0↑ born
❒
bundle · born here
❒asset
▲ 0↑ born
❒
bundle · born here
❒asset
▲ 0↑ born
❒
bundle · born here
❒asset
▲ 0↑ born
❒
bundle · born here
❒asset
▲ 0↑ born
❒
bundle · born here
❒asset
▲ 0↑ born
❒
bundle · born here
❒asset
▲ 0↑ born
❒
bundle · born here
❒asset
▲ 0↑ born
❒
bundle · born here
❒asset
▲ 0↑ born
❒
bundle · born here
❒asset
▲ 0↑ born
❒
bundle · born here
❒asset
▲ 0↑ born
❒
bundle · born here
❒asset
▲ 0↑ born
❒
bundle · born here
❒asset
▲ 0↑ born
❒
bundle · born here
❒asset
▲ 0↑ born
❒
bundle · born here
❒asset
▲ 0↑ born
❒
bundle · born here
❒asset
▲ 0↑ born
❒
bundle · born here
❒asset
▲ 0↑ born
❒
bundle · born here
❒asset
▲ 0↑ born
❒
bundle · born here
❒asset
▲ 0↑ born
❒
bundle · born here
❒asset
# FlatRail_360 Original Blender-authored modular skatepark part with static skate collision. Real-world meter scale, smooth geometry and PBR surfaces. 21 render meshes; 2,428 triangles. See the parent ModularPark README for dimensions and placement.
▲ 0↑ born
❒
bundle · born here
❒asset
# Funbox_090 Original Blender-authored modular skatepark part with static skate collision. Real-world meter scale, smooth geometry and PBR surfaces. 3 render meshes; 268 triangles. See the parent ModularPark README for dimensions and placement.
▲ 0↑ born
❒
bundle · born here
❒asset
# GrindLedge_045 Original Blender-authored modular skatepark part with static skate collision. Real-world meter scale, smooth geometry and PBR surfaces. 5 render meshes; 1,500 triangles. See the parent ModularPark README for dimensions and placement.
▲ 0↑ born
❒
bundle · born here
❒asset
# LaunchKicker_060 Original Blender-authored modular skatepark part with static skate collision. Real-world meter scale, smooth geometry and PBR surfaces. 2 render meshes; 500 triangles. See the parent ModularPark README for dimensions and placement.
▲ 0↑ born
❒
bundle · born here
❒asset
# ManualPad_020 Original Blender-authored modular skatepark part with static skate collision. Real-world meter scale, smooth geometry and PBR surfaces. 3 render meshes; 900 triangles. See the parent ModularPark README for dimensions and placement.
▲ 0↑ born
❒
bundle · born here
❒asset
# QuarterPipe_150 Original Blender-authored modular skatepark part with static skate collision. Real-world meter scale, smooth geometry and PBR surfaces. 12 render meshes; 1,700 triangles. See the parent ModularPark README for dimensions and placement.
▲ 0↑ born
❒
bundle · born here
❒asset
# QuarterPipe_225 Original Blender-authored modular skatepark part with static skate collision. Real-world meter scale, smooth geometry and PBR surfaces. 12 render meshes; 1,700 triangles. See the parent ModularPark README for dimensions and placement.
▲ 0↑ born
❒
bundle · born here
❒asset
# RoundRail_360 Original Blender-authored modular skatepark part with static skate collision. Real-world meter scale, smooth geometry and PBR surfaces. 21 render meshes; 2,380 triangles. See the parent ModularPark README for dimensions and placement.
▲ 0↑ born
△
mesh · born here
❒asset
# Mesh Mesh asset. `data.zmsh` is the engine-native geometry payload (`renderer.mesh.encode`); consumers reference the asset's guid.
▲ 0↑ born
❒
bundle · born here
❒asset
# Foundry Skatepark Connected 66x48m industrial courtyard with a banked pump circuit, stair/hubba/bank street sequence, recessed asymmetric shallow/deep skate bowl, vert halfpipe, wallride and optional ledge/manual lines. See ../../Foundry/README.md for the routes and measured rider tests. Detailed visible meshes use separate efficient native collision where needed.
▲ 0↑ born
❒
bundle · born here
❒asset
# StairSet_Five Original Blender-authored modular skatepark part with static skate collision. Real-world meter scale, smooth geometry and PBR surfaces. 6 render meshes; 1,552 triangles. See the parent ModularPark README for dimensions and placement.
▲ 0↑ born
❒
bundle · born here
❒asset
# StreetSkateboard_825 Original Blender-authored detailed skateboard with deck, trucks and four axle-pivoted wheels. Real-world meter scale, smooth geometry and PBR surfaces. 68 render meshes; 31,036 triangles. See the parent ModularPark README for dimensions and placement.
▲ 0↑ born
◇
component · born here
❒asset
# NativeActorPart Entity-owned native physical state exchanged with the full rider loop. Role and index identify the part; state contains its complete rates and inertia. Shape/constraint authoring integration is unfinished.
▲ 0↑ born
▣
module · born here
❒asset
# NativeAnimationBake <!-- zero:scaffolded-readme --> <!-- Replace the line below with what this module provides and who consumes it, then delete both comment lines. --> TODO: describe this module.
▲ 0↑ born
◇
component · born here
❒asset
# NativeAnimationBinding <!-- zero:scaffolded-readme --> <!-- Replace the line below with what this component provides and who consumes it, then delete both comment lines. --> TODO: describe this component.
▲ 0↑ born
▣
module · born here
❒asset
# NativeAnimationBindings <!-- zero:scaffolded-readme --> <!-- Replace the line below with what this module provides and who consumes it, then delete both comment lines. --> TODO: describe this module.
▲ 0↑ born
▣
module · born here
❒asset
# NativeAnimationCatalog Builds the preserved pose evaluator's input from ordinary Zero rig and animation asset references. Clips are decoded through Zero's own `skeleton.clipToTable`. Bindings retain loop transforms, channel weights and bank/reference-pose mapping. The native loader has no animation-bank fallback. This is a content boundary, not a completed playable rider controller or fidelity acceptance.
▲ 0↑ born
▣
module · born here
❒asset
# NativeAnimationMetadata <!-- zero:scaffolded-readme --> <!-- Replace the line below with what this module provides and who consumes it, then delete both comment lines. --> TODO: describe this module.
▲ 0↑ born
▣
module · born here
❒asset
# Native board assembly binding Place ordinary skate_physics.Joint entities and NativeTruckMotor entities beneath the driver's constraintsRoot. Joints reference the actor's board parts and its physicsRoot. Their order determines native constraint registration. The selected root replaces the six built-in board joints, so an empty joint list intentionally disconnects the board parts. With no constraintsRoot the original definitions remain active. With no motor entities, original truck dynamics remain active. The separate hook and rider constraints are retained. This interface currently addresses the seven board parts; it does not claim arbitrary actor topology.
▲ 0↑ born
◇
component · born here
❒asset
# Native body visual Add this to an ordinary visual entity under NativeRiderDriver.boardVisualRoot. Set body to a NativeActorPart belonging to that driver's board assembly. The driver supplies its interpolated position and rotation, coherent with the camera. Position/rotation offsets are in body space; visual scale remains authored on the entity. Do not put this component on the physical body itself. Model and Asset bundle content can be exchanged normally. An animated bundle may keep its own Zero animation components: this binding drives only the visual root, never its bones. It does not alter collision shape, mass or simulation. The current full actor exposes the seven board parts through this presenter.
▲ 0↑ born
▣
module · born here
❒asset
# Native environment Collects Zero entities into the full rider runtime's collision and grind inputs. Use static mesh Body entities and optional TerrainSurface metadata. GrindPath children supply native grind splines and explicit ledge-query segments. Geometry and poses come from the selected entities; no reference level is loaded.
▲ 0↑ born
▣
module · born here
❒asset
# NativeFootSurface Geometry-based visual foot correction candidates. This module does not alter physics and runs in NativeRiderDriver's interpolated presentation path when a footSurfaceMesh and footSurfaceBody are assigned. `new(parsedTargetRig, skinnedGeometries, surfaceGeometry)` caches foot-weighted vertices and inverse bind points. It indexes the surface triangles in an X/Z grid. Rig foot roles and hips are required. Supply ordinary Zero mesh geometry; no game files or host filesystem access are needed. `targets(freshPoses, toSurface, fromSurface, options)` returns model-space IK targets plus per-foot gap/overlap/correction diagnostics. Point transforms must be inverse affine transforms between rig model units and surface units. Surface Y defines the normal axis. The hips choose which side of the surface to use. Defaults: maxCorrection=.05 and clearance=0 in surface units. Deep penetration beyond the limit and separated feet receive no correction. This avoids turning IK reference-frame flags into planted-foot assumptions. Pass targets to NativeRigPose:solveFootTargets. It preserves shoe orientation, translations and scales while adjusting the leg rotations. Recompute from the fresh base pose; never feed corrected entity transforms back into this step. Live Zero geometry/pose checks: two 480-vertex feet, 712 projected triangles, about 2 ms per query after indexing in the measured session. The standing-pose 15 mm/3 mm penetrations reduced to about 5e-8 m; a 2 m separation produces no correction. The enabled rider preset also passed live standing, push/ollie/landing and inverted darkslide contact checks. Rig/mesh edit invalidation, broader rig variants and rendering performance across target machines remain to be verified.
▲ 0↑ born
◇
component · born here
❒asset
# Native ground execution boundary Calls the reconstructed complete `Ground::UpdateSkateboard` on existing Zero Body entities. It consumes explicit native records supplied by the controller/animation observation producer; it is not a standalone input controller. The live producer connection is still under development. Bind a World, active BoardFeedback and the two truck Drive entities. Supply the resolved numeric profile, native history after entry, current GroundBoardInput/physical observations and truck base frames. Set `entered` only after the native entry lifecycle has completed; update is refused before that. Enable only after all records are prepared. `inputTick` must match the World tick. Ground uses one substep per observation; stale records are refused. Full ground and standalone BoardSteering cannot own the same feedback binding. `forcesBefore` preserves any already-queued native point forces before this update appends its records. Every force uses the existing queue and native point-force consumer. Returned history, drive frames, material and linear drag publish on Zero components. No hidden body or second solver is created. Missing required wall-jump trajectory launch/update currently rejects the entire transaction; that provider remains required before this branch is usable. Never treat ordinary-ground success as proof of trajectory support. Reset restores the explicit controller history and drive frames with the body snapshot. The producer must prepare observations for the reset tick before resuming. ## Live body observation stage `inputSource` optionally supplies the shared native input-builder record instead of a complete `input` record. Each transaction derives current board motion, mass, wheel normal, contact flags and wheel count from its actual bodies and BoardFeedback. The original native mapping is retained: processed416 is ground-linear velocity; processed720 is angular velocity. `producedInput` exposes the generated record locally for inspection without entering the solver's retained state. Other observations still require real providers: animation/control attributes, reckoning/pose observations, lifecycle times, pumping and geometry/state-machine results. They must be prepared for `inputTick`; a diagnostic snapshot is not a continuous controller. The live clock/pose/control producer remains unfinished. ## Native input clocks An `inputSource.lifecycle` record supplies `captured_category`, `signed_ground_step`, and the one-tick `teleported` signal. The native input-clock owner then maintains ground duration, signed ground time, inactivity, teleport frames, spin history and crouch difference in `state.input_clocks`. It advances only in a submitted physics transaction and is restored with the normal World state snapshot. Without this optional record, externally supplied timing remains authoritative. The category/signed-step signals and per-frame flags must come from their real state/input owners. This does not perform physical Ground entry/exit, update its separate elapsed-state timer, provide pose/geometry observations, or make a continuous controller out of a captured context. ## Exit and observation Set `operation=exit` with current observations, an entered controller, `inputSource` (the pumping owner), and `standardWheelMaterial` containing explicit static/dynamic friction and restitution. The native exit resets steering history/pumping, clears all seven linear drags, restores wheel material and runs the original animated-velocity clamp when that branch is active. The result clears `entered` and changes `operation` to `observe`. Observe continues current input observation/history without applying Ground forces or writing wheel materials/drive targets. A separate BoardSteering may own those drives. Exit is required before observing an entered Ground controller. Update after exit is refused until real entry completes. Physical entry and continuous state selection remain under development. World.restoreState restores the saved drive frames and pumping state; current configuration and unrelated input-source fields remain owned by their producers. ## Explicit physical entry Set `operation=enter`, bind the existing `hookDrive`, and supply `entrySettings`: explicit `rider_mode`, previous category/state, deck angular drag, powerslide-exit scale, landing strength/offset, and the standard wheels/trucks/deck materials. Entry uses the real source/pumping state and current bodies. `rider_mode=none` means no simulated rider; no hidden body is created. `bound` currently refuses entry until the real Zero rider owners are connected. The shared native executor initializes physical rates/controllers, disables the actual hook drive, resets pumping/wipeout state and handles the manual/re-entry/landing-force branches. Standard collider enables and materials reach the current solve and the actual Body/CollisionVolume components. The native assembly class is retained separately from Zero's self-collision group. RestoreState restores collider flags and hook parameters and checks their topology first. This is body-only entry support, not completed rider-bound entry or a continuous gameplay controller. Fresh entry may use state `{}`; the kernel creates native initial history and then executes entry. Full update/exit still requires entered state. `inputSource.body_update` opts into the original Ground begin/pumping/prediction/finish sequence for an explicitly riderless rig with `pose.observation.mode="body_com"`. Pumping settings and selected mode remain authored inputs; history is retained in `state.body_update`. Bound-rider target owners and the normal command/geometry producer are not yet connected. This option alone is not a finished playable controller. `inputSource.kind="body_commands"` enables a fresh riderless producer. Supply native `settings`, `pose` (body_com) and `body_update` tuning. Current commands are the component's editable fields; callers need no captured input/physical record. For first entry, use state/input/physical `{}` and explicit entry settings. W/S/A/D mapping is available through InspectionSession.ground. This path is verified for live push/coast/brake/steer/reset, but sustained rest still fails validation and saved-default/installation acceptance is pending. The riderless `body_commands` source can now include `flight` settings for native Ground/Air selection, jump calculation, Air reckoning and the angular hook drive. Increment `jumpSequence` once per jump; `jumpStrength` selects the configured height response. Full rider/trajectory/trick integration remains unfinished.
▲ 0↑ born
▣
module · born here
❒asset
# NativePoseStream Adjacent completed tick interpolation shared by rider and camera.
▲ 0↑ born
·
inputmap · born here
❒asset
# Native rider controls The input map sends raw controller values to the full reconstructed controller. Trick recognition, pop, catch and landing remain in the native behavior pipeline. Keyboard: W push; X other-foot push; S brake; A/D steer; arrow keys right-stick directions; hold/release Space for down-to-up ollie; Z/C grab triggers; Q/E bumpers; F get on/off the board; R reset. Arrow-key flicks can be diagonal. Gamepad: left stick steer/body; right stick flicks and partial-deflection manuals; south/west push; east brake; north mount/dismount; triggers grab; bumpers native modifiers. Touch offers separate steering and trick sticks. Keyboard right-stick directions are digital. Analog manuals require a controller or touch stick. These bindings are editable entirely inside Zero.
▲ 0↑ born
◇
component · born here
❒asset
# NativeRiderDriver — Skate 3 rider and board integration Use this component for the integrated Skate 3-derived skating system in Zero. It connects the reconstructed native controller, physics and animation loop to Zero content and NativeActorPart state. Start from Samples.Rider or RiderFidelity rather than attaching a second movement controller to the same bodies. The driver coordinates board/rider bodies, terrain, inputs, constraints, visual models, rigs and animation bindings. It supports device input and normalized script commands, plus vehicle-only and self-propelled configurations. W/X push, A/D steer, S brakes, Space and the trick stick control tricks, and R recovers the initial setup. The native coupled layout uses seven board bodies and 26 rider bodies. See GettingStarted for supported joint/motor overrides, rig mappings and animation bindings.
▲ 0↑ born
◇
component · born here
❒asset
# NativeRiderMotor <!-- zero:scaffolded-readme --> <!-- Replace the line below with what this component provides and who consumes it, then delete both comment lines. --> TODO: describe this component.
▲ 0↑ born
▣
module · born here
❒asset
# Native rig pose Transfers live simulation poses through Zero humanoid role mappings and anatomical frames. Source and target rig assets remain editable in Zero. Bone lengths and local scales come from the target rig; source poses contribute anatomical orientation and pelvis motion. Non-humanoid content uses the direct pose path or its own presenter.
▲ 0↑ born
◇
component · born here
❒asset
# Native truck motor The front or rear motor's native linear/angular drive parameters. Native steering continues producing its target frame; these fields control how the motor drives toward it. Disable active to remove its drive response. The actor's separate animation-controlled hook and rider motors retain their existing behavior.
▲ 0↑ born
△
mesh · born here
❒asset
# 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.
▲ 0↑ born
·
animation · born here
❒asset
Original two-second balance motion authored for OriginalRiderRig; contains no retail animation samples. Geometry design derives from the project-owned skate.rider module, asset 2901eef4-ce5a-47a5-9788-96b39a9c135d. No retail mesh or animation bank is used.
▲ 0↑ born
△
mesh · born here
❒asset
# 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.
▲ 0↑ born
△
mesh · born here
❒asset
# 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.
▲ 0↑ born
·❒asset
# Anticipation_R_ANTIC_CROUCH_HIGHNOLLIE_L_0_INTO Authored motion `Anticipation_R_ANTIC_CROUCH_HIGHNOLLIE_L_0_INTO` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_ANTIC_CROUCH_HIGHNOLLIE_L_0_OUT Authored motion `Anticipation_R_ANTIC_CROUCH_HIGHNOLLIE_L_0_OUT` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_ANTIC_CROUCH_HIGHNOLLIE_N_0_INTO Authored motion `Anticipation_R_ANTIC_CROUCH_HIGHNOLLIE_N_0_INTO` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_ANTIC_CROUCH_HIGHNOLLIE_N_0_OUT Authored motion `Anticipation_R_ANTIC_CROUCH_HIGHNOLLIE_N_0_OUT` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_ANTIC_CROUCH_HIGHNOLLIE_R_0_INTO Authored motion `Anticipation_R_ANTIC_CROUCH_HIGHNOLLIE_R_0_INTO` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_ANTIC_CROUCH_HIGHNOLLIE_R_0_OUT Authored motion `Anticipation_R_ANTIC_CROUCH_HIGHNOLLIE_R_0_OUT` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_ANTIC_CROUCH_HIGHOLLIE_L_0_INTO Authored motion `Anticipation_R_ANTIC_CROUCH_HIGHOLLIE_L_0_INTO` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_ANTIC_CROUCH_HIGHOLLIE_L_0_OUT Authored motion `Anticipation_R_ANTIC_CROUCH_HIGHOLLIE_L_0_OUT` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_ANTIC_CROUCH_HIGHOLLIE_N_0_INTO Authored motion `Anticipation_R_ANTIC_CROUCH_HIGHOLLIE_N_0_INTO` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_ANTIC_CROUCH_HIGHOLLIE_N_0_OUT Authored motion `Anticipation_R_ANTIC_CROUCH_HIGHOLLIE_N_0_OUT` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_ANTIC_CROUCH_HIGHOLLIE_R_0_INTO Authored motion `Anticipation_R_ANTIC_CROUCH_HIGHOLLIE_R_0_INTO` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_ANTIC_CROUCH_HIGHOLLIE_R_0_OUT Authored motion `Anticipation_R_ANTIC_CROUCH_HIGHOLLIE_R_0_OUT` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_ANTIC_CROUCH_NOLLIE_L_0_INTO Authored motion `Anticipation_R_ANTIC_CROUCH_NOLLIE_L_0_INTO` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_ANTIC_CROUCH_NOLLIE_L_0_OUT Authored motion `Anticipation_R_ANTIC_CROUCH_NOLLIE_L_0_OUT` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_ANTIC_CROUCH_NOLLIE_N_0_INTO Authored motion `Anticipation_R_ANTIC_CROUCH_NOLLIE_N_0_INTO` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_ANTIC_CROUCH_NOLLIE_N_0_OUT Authored motion `Anticipation_R_ANTIC_CROUCH_NOLLIE_N_0_OUT` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_ANTIC_CROUCH_NOLLIE_R_0_INTO Authored motion `Anticipation_R_ANTIC_CROUCH_NOLLIE_R_0_INTO` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_ANTIC_CROUCH_NOLLIE_R_0_OUT Authored motion `Anticipation_R_ANTIC_CROUCH_NOLLIE_R_0_OUT` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_ANTIC_CROUCH_OLLIE_L_0_INTO Authored motion `Anticipation_R_ANTIC_CROUCH_OLLIE_L_0_INTO` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_ANTIC_CROUCH_OLLIE_L_0_OUT Authored motion `Anticipation_R_ANTIC_CROUCH_OLLIE_L_0_OUT` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_ANTIC_CROUCH_OLLIE_N_0_INTO Authored motion `Anticipation_R_ANTIC_CROUCH_OLLIE_N_0_INTO` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_ANTIC_CROUCH_OLLIE_N_0_OUT Authored motion `Anticipation_R_ANTIC_CROUCH_OLLIE_N_0_OUT` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_ANTIC_CROUCH_OLLIE_R_0_INTO Authored motion `Anticipation_R_ANTIC_CROUCH_OLLIE_R_0_INTO` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_ANTIC_CROUCH_OLLIE_R_0_OUT Authored motion `Anticipation_R_ANTIC_CROUCH_OLLIE_R_0_OUT` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_ANTIC_NOLLIE_L_0_CYC Authored motion `Anticipation_R_ANTIC_NOLLIE_L_0_CYC` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_ANTIC_NOLLIE_L_0_INTO Authored motion `Anticipation_R_ANTIC_NOLLIE_L_0_INTO` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_ANTIC_NOLLIE_L_0_OUT Authored motion `Anticipation_R_ANTIC_NOLLIE_L_0_OUT` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_ANTIC_NOLLIE_N_0_CYC Authored motion `Anticipation_R_ANTIC_NOLLIE_N_0_CYC` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_ANTIC_NOLLIE_N_0_INTO Authored motion `Anticipation_R_ANTIC_NOLLIE_N_0_INTO` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_ANTIC_NOLLIE_N_0_OUT Authored motion `Anticipation_R_ANTIC_NOLLIE_N_0_OUT` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_ANTIC_NOLLIE_R_0_CYC Authored motion `Anticipation_R_ANTIC_NOLLIE_R_0_CYC` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_ANTIC_NOLLIE_R_0_INTO Authored motion `Anticipation_R_ANTIC_NOLLIE_R_0_INTO` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_ANTIC_NOLLIE_R_0_OUT Authored motion `Anticipation_R_ANTIC_NOLLIE_R_0_OUT` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_ANTIC_OLLIE_L_0_CYC Authored motion `Anticipation_R_ANTIC_OLLIE_L_0_CYC` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_ANTIC_OLLIE_L_0_INTO Authored motion `Anticipation_R_ANTIC_OLLIE_L_0_INTO` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_ANTIC_OLLIE_L_0_OUT Authored motion `Anticipation_R_ANTIC_OLLIE_L_0_OUT` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_ANTIC_OLLIE_N_0_CYC Authored motion `Anticipation_R_ANTIC_OLLIE_N_0_CYC` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_ANTIC_OLLIE_N_0_INTO Authored motion `Anticipation_R_ANTIC_OLLIE_N_0_INTO` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_ANTIC_OLLIE_N_0_OUT Authored motion `Anticipation_R_ANTIC_OLLIE_N_0_OUT` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_ANTIC_OLLIE_R_0_CYC Authored motion `Anticipation_R_ANTIC_OLLIE_R_0_CYC` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_ANTIC_OLLIE_R_0_INTO Authored motion `Anticipation_R_ANTIC_OLLIE_R_0_INTO` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_ANTIC_OLLIE_R_0_OUT Authored motion `Anticipation_R_ANTIC_OLLIE_R_0_OUT` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_HIGHANTIC_NOLLIE_L_0_CYC Authored motion `Anticipation_R_HIGHANTIC_NOLLIE_L_0_CYC` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_HIGHANTIC_NOLLIE_L_0_INTO Authored motion `Anticipation_R_HIGHANTIC_NOLLIE_L_0_INTO` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_HIGHANTIC_NOLLIE_L_0_OUT Authored motion `Anticipation_R_HIGHANTIC_NOLLIE_L_0_OUT` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_HIGHANTIC_NOLLIE_N_0_CYC Authored motion `Anticipation_R_HIGHANTIC_NOLLIE_N_0_CYC` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_HIGHANTIC_NOLLIE_N_0_INTO Authored motion `Anticipation_R_HIGHANTIC_NOLLIE_N_0_INTO` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_HIGHANTIC_NOLLIE_N_0_OUT Authored motion `Anticipation_R_HIGHANTIC_NOLLIE_N_0_OUT` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_HIGHANTIC_NOLLIE_R_0_CYC Authored motion `Anticipation_R_HIGHANTIC_NOLLIE_R_0_CYC` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_HIGHANTIC_NOLLIE_R_0_INTO Authored motion `Anticipation_R_HIGHANTIC_NOLLIE_R_0_INTO` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
·❒asset
# Anticipation_R_HIGHANTIC_NOLLIE_R_0_OUT Authored motion `Anticipation_R_HIGHANTIC_NOLLIE_R_0_OUT` for the skating rider animation overrides. This clip supplies the named controller motion family through NativeAnimationBinding; it is separate from the default reference animation catalog.
▲ 0↑ born
backing path · skate_physics.package

Problems

Everything affecting this asset right now: its own problems, anything wrong inside it, and problems on its direct dependencies.

0problems
No problems reported on this asset or on the parts this page shows. Parts it leaves out are not counted here.
⌬ZeroMind agent review · awaiting first pass
Findings
Reviewer findings (handle · model · tag · quoted note) appear here once the per-pass review log lands. Today only the rolled-up agent_score is exposed.
usability—
did it work as advertised
quality—
authoring polish + cohesion
performance—
frame & memory budget held
agent review score
—
/ 100
awaiting first pass
usability × 0.40
+ quality × 0.35
+ performance × 0.25
± compat factor

Usability ratings

Did the part work as advertised when consumers tried to drop it in. Separate from upvotes: those are taste; this is "did it function".

—%no reports yet
Sign in to report whether this part worked for you.
Discussion

Scoped to this part · feeds back into the world's score.

0comments
Sign in to post.sign in
No comments yet. Be the first.