Reality Kosmos Engine

Build a reality,
not a scene.

An experimental 3D engine written in Rust on wgpu. Prototype games, a film player, character labs and an editor run on it, and agents can drive it over a headless protocol.

Pocket Meadow running in the engine: a pink bunny, a fox and an orange friend in a park with a fountain, with a Japanese dialogue line at the bottom
Pocket Meadow in the engine. Real capture from kosmos-engine, 16 Oct 2026.

What it is

Experimental. Started on 15 October 2026.

Kosmos Engine is a 3D engine in Rust. Its README calls it a third backend beside PlayCanvas on the web and Godot in the Yakopop repository. The plan of record asks for a fixed-tick, seeded, replayable simulation, everything stored as text, and a headless mode, so that people and AI agents can build and test with the same commands.

It is a private repository today. The games below are prototypes, not products.

Language
Rust, edition 2024
Renderer
wgpu 30.0.1 (Metal, Vulkan, DX12, WebGPU)
Workspace
45 crates plus runner apps
Runners
Native window, headless CLI and MCP, browser runner in the repo
Browser build
Code exists, no public build found
Licence
MIT OR Apache-2.0

Sources: kosmos-engine README.md, Cargo.toml, rust-toolchain.toml, docs/plans/rust-engine.md, apps/kosmos-web. Counts taken 24 Oct 2026.

Pocket Meadow in the engine: two mochi characters on grass, a fountain and a dialogue box.
Kamikin on the engine. Capture of 16 Oct 2026.
Kosmica prototype in the engine: a village square with a quest list, a compass and a dialogue box.
Kosmica prototype, HUD on the native painter. Capture of 16 Oct 2026.
The engine editor: a scene tree, three coloured cubes in the viewport and an inspector.
The editor with the cube demo scene. Capture of 16 Oct 2026.

Captured from the native app (kosmos-app), not from a browser. Source: kosmos-engine reports/.

Features

What the engine does today and what is only planned, from the crates, the plans and the reports. A badge says how far each one is. Nothing here is a shipped product.

In detail: The UI, Workshops, Physics, Airships, Previs and games, Animation, Character Studio, Effects.

  • Replayable simulation tested

    Fixed tick of 1/64 s, seeded random numbers, a state hash, snapshot, restore and replay. CI compares the hash of native builds with the wasm32 build under wasmtime, and on macOS.

    Source: kosmos-core, kosmos-sim, .github/workflows/engine.yml, engine-matrix.yml.

  • wgpu renderer prototype

    Flat, toon and PBR looks, shadows, sky and clouds, grass, water, motion blur and an HDR tone map, with 54 JSON schemas for the data around it. Shaders are WGSL files in the repo.

    Source: crates/kosmos-render/src, schemas/, looks/.

  • Headless protocol prototype

    Typed JSON messages over stdio or WebSocket, a typed TypeScript client, and an MCP server over the same protocol. The step request is the only thing that advances the sim.

    Source: kosmos-protocol, apps/kosmos-cli, packages/kosmos-protocol-sdk.

  • Editor prototype

    An egui editor inside the native app: scene tree, inspector, gizmos, undo, and a list of labs. See The UI below.

    Source: apps/kosmos-app/src/editor, kosmos-cmd.

  • HUD in TypeScript prototype

    Solid components run on Hermes and drive a retained HUD tree that the app paints natively. See Architecture.

    Source: crates/kosmos-host, kosmos-ui, games/kosmica-real.

  • Characters and faces prototype

    Animation graph, 45 face channels, a face plate for heads without morph targets, wardrobe arithmetic, a mochi importer and glTF morph targets.

    Source: kosmos-anim, -face, -faceplate, -wardrobe, -model.

  • Film, subtitles, audio prototype

    Compiled film timelines with camera, actors, subtitles and cues. Cue-driven audio over kira, and a client for a local text-to-speech server.

    Source: kosmos-film, kosmos-audio.

  • Assets prototype

    A content-hashed cache with hot reload, and importers for glTF, FBX, OBJ and mochi. Mesh writers for STL, PLY, OBJ and 3MF, and a KTX2 writer.

    Source: kosmos-assets, kosmos-model, kosmos-meshops, kosmos-texops.

  • Physics prototype

    Rapier colliders, queries and a character controller. A rigid-body world exists but no app uses it. See Physics below.

    Source: crates/kosmos-physics.

  • Airships prototype

    Flight, decks, docking, sway and a planet to land on, checked against numbers from the web code. See Airships below.

    Source: crates/kosmos-airship.

  • Browser runner unverified

    A wasm and WebGPU runner builds a single canvas of the default scene. No public build was found and no browser frame time is measured.

    Source: apps/kosmos-web.

  • Networking, game scripting in wasm planned

    Named in the plan (kosmos-net, wasm components). No such crate exists. The plugin crate is data-only.

    Source: docs/plans/rust-engine.md, crates/kosmos-plugin.

  • Mobile and consoles not found

    Nothing in the repository targets iOS, Android or a console. The consoles idea belongs to the Godot work in Yakopop.

    Source: searched Cargo.toml and CI files.

Support matrix

Platforms, backends and formats. Tested means a run in the reports or in CI.
TargetStatusEvidence
macOS, Metal, Apple M3 MaxTestedParity and frame-time reports
Linux, Vulkan on lavapipe (software)Tested in CIRender goldens in engine.yml
Linux, native against wasm32 hashTested in CIengine-hash job
WindowsUnverifiedA CI build job exists, its scope was not read
Real-GPU Vulkan, DX12UntestedOffered by wgpu, no report
WebGPU in a browserUntestedRunner code exists, no public build
Audio: CoreAudio, WASAPI, ALSA, Web AudioUntestedListed by the audio crate through cpal
GamepadsUnverifiedgilrs is a dependency, no test seen
Scene JSON, schemasTestedGoldens under tests/
glTF import and export, mochi importImplementedkosmos-model, tests/golden
FBX, OBJ importImplementedDependencies fbxcel, tobj. Coverage not read
Godot scenes or GDScriptNot foundNo importer in the model crate
iOS, Android, consolesNot foundNo target in the repository

Sources: kosmos-engine .github/workflows, Cargo.toml, crates/kosmos-model, kosmos-audio, apps/kosmos-web. Read 24 Oct 2026.

The engine editor showing the Ball worlds lab: a list of labs on the left, controls beside it, and a small green round planet with trees and a path in the viewport.
Editor with the Ball worlds lab. Capture of 17 Oct 2026.

The UI prototype

The editor lives inside kosmos-app and is built with egui. It has a left rail of views, a scene tree, an inspector, gizmos, a bottom output panel and a list of labs, each lab a small playable page. Commands go through typed edit commands with undo and redo.

The editor has three themes: Dark, Kosmica and a Godot HUD theme taken from Yakopop's tokens. Headless UI tests drive the widgets through their accessibility labels. An older Solid and Vite dev UI is parked. A separate Watch view is described in a plan and was not checked.

Source: apps/kosmos-app/src/editor, docs/themes/godot-hud.md, apps/dev-ui/README.md, reports/labs-ball.png.

The Kamikin studio on this site: a list of options on the left, and a brown fawn mochi character with large ears on a cream background.
Kamikin studio on this site. Capture of 24 Oct 2026.

Workshops prototype

The word covers two things. On this site the Workshops are three studios for building a character: a Kamiji hand, a Kamikin mochi and an emoji face. They run on three.js in the browser, not on the Kosmos renderer.

In the engine, labs are the working equivalent: more than 40 lab files in the editor, such as broom, hoverboard, mecha, dragon, wardrobe and airship. A draft plan of 17 Oct 2026 proposes one workshop space per area on the editor rail. It says nothing in it is built, so treat that part as planned.

Open the Kamikin studio

Source: site/workshop/studios.js, kosmos-engine docs/plans/workshops.md, apps/kosmos-app/src/editor/lab_*.rs.

The Broom lab in the editor: a small character on a broom over a flat lilac meadow with hills and floating rings in the distance.
Broom lab, which asks the physics crate for the ground. Capture of 17 Oct 2026.

Physics engine prototype

The physics crate wraps Rapier 0.36.1 with its enhanced-determinism option and no threads or SIMD, so results depend only on the scene. It has static colliders, ray and shape queries, and a kinematic character controller. A stepped rigid-body world exists, but no sim or app code uses it. Its gate is a hash case that must match between native and wasm.

The broom, mecha, capture and ball labs and the HUD world queries use the static part. Vehicles are a separate arcade handling model ported from the web code, not Rapier. No buoyancy or water physics and no ragdoll were found. The flesh crate does cosmetic soft chains only. The one measured number is crowd steering: 300 people took 1.25 ms per tick, against 9.2 ms for the TypeScript version on V8. The capture shows a lab that uses the ground queries, not colliders drawn.

Source: crates/kosmos-physics/src/lib.rs, kosmos-vehicle, kosmos-flesh, reports/parity-frametime.md, reports/labs-broom-rider.png.

The Airship lab: a wooden galleon hung under four striped balloons flying over the curved horizon of a planet, with a flight readout at the top.
Airship lab, the Heron galleon, 1 of 41 designs. Capture of 18 Oct 2026.

Airship support prototype

The airship crate ports the web game's flight model, deck geometry and walking on a moving deck, sway and rope, docking and landing, the globe maths and part of the Terra planet. Each part is checked against numbers from the TypeScript, and the hashes match between native and wasm. A loader reads 41 of 42 baked ship designs, and an Airship lab in the editor flies them.

Not done, per the plan of 18 Oct 2026: rigging and livery, sails in the lab, the race lab, and Terra roads and rivers. The sail rigging study lives in a Yakopop worktree. The port does not use a physics engine. Flight is a formula, not a simulation of air.

Source: crates/kosmos-airship, docs/plans/airship-port.md, yakopop-sails docs/plans/sail-rigging.md, reports/labs-airship-ships.png.

The engine editor on its Timeline tab with a film loaded: tracks for camera shots, two actors, dialogue lines and a title card, laid out along a time ruler of about 25 seconds.
Timeline tab with the demo film. Capture of 18 Oct 2026.

Previs and game development prototype

Previs, short for previsualization, is the planning stage before final production: you block out shots, cameras, staging and timing, then cut them into a rough timed version (an animatic) to judge the sequence before anything is polished. Dedicated tools exist for that job. Kosmos is not one of them. It has several parts a previs workflow needs, in an engine where the same data can also become a game.

A film in the engine is a compiled timeline: a list of scenes, each with tracks of timed events for camera shots, actors, dialogue and subtitles, cards, fades and sound cues. Every channel is a pure function of time, so the film can be scrubbed, skipped and played frame by frame with the same result. The editor shows those tracks on its Timeline tab.

Source: crates/kosmos-film/src/lib.rs, schemas/film.schema.json, apps/kosmos-app/src/editor/timeline.rs, reports/timeline-film.png.

Previs: what is there

  • Shots and cameras prototype

    The film player outputs a camera as position, look-at, field of view and roll, with shot cuts, transitions and accents. The demo film in the capture cuts through eight shots, from fixed and medium to over-the-shoulder and close.

  • Staging and actors prototype

    Each actor has an acts track that sets animation parameters on the engine's own characters, plus hands and face from the film data. Staging uses the same models and rigs as the games.

  • Timing, subtitles and cues prototype

    Time runs on the sim's 64 Hz tick. A frame carries the subtitle line, a card, a fade, light and screen effects, and the cues that fire in that tick: a line begins, a sound, a cut.

  • Agents can drive it prototype

    The headless protocol steps the sim, applies typed scene edits and takes screenshots on a build with rendering, over stdio, WebSocket or MCP. That film playback is exposed through the protocol was not checked.

  • Animatic export, shot lists not found

    No video, image-sequence or shot-list export, and no previs mode, was found. Films are compiled from sources written outside this repository, so the editor reads them rather than authoring them.

Game development: what is there

  • Scenes and assets prototype

    Scenes are JSON that can be parsed, written, diffed and resolved from prefabs. Models come in through glTF, FBX, OBJ and mochi importers, with a content-hashed cache and hot reload.

  • Character controller and physics prototype

    A kinematic character controller and ray and shape queries on Rapier, plus a walker for round planets. See Physics above.

  • HUD and input prototype

    A retained HUD tree painted natively, driven by TypeScript on Hermes. An action map handles rebinding and input recording.

  • Replay and tests tested

    The fixed tick, state hash, snapshot and replay let a game run the same way twice. CI checks the hash on native and wasm.

  • Games prototype

    Kamikin and Kosmica run on the engine as prototypes. No public game build and no player-facing packaging step was found.

Sources: kosmos-film, kosmos-scene, kosmos-model, kosmos-assets, kosmos-physics, kosmos-ui, kosmos-input, kosmos-protocol, docs/plans/kamikin-port.md, .github/workflows. Searched for ffmpeg, mp4, animatic and previs in crates, apps, docs and tools: no match.

Animation and rigging prototype

Skeletons, clips, faces and hands. The graph and importers are in the crates. The Faces section below covers the face channels in more detail.

  • Animation graph prototype

    A data file (*.anim.json) holds a state machine, one-dimensional blend trees, crossfades and masked layers over the skinned clips of a character. Fed the fixed tick, a pose is a pure function of its inputs. The crate also has two-bone and FABRIK reach, spring follow-through and crowd walking.

  • Rigged characters prototype

    Skinned models with a skeleton, named clips and clips retargeted by bone name from a donor model. The editor has a Rig lab, which plays a quadruped rig through moves and attacks with effects, and a rig registry that marks some rigs as partial.

  • Face channels and morph targets prototype

    45 face channels, morph targets carried through glTF, and a face plate for heads without them.

  • The Kamiji hand rig prototype

    The Kamiji hand model is among the engine's assets, and the editor builds finger grids from a skeleton's finger chains with curl and spread controls, so a hand with six fingers gets six columns. The hand library on this site is a separate three.js and React build.

  • Mochi importer prototype

    Turns an exported mochi (skinned body, face shell, baked motions, six face states) into the same model type as glTF import. The Kamikin cast loads this way.

  • glTF import and export prototype

    Meshes, skins, clips and morph targets in and out, with golden files under tests/golden.

  • FBX unverified

    Binary FBX import reads meshes, normals and UVs. Its source says node transforms, materials, skins and animation are not read yet. A writer exists too, and its coverage was not read. OBJ, Collada, USD, STL, PLY and 3MF readers are in the model crate.

  • Motion capture, ragdoll not found

    No capture or BVH importer was found. The physics crate names ragdoll only as not built.

Sources: crates/kosmos-anim/src/lib.rs, ik.rs, crates/kosmos-model/src (fbx_import.rs, gltf_import.rs, mochi_import.rs, anim.rs), apps/kosmos-app/src/editor/rig_hands.rs, lab_rig.rs, assets/models/kamiji. Read 25 Oct 2026.

The Character studio in the engine editor: a panel with Body, Clothing, Library and Pose tabs and a list of body bases, beside a grey stylised woman wearing a beret on a green ground.
Character studio in the editor, a stylised base with a beret. Capture of 19 Oct 2026.

Character Studio prototype

The character builders exist in two places. In the engine, the Character studio lab is one page for a character: a body, head shape, hair plates, clothing and a pose. Garments are shells cut from the body's own skin, so they follow the same bones. Hair guides sway with the head, and the ears of the animal-eared characters flop with its movement. The lab's own file marks its status as work in progress.

On this site the Workshops are the character builders you can open now, and the demo further down this page lets you pick a Kamikin, a face and a clip. They run on three.js, not on the Kosmos renderer.

Hand studio, Kamikin studio, Emoji studio, Try a character

Source: labs/character/lab.json, apps/kosmos-app/src/editor/lab_character, crates/kosmos-wardrobe, site/workshop/studios.js, reports/labs-wardrobe-studio.png.

In the engine

  • Bodies and sliders prototype

    Sculpt bases and rigged bodies to start from, with shape sliders for girth and length per bone, ported from the Yakopop wardrobe code.

  • Wardrobe prototype

    Shell garments, hiding what clothes cover, atlas merging, outfits and static garments fitted onto a model.

  • Saving and exporting a finished character unverified

    A character file with a sparse sculpt layer exists. Whether the studio writes out a finished, dressed model was not checked.

On this site

  • Hand studio prototype

    Build a Kamiji hand: tint, face, pose, shape and halo.

  • Kamikin studio prototype

    Pick one of 14 mochi, then a face, a clip and a tint.

  • Emoji studio prototype

    Make a character from a 3D emoji face.

Particles, liquid and fabric

What exists for effects and soft things, taken from the crates, the plans and the reports. Particles are built and drawn. Water is a flat rendered sheet. A liquid simulation and simulated cloth are plans with no code.

  • GPU particles prototype

    A compute runtime in kosmos-fx reads the web effects library: all 58 effects and 1628 emitters parse, 20 sprite shapes draw, and the GPU motion matches the CPU reference. One million simple particles stepped in 0.197 ms of GPU time on an M3 Max. They are drawn in the editor's lab viewport over the scene, without depth testing. The plan lists joining them to the main render pass as open, and no particle pass was found in the renderer's frame graph.

    Source: crates/kosmos-fx, apps/kosmos-app/src/editor/lab_fx.rs, docs/plans/fluid-vfx.md (F0, F1).

  • Particle lighting and collision prototype

    Billboards are lit by the sun and the lamps. Particles can stop or bounce on static triangles, and a CPU test marches light through a uniform density slab. All of it is visual only and never enters the state hash.

    Source: kosmos-fx light.rs, ballistic.rs, volume.rs, kosmos-render particle_light.rs.

  • Water surface prototype

    The renderer has a water sheet: a grid whose height moves with time, drawn only when a look asks for it. It is not a simulation, and the Kamikin port does not use animated water yet.

    Source: crates/kosmos-render/src/water.rs, water.wgsl, docs/plans/kamikin-port.md.

  • Liquid simulation planned

    Pouring, splashes, rivers and waterfalls are steps F3, F6 and F7 in the fluid plan. No fluid solver exists in the crates: the fx crate holds particles and a density march only. Buoyancy and water physics were not found either.

    Source: docs/plans/fluid-vfx.md, crates/kosmos-fx, kosmos-physics.

  • Rope, cape and tail solver prototype

    A cosmetic XPBD solver for ropes, capes and tails sits in kosmos-flesh with a golden file and two tests. No app code calls it yet. The character studio uses the same crate's springs for ear and tail jiggle.

    Source: crates/kosmos-flesh/src/xpbd.rs, jiggle.rs, tests/golden/rigs/xpbd.json.

  • Cloth, garments in motion, soft bodies planned

    Garments are static shells on the skin. Airship sails move by formula and are not cloth. A cloth decision record and jelly-like soft objects are planned and unbuilt.

    Source: docs/plans/flesh-dynamics.md (FLS.6, PHY.D7), crates/kosmos-wardrobe, kosmos-airship.

  • Fire and smoke grids planned

    Step F8 in the fluid plan. No grid solver was found.

    Source: docs/plans/fluid-vfx.md, crates/kosmos-fx.

  • Breaking things prototype

    Voxel fracture matches the web code's numbers in tests. A separate crate cuts closed meshes into convex pieces, marked a spike. The strike tools, shapes and burn rules are not ported.

    Source: crates/kosmos-voxel, kosmos-break, reports/fx-f4b-voxel.md.

The Rig lab in the editor: a panel of effect looks and moves on the left, and two small fox characters on a green plain, the nearer one inside a glowing ring with sparks.
Rig lab with the solar effect on a kitsune. Capture of 18 Oct 2026.

Sources: kosmos-engine docs/plans/fluid-vfx.md, flesh-dynamics.md, crates/kosmos-fx, kosmos-flesh, kosmos-render, reports/labs-rig-fx.png. No code for liquid simulation or cloth was found. Searched 25 Oct 2026.

Engine

A Cargo workspace. These are the crates, grouped by what they do, with the description each crate gives itself.

  • Core and simulation

    kosmos-core
    Ids, seeded RNG, tick clock, state hash.
    kosmos-sim
    ECS world, fixed tick, snapshot, restore, replay.
    kosmos-scene
    Scene JSON: parse, write, prefab resolve, diff.
    kosmos-protocol
    Headless protocol with typed messages and a stdio server.
    kosmos-cmd
    Typed edit commands, undo, redo, transactions.
    kosmos-agent
    Headless agent loop with a mock provider and a confirm gate.

  • Rendering

    kosmos-render
    The wgpu renderer. Metal, Vulkan, DX12, WebGPU.
    kosmos-layers
    One override stack for looks, post and camera.
    kosmos-fx
    GPU compute for particles, as built. Its description also names fluids and smoke, which are planned. Visual only.
    kosmos-clouds, -weather, -blur
    Sky and clouds, weather as numbers, screen-space motion blur.
    kosmos-texops, -meshops
    Deterministic CPU texture and mesh operations.

  • Characters

    kosmos-model
    Model import to one ModelData, including the mochi importer.
    kosmos-anim
    Animation graph: state machine, blend trees, masked layers.
    kosmos-face
    Gaze, attention, expressions, talk and symbols.
    kosmos-faceplate
    Paints the face channels onto a texture for a skinned head.
    kosmos-human
    MakeHuman-style base meshes and morph targets.
    kosmos-film
    Plays compiled film timelines: camera, actors, subtitles, cues.

  • Worlds

    kosmos-planet
    Round worlds: cube-map ground and a radial-gravity walker.
    kosmos-physics
    Deterministic Rapier wrapper and a character controller.
    kosmos-crowd
    Crowd steering, planted feet, walk-grid A*.
    kosmos-voxel, -gen
    Voxel objects and seeded procedural geometry.
    kosmos-roads, -settlement
    Roads, street graphs, lots and buildings as data.

  • Audio, input, UI

    kosmos-audio
    Cue-driven audio over kira, plus a client for a local TTS server.
    kosmos-input
    Action map, rebinding, input recording.
    kosmos-ui, -host
    A retained HUD tree. Games run TypeScript on Hermes with Solid.

  • Runners and tools

    kosmos-app
    Native window and editor (winit, wgpu).
    kosmos-cli, kosmos-mcp
    Headless runs, replay, hash, and an MCP server over the same protocol.
    kosmos-web
    Browser runner on WebGPU. In the repo, no public build found.
    kosmos-genai
    Job queue and router for 3D generation. No model code. Draft.

Sources: each crate's Cargo.toml description, README.md, docs/plans/kamikin-port.md. Not every crate is equally complete: several plans in docs/plans are drafts.

Architecture

The layers as the code has them, top to bottom. Read each box as a group of crates or files, and each line as the way it talks to the layer below. The list under the diagram says the same in words.

  1. Games and labs

    Kamikin, Kosmica, film player, 40+ labs

  2. Runners

    • kosmos-appwinit window, egui editor
    • kosmos-cli, kosmos-mcpheadless, MCP
    • kosmos-webwasm, WebGPU
    • kosmos-hudlab

  3. JavaScript side

    • Hermesfacebook/hermes, JIT off, own thread
    • Solid 1.9.9universal renderer, one esbuild bundle per game
    • Bridgefour UI ops plus host calls (engine/wit)

  4. Rust engine crates

    • kosmos-simbevy_ecs, fixed tick
    • kosmos-physicsRapier
    • kosmos-anim, -face, -filmcharacters
    • kosmos-protocol, -agentheadless agents
    • kosmos-uiretained HUD tree
    • kosmos-audiokira, TTS client

  5. kosmos-render

    wgpu 30 on Metal, Vulkan, DX12 or WebGPU, with WGSL shaders and look layers

  6. Data

    54 JSON schemas, scenes, looks, glTF and mochi models, exported packs, content-hashed asset cache

Layers of the engine. Sources: Cargo.toml, crates/kosmos-host, games/kosmica-real/build.mjs, engine/wit.

How a frame and a HUD update flow

  1. The window loop sends the game thread a tick (milliseconds since the last one) and any input lines.
  2. Hermes cannot move between threads, so the runtime is created inside its own thread and only messages cross.
  3. The JS bundle runs. Solid's effects call four host operations: create, set property, insert, remove.
  4. Each batch comes back as a delta of UI ops, camera, lights, objects and logs. If many batches pile up, only the newest heading is run and the ticks are summed.
  5. The app applies the ops to the retained HUD tree, then paints it natively over the wgpu frame.
  6. The sim steps on its own fixed 1/64 s tick. A headless agent calls the same step through the protocol.

Sources: crates/kosmos-host/src/inproc.rs, hermes.rs, crates/kosmos-ui/src/op.rs, kosmos-core. Step 6 and the painter come from module docs and were not traced in a run.

How the JavaScript is built

  • Game and HUD source is TypeScript and TSX. Babel with babel-preset-solid compiles the JSX in universal mode against the engine's own renderer module, then esbuild bundles it to one ES2018 script.
  • Hermes is built from a pinned facebook/hermes revision with the JIT compiled out and linked as a static library through a small C++ shim. If that library is missing, the crate still builds and the fixture runner is used.
  • Rust and JS talk through a fixed list of host functions (set_pose, raycast, ground_at, emit and more) described once in engine/wit, from which the TypeScript types are generated.
  • HUD screens come from Yakopop's Solid sources, copied unchanged. The web dev UI is parked.
  • Agents use the headless protocol (JSON lines or WebSocket) with a typed TypeScript client, and an MCP server over the same messages.

Sources: games/kosmica-real/build.mjs and PROVENANCE.md, tools/hermes, crates/kosmos-host/build.rs, engine/wit, packages/kosmos-protocol-sdk.

Libraries

What the engine builds on, grouped by job. Versions are exact pins from the workspace Cargo.toml and package.json files, read 24 Oct 2026. Links go to each project's own page.

Libraries by group.
GroupLibraryVersionRole
Renderingwgpu30.0.1GPU API on Metal, Vulkan, DX12, WebGPU
naga (in the wgpu repo)30.0.1Reads WGSL shaders
Window, inputwinit0.30.13Window and events
gilrs0.11.0Gamepads
Mathglam0.34.1Vectors and matrices, with libm for repeatable results
Sim, physicsbevy_ecs0.20.0ECS only, not the Bevy engine
Rapier (rapier3d)0.36.1Colliders, queries, rigid bodies
Dataserde, serde_json1.0.229, 1.0.154Scenes and messages as JSON
postcard, blake3, jsonschema1.1.3, 1.8.7, 0.58.6Snapshots, content hashes, schema checks
gltf, fbxcel, tobj1.4, 0.9.0, 4.0.5Model import
Audio, speechkira0.12.5Cue playback over cpal
Local TTS server (in Yakopop)n/aSpeech and mouth shapes over HTTP. The engine holds the client only
JS runtimeHermes (site)pinned rev 1d2fc48cRuns the game and HUD scripts
Solid1.9.9HUD components, universal renderer
esbuild, TypeScript0.25.5, 5.8.3Bundling and types
UIegui, egui-wgpu, egui-winit0.37.0The editor
tiny-skia, ab_glyph, taffy0.11.4, 0.2.32, 0.15.0HUD painting, text, layout (taffy in hudlab)
AccessKit0.25.1Accessibility labels
Testingegui_kittest, cargo-deny, wasmtime, lavapipe0.37.0 (kittest)UI tests, licence check, native against wasm hash, software Vulkan
Toolingwasm-bindgen, clap0.2.129, 4.6.7Browser glue, command lines
Rust toolchain1.97.1Edition 2024, wasm32 target

Sources: kosmos-engine Cargo.toml, Cargo.lock, crates/*/Cargo.toml, games/kosmica-real/package.json, tools/hermes/hermes.sh. Cargo.lock holds several glam versions, the engine pins 0.34.1.

Related, not part of the engine

  • Godot

    The native reference engine in the Yakopop repository. Used for parity captures. See Compatibility.

  • PlayCanvas

    The web engine of the Yakopop client (playcanvas ^2.23.0). See Compatibility.

  • three.js

    Renders the character demos in this page and the Kamiji library (0.186.1). Not used by the Kosmos engine.

  • Bevy

    Only its ECS crate is used. The full Bevy tree is kept as a read-only reference in vendor/. The repositories do not mention Fyrox.

Compatibility

Kosmos is a third backend beside Godot and PlayCanvas in the Yakopop project. Compatibility means shared data, shared code and a way to compare pictures. It does not mean Kosmos opens Godot or PlayCanvas projects.

Godot partial

Shared. The same exported Kamikin data (planet, height cube, grass, the mochi cast) from Yakopop's Godot folder, copied by one script. The toon shader's header says it follows toon_shade in Godot and celShade in the web code. The Hermes build and the HUD Solid sources are copied from Yakopop's Godot binding.

Measured. Six poses scored against Godot 4.7.2 on Metal. Best is pond at MAE 20.7 and SSIM 0.752. Most error is missing content. No pass or fail threshold is approved. See Numbers.

Not done. No loader for Godot scenes or GDScript. Yakopop's pack files (kamikin.json, kamikin-village.json) feed Godot, and no reader for them was found in the engine. The native extensions in the Godot checkout were dead links, so the references have no Hermes HUD or audio. Embedding Godot as a renderer is a proposal only.

Sources: tools/kamikin-export/sync-data.sh, tests/parity/ref/kamikin/godot/provenance.json, reports/parity-kamikin.md, docs/plans/godot-embed-multi-renderer.md, yakopop apps/godot.

godotengine.org, Godot logo page

PlayCanvas partial

Shared. Yakopop's web client runs on PlayCanvas 2.23.0, and many engine ports start from its pure TypeScript logic, checked against goldens. A recording stand-in for the playcanvas module lets Yakopop's model builders run inside a Hermes bundle with no rendering.

Measured. PlayCanvas frame times on three web scenes in Chrome (a dense town at 24.1 ms CPU median). The PlayCanvas column of the Kamikin parity table is unmeasured because Kamikin has no web build. Kosmos cells for those three scenes are also unmeasured.

Not done. No PlayCanvas adapter in the engine. A script that captures a PlayCanvas reference exists for the Sakura Town scene. Streaming one scene to several renderers is a proposal.

Sources: yakopop apps/world/package.json, kosmos-engine tools/pc-record, tools/parity/ref-playcanvas.mjs, reports/parity-frametime.md.

playcanvas.com, developer docs, engine on GitHub

Three crops of the same Kamikin pond pose side by side: Godot on the left, Kosmos in the middle, and on the right a dark difference image with bright patches where they disagree.
Pond pose, Godot then Kosmos then difference times four. Our own render, 20 Oct 2026. Source: reports/parity/kamikin/pond-godot-sbs.jpg.

Godot logo: godotengine.org/press, CC BY 4.0, shown unmodified to name the engine. No PlayCanvas logo is shown: the PlayCanvas site has no brand or press page, so only the name is used. Logos and names belong to their owners. They describe compatibility only and imply no endorsement.

Built on Kosmos

Four projects connect to the engine. Status labels follow the sources, not hopes.

  • Kamikin prototype

    A mochi game on a round meadow planet that teaches Japanese words. A Godot slice exists, and a port runs in the engine: walker, grass, the mochi cast, toon look, rules with 29 tests. Missing in the port: sky shaders, animated water, shadows, meadow sound. A public play site is planned, not live.

    Source: kosmos-engine docs/plans/kamikin-port.md, reports/parity-kamikin.md.

    Kamikin page

  • Kosmica prototype

    The wider universe and flagship game behind Kamikin. The engine runs a real HUD and dialogue from the Yakopop sources through Solid and Hermes. No public build found, and the full game is a draft design document.

    Source: kosmos-engine docs/plans/kosmica-port.md, yakopop docs/plans/kosmica.md (draft 2026-10-13).

  • Yakopop live

    A language learning site with word-synced, colour-coded bilingual subtitles. The site is a separate web product and is live. Its role with the engine is the learning layer inside the games.

    Source: yakopop README.md (status October 2026), checked 24 Oct 2026.

    yakopop.com

  • Kamiji prototype

    Rigged, expressive 3D hand avatars with a morph-target face, for React and three.js. The hand model is also copied into the engine's assets. The library itself renders with three.js, not with the Kosmos renderer.

    Source: kamiji README.md, kosmos-engine assets/models/kamiji.

    Kamiji page

The Kamikin planet seen from above: a green round world with a brown path and a blue marker.
The Kamikin planet in the engine, from above. Capture of 16 Oct 2026.

Try a character

A small demo of the characters that run on the engine. Pick a character, a face and a clip. It is rendered with three.js in this page, not with the Kosmos renderer.

Kamikin demo, rendered with three.js in this page, not the Kosmos renderer

Numbers

Read first. Measurement only, on one Mac. The engine is not at parity with Godot, and the reports say so. No threshold has been approved.

Look against Godot (lower MAE, higher SSIM is closer)

Kamikin, six poses at 640 by 360. Score run 20 Oct 2026.
PoseMAESSIMGodot against itself (MAE / SSIM)
pond20.70.7520.021 / 0.999
sky28.00.8920.076 / 1.000
patch29.40.5450.013 / 1.000
meadow-wide37.00.5540.185 / 0.994
character-close43.20.5980.438 / 0.982
planet-far68.10.6010.001 / 1.000
  • Debug build, Metal, Apple M3 Max. Two captures of each pose are byte-identical (6 of 6). Godot 4.7.2, Metal.
  • The Kosmos shots show the world only. Godot shows the player, the cast, village shells and labels, so most of the error is missing content, not the renderer.
  • planet-far compares against a Godot frame that is flat sky colour, so that row measures the reference.
  • Sky and cloud shaders, animated water and shadows are not done in the port. The report proposes a looser target (MAE at most 10, SSIM at least 0.85) for the owner to decide. The best row today is pond.

Source: kosmos-engine reports/parity-kamikin.md, committed 20 Oct 2026. MAE is on a 0 to 255 scale, SSIM on luma.

Frame time

Milliseconds per frame, median and 95th percentile, 240 frames.
PoseGodot p50 / p95Kosmos p50 / p95
character-close5.13 / 5.302.34 / 2.63
meadow-wide5.32 / 5.533.70 / 7.89
pond5.74 / 5.953.20 / 4.30
patch5.74 / 5.903.18 / 3.85
sky3.97 / 4.131.93 / 2.14
planet-far2.80 / 3.123.02 / 3.23
  • These are not the same measurement and are not a ratio. Kosmos times one headless render including GPU completion and a pixel readback. Godot times a forced draw and sync, and the report could not verify that this waits for the GPU on Metal.
  • Kosmos is a release build, Apple M3 Max. Only 640 by 360 shots of one game were measured. No other hardware, no browser.
  • On three web scenes the report lists PlayCanvas in Chrome (for example a dense town at 24.1 ms CPU median), and the Kosmos cells are unmeasured because no Kosmos scene exists yet.

Source: kosmos-engine reports/parity-frametime.md, committed 20 Oct 2026. Read the columns as orders of magnitude.

Faces and voices prototype

Try the Face and Clip menus in the hero. They show the Kamikin face states in this page, not the Rust face crate.

  • Face channels

    The face crate holds 45 numeric channels for eyes, brows, mouth, gaze and more. It was ported from the web code in Yakopop and is checked against golden data from that code.

  • Face plate

    For characters whose head has no morph targets, the faceplate crate paints eyes, brows, mouth, blush and marks onto a texture for the head. Morph targets are also carried through glTF import and export.

  • Visemes and phonemes

    Mouth shapes come from a viseme table with phonemes and coarticulation. A draft proposal asks for a way to author them by hand, and nothing in that proposal is built.

  • Voices

    The audio crate has a client for a local text-to-speech server. The server returns audio plus timed mouth shapes in a header. The server lives in the Yakopop repository. Which voices ship is not settled in the files.

  • Mochi importer

    The model crate turns exported mochi characters (skinned body, face shell, baked motions, six face states) into the same model type that glTF import gives. The Kamikin characters in the hero are those mochi, as GLB files.

Sources: kosmos-engine crates/kosmos-face, kosmos-faceplate, kosmos-audio/src/tts.rs, kosmos-model/src/mochi_import.rs, docs/plans/rig-authoring.md (proposal, 23 Oct 2026), tests/golden/face.

Open source and licence

  • The engine

    Dual licensed under MIT or Apache-2.0, at your option, as declared in the workspace and in the LICENSE-MIT and LICENSE-APACHE files. The repository is private today, so the declared licence does not mean the code is public. Dependencies are limited by a cargo-deny allow list. Third-party assets have their own terms, and the asset ledger is still a draft.

  • Kamiji and Kamikin assets

    The characters and assets (the hand, every Kamikin mochi, models, textures, props) are not part of the engine licence. They are free for non-commercial use under CC BY-NC 4.0 with credit, and for-profit use needs the paid Premium Licence. The Kamiji code is MIT.

  • Names

    "Kamiji" and "Kamikin" are trademarks of Paul Bloch. Registration status in the repository: unregistered, to be filed. You may say a project uses Kamiji in plain text. Do not name a product after them or imply endorsement.

Sources: kosmos-engine Cargo.toml, README.md, deny.toml, docs/licences/assets.md. Kamiji LICENSE.md, TRADEMARKS.md. This is a summary, read the files for the terms.