Kinewright is a house of motion engines. Humans is the first engine. This article is the plan for that engine as it stood in September 2026, written down once and left as it is: what the engine does itself, what it deliberately takes from outside, which published data it leans on and how that data is allowed in, and what was planned to happen before each next step.
I will not update this article. It is the starting point, kept so that later changes can be read against it. The living version is the pinned post on r/Kinewright; it changes when a stage closes or the order moves. And the order does move, not only by my decision: I posted the first video, a reader said the torso looked held, we checked, agreed, and a correction that was not in the plan went in front of the next stage the next day. That is the kind of change this article is a baseline for.
There are no dates in it, on purpose.
One sentence, one level
Humans turns a supported body, a motion skill, scene constraints, a motor style, a seed and time into a canonical stream of three-dimensional poses, contacts and events. It produces motion state, not pixels.
Its level at the time of writing is kinematic. Gravity, ballistic flight and the lean of a braking body are used as identities with a known source; nothing is dynamically simulated, and no balance or physical validation is claimed. Every step below names the highest claim it may make on one ladder:
| Level | Meaning |
|---|---|
| Kinematic | poses and contacts meet declared geometric and timing checks; this does not establish forces or physical validity |
| Physics-informed | kinematic motion shaped by named physical identities, without simulation or balance claims |
| Static balance checked | projected centre of mass and support polygon pass declared quasi-static checks |
| Dynamically checked | momentum, contact forces, centre of pressure or capture-point reasoning pass declared checks |
| Simulated on | a named slice ran on a named dynamics provider build |
| Hardware validated on | validated on exactly named hardware through a separately proven physical stack |
A motion that passed a kinematic or visual gate is never described as physically validated. The accepted locomotion sits at physics-informed; the stages that follow are kinematic.
What the engine owns, and what it is meant to own
At the start the implementation centres on one reference body's locomotion, contact timing, command handling and replay. General body compatibility, marker-based warping and a durable runtime journal are contracts on the plan, not capabilities the first video demonstrates.
Intent. Commands, their order, a fixed tick. A command is answered at a declared safe boundary, never mid-air by accident.
Contacts and their owners. Which foot is on the ground, when, where; who owns each contact when something else is involved.
Markers and admissible warps. The named moments a motion may be cut, joined or warped at (touchdown, toe-off, takeoff, landing) and by how much.
Capabilities and honest answers — planned contract. Each skill–body pairing is intended to resolve to native, adapted, fallback or unsupported with a diagnostic. At the start there is one supported body, not a delivered general compatibility platform.
Expected supports. What the engine believes holds the body up.
Diagnostic truth and replay. Silent NaN, silent target dropping and undocumented clamping are treated as violations. Identical versions, body, scene, configuration, initial state, seed and ordered commands at the same fixed time steps must replay the same motion state; this does not promise identical pixels across renderers or arbitrary future physics backends.
Concretely that is the rig and its limits, forward kinematics and a bounded solver, the locomotion profiles (cadence, step, duty factor, timing of contacts, root motion, start, stop, transitions), the scheduler, and the renderer-adapter boundary.
What it will consume, by design
The list is finite on purpose. An infinite adapter list cannot define readiness, so every item here has a named slice and a named claim.
Physics. Not written here. An optional dynamics provider owns dynamic realization, collision response, external impulses and stability enforcement under an explicit ownership contract with seven named handoffs (grounding and support, collision queries and responses, carried-object authority, grasp and release, external impulses, replanning and fallback, deterministic replay and diagnostics). The actor stays the kinematic authority by default; a provider may own named objects and, only under an explicit handoff, named body parts. When animation intent and physics disagree, the contract names the owner of every contact; nothing is resolved silently. First provider candidate: Rapier, one slice.
Rendering. The engine does not draw. What the videos show is a plain Canvas 2D reference renderer projecting the canonical 3D state. First real lane later: Three.js with glTF/GLB transport. Renderer bone names, camera assumptions and drawing styles never leak into the motion model.
Avatars and retargeting. A generic humanoid mapping first, then VRM 1.0 and VRMA conformance. Having a specification does not license an asset; each avatar is its own rights question, and no automatic retargeting is promised.
Navigation. Recast/Detour for paths and corridors. The engine keeps the footholds and the body heading.
The scene. A small contract: named surfaces, affordances such as "seat", "grasp" or "ground", target transforms, and collision or reachability only when a backend provides it. The engine never guesses that a mesh is a chair, and ground is not implicitly at zero; the scene says where it is.
Input, game engines, motors. Adapters. DOM events and frame timing are adapter inputs, not scheduler state. The engine is not a game engine and will never claim it drives a robot from a browser; physical embodiment needs a separately proven stack and is a far-future, optional direction only.
Workers, WASM or WebGPU come only after a measured hotspot at 1, 16, 32 and 64 actors. Other renderers or physics backends come when someone actually needs them.
Where the data comes from, and how it is allowed in
The engine core ships no third-party data. Every number taken from a dataset lives in a separate pack under the dataset's own licence, with the exact artifact and its hash pinned. Retargeting, smoothing, fitting or changing the file format does not wash away an upstream obligation. Nothing is admitted because it appears in a paper or in another engine.
Every constant carries a status: measured, aggregated, derived, engineering or estimated. Nearly every constant in the core at the start is an engineering choice, and it is labelled as one; "measured" is reserved for what a source actually reports.
In use at the start
| Source | What it provides | Licence |
|---|---|---|
| NIOSH firefighter anthropometry, RD-1007-2015-0 (951 US firefighters, 2008–2012) | body proportions as fractions of stature for the one supported body; silhouette anchors | US public domain |
| Fukuchi et al., walking biomechanics dataset v5 (WBDS; PeerJ 4640) | sagittal pelvis, hip, knee and ankle curves of treadmill walking | CC BY 4.0 |
| Fukuchi et al., running biomechanics dataset v5 (RBDS; PeerJ 3298) | duty factor and knee-flexion anchors at 2.5, 3.5 and 4.5 m/s; one of the sources shaping the product run | CC BY 4.0 |
| The same RBDS raw markers | spatial curves and reconstructed joint centres, used at the application's carrier layer | CC BY 4.0 |
| Riglet et al. 2024, run/walk 3D motion dataset v1 (Scientific Data) | four arm-relative channels in steady running; not a thorax or root-motion prior | CC0 |
Research and validation inventory — not runtime carriers
Reznick et al. 2021, continuously varying locomotion (walk↔run transitions; Scientific Data; CC0). Biancardi, Lagos-Hausheer and Bona, treadmill walking, running and transitions (Dataverse 10.60895/redata/PK1DCE; PeerJ 18162; CC BY 4.0). Calisti et al., countermovement-jump landings (dataset v1; CC BY 4.0). Two anthropometry sets are recorded as candidates with nothing extracted. Independent review of the three motion packages above was still pending at the time of writing; listing them is not a claim of completed runtime admission.
Method references, reimplemented without importing coefficients
Hof 2005 (the extrapolated centre of mass, ξ = x + v/ω₀); Wang and Srinivasan 2014 (pelvis state predicts the next lateral foot placement); Kwon et al. 2023 (planned stopping begins braking before the final contact); Mesquita et al. 2024 (curved running: straight flight, redirection owned by stance); Oosterwaal et al. 2016 and Arnold et al. 2017 (the foot is not one rigid block); Hof, Pratt and Vukobratović for capture point and zero-moment point, held for the balance rungs of the ladder. In every case the gain, cap or eligibility rule is an authored engineering control, not a claim about the publication.
Deliberately not used
AMASS and SMPL (non-commercial terms: no clips, retargeted motion, fitted tables, embeddings or weights may enter a release); the CMU motion-capture database (broad reuse, but not MIT or CC0); one curved-running dataset whose licence was never declared. The engine will not ship identity reconstruction, gait identification or demographic classifiers, and population labels describe source evidence, never a "personality preset".
Ranges we read our results against
When we look at a motion we compare its figures with published adult ranges, and those ranges stay in the record; they never enter the engine. Trunk obliquity and rotation in gait (Crosbie et al.), pelvic rotation in walking and running, thorax–pelvis coordination versus speed.
The plan as it stood: stages and dependencies
A step gets a size only after its definition of ready is frozen. Sizes here are the kind of work and a rough band in engineering passes and owner looks: planning envelopes, not a calendar.
| # | Step | What it delivers | Kind of work | Band |
|---|---|---|---|---|
| ✓ | Forward locomotion | steady walk, steady run, walk to run, run to walk | cycle synthesis, contacts and seams, arm swing, a blinded braking-lean ladder | closed; five review packets |
| ✓ | Stand, start, stop and command interruption | stand, start as the release of stop, stops from a walk and a run, commands answered at safe boundaries; one named condition carried forward (the hard landing foot on the last braking steps) | thirteen lanes behind gates, eleven review packets | closed; about a month |
| 1 | Runtime step planner | the next step planned at runtime instead of a precompiled track: a tap gives exactly one step, stop during start, shift back and forth mid-transition, a landing foot that arrives like the walk's | a small runtime substrate (descriptor, fixed tick, ordered commands, deterministic random streams, durable event journal) and the planner on it; steady walk and run byte-identical, transitions re-accepted | medium; up to 3 looks |
| 2 | Playable controller | WASD, Shift and Space on the planner: desired speed and response policy, contact-safe steering, a camera that does not feed back | policy, steering, input contract, arena | medium |
| 3 | Closing the foundation | continuity across the whole chain of states and reversals; visible feet and hands (renderer only, no new joints); directional readability; one integrated review of everything | gates, a renderer branch, a full packet | medium to large; several looks |
| 4 | Jump family | standing, walking and running jumps on the planner, ballistic flight as an identity | markers, bounded warps, contact schedules | medium; one batched look |
| 5 | Core boundary and first adapter | intent, tick, pose frame, events, snapshot and replay behind a renderer-neutral seam; a thin Three.js + glTF/GLB adapter; capability contract v0 | architecture discipline, not a public API | small |
| 6 | Skill platform and scene objects | stable skills, a broader transition realizer, scene objects that are explicitly not physics yet | platform | medium |
| 7 | Body compatibility and functional hold | other bodies with honest native/adapted/fallback/unsupported answers; holding an object with real grip semantics before any grasp claim | contracts and conformance bodies | unsized until its definition |
| 8 | Articulated hands | wrist, thumb and digits; grasp and release from a named taxonomy | a rig revision and a rerun of every earlier gate | unsized |
| 9 | Catalog waves | roughly 20 everyday actions, then 60, then 100 | skills, in waves | large |
| 10 | Multi-actor | two actors, then 4–12, then dozens; coordinated interaction sessions; a deterministic scene director with no language-model planner in the first version | isolation, sessions, a 1/16/32/64 benchmark | large |
| 11 | Integrations | generic humanoid + VRM/VRMA; the Rapier slice; the Recast/Detour slice | interleaved with catalog and multi-actor work, not postponed until both finish | bounded slices |
| 12 | World profile, static balance, dynamics contract | gravity, friction and mass with provenance; balance as a claimed capability; the seven handoff contracts with a provider | contracts and evidence | unsized |
| 13 | Full-scene gate | a 32-actor reference world, a 64-actor stress test, a truthful capability matrix | evidence at scale | gate |
| 14 | Public engine gate | clean-room packages, a public API, versioning and migration policy, documented limitations, notices | hardening | gate; opening the code is a separate decision |
Corrections between stages are not rows of this table. The pelvis and chest coordination pass now in progress, started by the first outside comment on the first video, is one of those: a fix inside the accepted foundation, tracked in the pinned post, not a stage of the plan.
The numbering groups work; it is not a strictly serial schedule. Avatar integration can overlap the first catalog and multi-actor work. The dynamics ownership contract comes before the Rapier slice, and that slice before catalog actions requiring dynamic objects. Navigation integration comes before the crowd/navigation stage. Coordinated two-person interactions likewise depend on their multi-actor contracts.
Optional and outside the main envelope: bounded seeded variation (cadence, step, arms, gaze and breathing with correlated memory, never per-frame noise and never contact drift), toe articulation, compensatory motion for missing or alternate limbs, dynamic plausibility checks, and physical embodiment.
A second comment on the same video already points at one of those optional items: the motion looks "too perfect", a human would not repeat the same action. That repetition is real and deliberate at the start, because the accepted cycles are the regression anchor of everything built on them; the answer to it is the seeded-variation item, and whether it moves up the list will be a decision recorded with its reason, visible in the pinned post, not here.
What this article is not
It is not a promise of dates. It is not a physics claim; the ladder above is the only vocabulary for that. It is not a code release; that is a separate decision with its own gate. It does not describe the second engine of the house, which gets its own map. And it is not the current plan: it is the plan at the start. Outside feedback is research input we measure against; a change of order is a decision recorded with its reason; both show up in the pinned post on r/Kinewright, which is the only version of this map that moves.
How to help
Watch the clips, answer the two questions — does it respond the way you expect, does it look natural — and say what you saw. The torso correction now in progress exists because one reader did exactly that, and this article exists so that the next such change has something to be read against.
Top comments (0)