minimal_player

# avatar A playable character, composed from three **independent** parts: - **body** (optional): a `.bundle` (a skinned `.mesh` + bone entities, a character imported from a GLB/FBX) or a plain `.mesh`. The look. An avatar with no body is a controller or first-person camera with no visible mesh. - **controller** — the movement system. Default: the standard humanoid kit (`CharacterController` + `MovementState` + `Humanoid`). - **animation** — the system that animates the body. Default: the shared `Locomotion` blend space (reads the controller's velocity, plays retargeted clips). Or `ClipPlayer`. Or your own component. Movement and animation are **not** tied together — attaching the controller never pulls in `Locomotion`, and choosing your own `animation` keeps the standard controller. Authoring your own locomotion is a one-field swap (`animation = ...`). Because the standard clip set retargets onto **any** humanoid rig, the default locomotion drives any humanoid body with no per-body setup and no editing of any built-in content. ## Make an imported character playable ```luau -- After importing a rigged humanoid GLB, the importer leaves a `.bundle` -- (skinned mesh + bones). Survey for it, then wrap it in an avatar: local body = asset.resolve("my_character", "bundle") local hero = asset.create("avatar", "my_hero", { body = body }) ``` To make `hero` the body every connecting player spawns with, point the scene's `PlayerPrototype.body` at a body entity whose `Asset` source is `hero` (authored in the scene tree — see `man scene`). To drive the **local** player with it right now, instantiate it and bind the entity: ```luau local root = hero:instantiate() -- spawns the body + movement kit layers.active.players.localPlayer.avatar = root -- bind the live body ``` Only the avatar bound as the local player's body answers the player's controls. Every other avatar you instantiate (an NPC, a mannequin, a preview) stands where it is until something drives it: with the standard controller, write its `CharacterController` input bus (`inputX` / `inputZ` / `inputJump`) from a component of your own, the way an AI brain does (`man CharacterController`). ```luau local npc = hero:instantiate() -- stands still npc.component.get("CharacterController").inputZ = -2 -- walks while this is written each frame ``` An avatar is **not** humanoid-only. The body can be anything — a humanoid, a vehicle, an unrigged plane with a custom controller and shader. The defaults adapt to the body: a **humanoid** body defaults to the shared humanoid Locomotion (the `synty` clip preset); a **non-humanoid / unrigged** body gets **no auto-animation** (you supply your own `controller` and `animation`). This is the non-humanoid detection — an arbitrary animated model is never auto-driven by humanoid locomotion — and it never blocks creating the avatar. ```luau -- Non-humanoid avatar (e.g. a custom-controlled body), fully generic: asset.create("avatar", "ship", { body = shipBundle, controller = { system = "ShipController" }, animation = false }) ``` ## Options `asset.create("avatar", name, opts)`: | opt | meaning | |-----|---------| | `body` (optional) | the body `.bundle` or `.mesh` ref; omit for a body-less avatar | | `controller` | movement: `true`/nil = standard kit, `false` = none, or a component name / `{ system, data }` | | `animation` | a component name or `{ system, ... }` — **author your own locomotion here**; defaults to Locomotion | | `locomotion` | clip preset for the default Locomotion (default `"synty"`) | | `clip` | a single `.animation` ref — selects a one-clip `ClipPlayer` | | `looping` / `speed` / `sourceRig` | `ClipPlayer` tuning (with `clip`) | Author your own locomotion (keeps the standard movement): ```luau asset.create("avatar", "my_hero", { body = body, animation = { system = "MyLocomotion" } }) ``` `avatar.json`: ```json { "body": { "__ref": "<bundle guid>" }, "controller": true, "animation": { "system": "Locomotion", "preset": "synty" } } ``` The body's facing is read from its rig (the importer records a `forward` for each body — `{0,0,1}` for a +Z Synty/FBX body, `{0,0,-1}` for a -Z glTF body), so Locomotion turns the body to its movement direction regardless of how its source authored it. No per-avatar facing knob. ## Use ```luau local root = avatarRef:instantiate() -- spawn body + movement kit avatarRef:setCharacter(root, asset.resolve("knight", "bundle")) -- swap the body, keep the behaviour ``` `:instantiate()` spawns the body and attaches the movement system bound to it. `:setCharacter(root, body)` despawns the current body and spawns a new one in its place; the Locomotion kit on the avatar root re-resolves the new body's rig, so the look swaps while the behaviour is kept. Items seated with `Humanoid:attach` are kept: each moves to the new body's socket for the same point, with the transform it was seated with. An item whose point the new body lacks stays on the avatar root and is seated by the next swap to a body that has it. The new body takes the old body's id and is composed with the options the avatar was instantiated with, and the avatar's `Asset` id map names it. ## In the Inspector Selecting an avatar opens its **Avatar** section, read from `avatar.json`: its label when it has one, how it moves (`controller`: the standard mover, none, or the system it names), what animates it, and whether it is humanoid. It links the body the avatar wears, or says the avatar spawns no visible body, and offers to open `avatar.json` in the Code panel.

# assetType (asset type) An asset type says what a kind of asset is: the files an asset of the kind is made of, the code that gives it behaviour, the interface a person uses to work with it, and how it is found, pictured and checked. A `<typename>.assetType/` folder declares a type called `<typename>`, and every `<name>.<typename>/` folder is an asset of it. `assetType` is itself a type, so a type is an asset like any other: it is created, versioned, installed and contributed the same way. ## Making a type `asset.create("assetType", "<typename>")` scaffolds a type. The type registers the moment its folder is written, anywhere under `/zero/source/`, and from then on `<name>.<typename>/` folders are its assets. An asset of a type that is not registered yet is not an asset, so make the type first. A type folder is a root: `~.x` in any file inside it names the type's own `x`, wherever the type is installed. Keep the type's whole implementation inside its folder and reach it that way. What a type folder must hold is set by this type's own `type.yaml`, the same way every type's `type.yaml` sets what its assets hold. `asset.validate` on a type reports anything missing, and the scaffold produces a folder that passes. ## What sets your type's schema (`type.yaml`) `type.yaml` is the structural contract every asset of the type is checked against. The keys below are the ones the engine reads; a key not listed here is ignored. | Key | What it controls | |---|---| | `suffix` | The folder suffix of the type's assets. Defaults to `.<typename>`. | | `primary` | The file or files that are the asset's content: what the asset resolves to when it is used. | | `entry_files`, `primary_aliases` | Further files that load as the asset or share its identity. | | `is_container` | Whether the suffix stays in the identities of what the asset holds. | | `is_opaque_walker` | Whether a walk of the tree stops at the asset and registers only its primary. | | `plural_dir`, `classify_exts` | Loose files in a folder of this name, or with these extensions, are assets of the type. | | `is_text_default` | Whether the asset's files are text unless stated otherwise. | | `broadcasts_subassets` | Whether assets nested inside an asset of the type are found by their own short name. | | `root` | `true` makes every asset of the type a root, so `~.x` inside one names that asset's own `x`. | | `contract_ref: { field, category }` | A key of the primary file that names another asset the asset is built on. | | `files: { required, optional }` | The files an asset holds (below). | | `allow_unlisted` | `false` reports every file the type does not declare. | | `aliases_from: [{ file, key }]` | Further names an asset answers to, read from its own files. | | `settings:` | Typed per-asset settings (below). | | `inspector:` | The interface people use for the type and its assets (below). | | `preview:` | How an asset is pictured (below). | | `references:` | Names of other assets the type's files carry (below). | | `indexing:` | What search reads for each asset (below). | | `describe:` | How a missing description is generated (below). | ### The files an asset holds Each entry under `files.required` or `files.optional` is `{ path, kind: file | folder, one_of_group?, content? }`. `*` in a path matches within one segment. Entries that share a `one_of_group` are satisfied by any one of them. `content` lists checks on the file's bytes: | Check | Passes when | |---|---| | `non_empty` | the file has content | | `json_field { key, type?, non_empty?, accept? }` | the JSON holds the key (a dotted path) with that shape | | `yaml_field { key, type?, non_empty?, accept? }` | the same for YAML | | `described { keys?, headings?, message? }` | the file says what the asset is (see "Ask your assets to say what they are") | Each check takes a `message`, which is what the author is told when it fails. ### Settings `settings: { values, schema: { type | instance, export? } }` gives every asset typed settings. `values` names the file an asset's values live in; `schema.type` declares one schema for the whole type, and `schema.instance` names a file each asset declares its own in. `asset.create` writes the resolved values, and a write to the values file reaches `onChange` with what changed. ## The human side (`inspector.luau`) A type is used by people through its Inspector, and without one the type is usable only from code. The Inspector is the type's interface for a person: for a procedural graph it is the graph editor, for a kit it is the tracking view of what the kit holds and what is still missing. Writing it is part of writing the type. `inspector: { type, instance? }` in `type.yaml` names the files. `type` is the interface for the type itself and for its assets; `instance` names a file an asset may ship to add its own. Each returns: ```luau return { sections = { { id = "graph", title = "Graph", build = function(ctx) ... end } }, replace = { contents = { ... } }, -- replace a default section by id order = { "graph", "contents" }, -- section order } ``` `build(ctx)` receives the asset and builds the section. A section's `title`, and the text its rows carry, is a string or an `i18n.text` value read from a catalog (`i18n.text("inspectors.mesh.title")`), which follows the editor's language. `asset.create("assetType", ...)` scaffolds a working `inspector.luau` to start from. `asset.validate` on a type that names no inspector, or names one that does not load, reports it. ## Say what your type is for (`about.yaml`) Every type carries an `about.yaml` that says what the type is for, in three plain-language texts: ```yaml intent: "Sets the typeface of the text in your game: UI, labels, signs and 3D lettering." function: "A font, from a TTF, OTF or WOFF file, made available to all of Zero's text, including 3D text." usage: "You choose it by name for your UI or your text, and the text appears in that typeface." ``` - **`intent`** is what the type is for in someone's game, in the words a game maker uses. Up to 800 bytes. - **`function`** is how it works today: what an asset of it is made of and what the engine does with it. Up to 1500 bytes. - **`usage`** is what a person or an agent does with one. Up to 1200 bytes. Write about the type as a whole, not one asset of it, and say what it does now. Agents read these texts to learn when to reach for the type and how; people searching find the type by them. The scaffold starts each text with `[[describe]]` and a note on what to write; a text that still starts that way counts as not written. `services describe` can write them. They show up in `asset.inspect` as `detail.about`, in `assetTypeRef:getAbout()`, at the end of the type's `types/<typename>` guide, and at the top of the type's Inspector. ## Ask your assets to say what they are A type can require each asset to carry a description: a file, written by the author or generated, saying what the asset is and what it is for. Declare it with a `described` check: ```yaml files: required: - path: "README.md" kind: "file" content: - { check: "described", message: "Say what this widget is for and where it goes." } ``` A file that is missing, empty or still has a line starting with `[[describe]]` fails the check, and so does a YAML file whose named `keys` are missing or over their `max_bytes`, or a Markdown file missing a named heading. `asset.validate` names the asset, and a push that carries it is refused with `message`. `services describe` finds such assets and writes their descriptions. `describe:` steers what is generated: ```yaml describe: guidance: "Say what the widget shows, what input it reacts to, and where it fits in a UI." examples: - "<identity of an asset of this type whose description reads well>" ``` An example is an asset of your type whose description is a true, written one, never a placeholder and never the asset being described; with none, leave `examples` empty. A type whose assets the model cannot perceive (a sound, a motion) says so in `guidance`, and the description is drawn only from what the asset's own files state. Start the file unwritten in your `template/`: a heading and one line starting with `[[describe]]`, never example content, which every new asset would carry verbatim. A type whose assets say what they are through their own content (a mesh, a texture) declares no check. ## The type's code (`behavior.luau`) `behavior.luau` returns one table. These are the keys the engine reads from it; anything else on the table is the type's own. ### What the type's assets can do | Key | Shape | What the engine does with it | |---|---|---| | `ref` | `{ [name] = function(self, ...) }` | Every function becomes a method on every asset of the type: `ref:name(...)`. | | `modules` | `{ [name] = require(".x") }` | Code the type's assets reach with `asset.containing(__FILE__).modules.<name>`. | | `events` | an events schema | Events an asset fires. Readers subscribe through `ref.events.<name>:connect(...)`; the type fires them. | | `refShapes` | `{ [method] = function(self) -> (typeExpr, source?) }` | The result type of a `ref` method for one particular asset (below). | | `namePattern` | a Lua pattern | The names `asset.create` accepts for the type's assets. Default `^[A-Za-z][A-Za-z0-9_]*$`. | | `derive` | `{ output, module, compute, fingerprint, matches?, required?, timeout? }` | A file computed from the asset when it is committed; a `required` one holds the commit until it lands. | Some `ref` names mean the same for every type, and the engine calls them: - **`instantiate(self, target?, opts?) -> (root, idMap)`**: puts the asset in a scene. Defining it is what makes the type scene-instantiable. Its return is a contract (below). - **`inspect(self) -> detail`**: what `asset.inspect` reports for the asset beyond the common record (below). - **`preview(self, opts)`**: renders the asset's picture; it wins over the type's `preview:` recipe. - **`previewMaterial(self) -> { material }`**: the material a `surface` preview paints. - **`saveDefinition(self)`**: writes the asset's in-memory edits back to its files in edit mode. Some names are answered for every asset before the type is asked, so a `ref` entry of the same name is never reached: `getSource`, `getBytes`, `getText`, `exists`, `deps`, `canInstantiate`, `canPreview`, `preview` (which calls yours when you define one), `meta`, `runtime`, `events`, `typeRef`, `modules`, and the residency flags `has_backing_asset`, `has_runtime_changes`, `cpu_resident`, `gpu_resident`. ### When the engine calls the type | Hook | Signature | When it runs | |---|---|---| | `onCreate` | `(name, opts) -> { [path] = contents }` | On `asset.create`. Returns the files of the new asset, laid over the type's `template/`. Annotate `opts`: its type is the schema `asset.create` checks the caller's arguments against. A `""` key writes a single loose file. | | `onReplace` | `(dest, files) -> files` | On an `asset.create` over an asset already at `dest`, after `onCreate`, so what the author added can be carried into the replacement. | | `onRegister` | `(self)` | Once per asset, when it first registers: when the world loads, on a live `asset.create`, and when an asset arrives later (installed, pulled, synced). This is what makes an asset take effect the moment it is written. | | `onChange` | `(ref, change)` | On every write to a file inside an asset of the type. `change` is `{ path, asset, type, kind, origin }`, plus `settings` and `settingsChanged` for a write to the settings values file; `kind` is `edited` or `seeded`, `origin` is `local` or `remote`. Filter on `change.path`. Writes to one asset arrive in order, each after the hook for the one before has finished, and the hook may wait on what it reads. A write the hook makes inside its own asset arrives later like any other, so keep the hook convergent. | | `onDependencyChange` | `(ref, change)` | When a module the asset's code requires is re-run, or a name the asset carries starts resolving. `change.kind` is `dependency`. | | `onDelete` | `(ref)` | When an asset of the type leaves the world: deleted, or the world it is in is swapped away. | | `validate` | `(ref) -> { { code, message, severity?, path? } }` | On `asset.validate`, after the `type.yaml` checks, for the type's own rules. `severity` defaults to `error`. Runs on every push, so a type's rules hold at publish. A hook that fails reports `validate.hook_failed`. | ### Settings hooks | Hook | When it runs | |---|---| | `settingsDefaults(name, opts, asked) -> table` | Once per `asset.create`, for values the schema's defaults do not give. | | `settingsCorrections(values, name, opts) -> (corrections?, reasons?)` | On every settings write. A correction to a field the writer named refuses the write, giving the reason. | | `settingsDerivedDefaults(values, explicit, changed)` | On a settings write, for fields derived from others. | | `normalizeSettings(values, stored?)` | On every read and write, to map an earlier spelling of a field to the current one. | | `settingsHealed(values, stored)` | On a read, to repair stored values. | | `settingsSchemaProblem(schema, ref) -> string?` | When an asset's own schema is read; a returned string refuses the schema. | `creationInputs` (`{ [opt] = true | selectorOpt }`) names `asset.create` options that are inputs to the type rather than settings. ### Reloading An edit to `behavior.luau` reaches existing assets with no restart. ## How an asset is pictured (`preview:`) | `kind` | The picture is | The type provides | |---|---|---| | `instantiate` | the asset placed in the preview studio through its `instantiate` | `ref.instantiate` | | `image` | a file the asset holds, fitted to the frame | `source: { files }`, the candidate files in order | | `surface` | the asset painted on a mesh | `mesh`, and `ref.previewMaterial` | | `custom` | whatever `ref.preview` returns | `ref.preview` | ```yaml preview: kind: surface mesh: sphere ``` `angle: [yaw, pitch]` turns the camera. The studio owns the light, the backdrop and the framing, so an asset pictures the same in every world. A type with no `preview:` that defines `instantiate` still answers `ref:preview()`. A picture is rendered when something asks to view it (the editor showing the asset, `ref:preview()`), when previews are generated on request (`assets.generatePreviews`), and when the asset is staged. An edit alone renders nothing. The picture records what it was made from, so a stale one is told from a current one. ## The names your type's assets hold (`references:`) Where your type's own format or API carries the name of another asset, declare it here: ```yaml references: keys: # a top-level key of the type's files that holds a name, or a table of them - { key: "shader", type: "shader" } args: # an argument of a call, counting from 1 - { call: "g:node", position: 2, type: "procNode" } fields: # a field of the options table a call takes - { call: "fx.beam", field: "material", type: "material" } ``` `type` is the category the name resolves in. `asset.declareReferenceKey`, `asset.declareReferenceArg` and `asset.declareReferenceField` declare the same from a script. ## What search reads (`indexing:`) `indexing:` is how assets are found. Search reaches an asset only through what its type's `indexing:` names, and adds nothing of its own. That includes you: an asset indexed badly is one you cannot find later, when you are making something else and need it. A type whose assets are never looked for says `indexing: none`. ```yaml indexing: data: # text, read from the asset's files - role: identity extractor: verbatim source: { file: "README.md" } - role: interface extractor: symbols source: { files: ["init.luau"] } - role: implementation extractor: verbatim source: { files: ["init.luau"] } content: # the picture - role: identity modality: image source: { file: "preview.png" } facets: # what a query filters and re-ranks by file: ".metadata" rigged: { type: bool, from: { components: { contains: SkinnedModel } } } roughness: { type: number, filter: range, from: { file: "mat.yaml", field: "floats.roughness" } } ``` **Roles.** Each `data` and `content` entry has a `role`, and a query matches in two slots: - **`identity`**: what an asset is. For anything you look at, the picture; for anything else, the text that says what it is. - **`capability`**: what it does and how it is made. `interface` (the signatures or shape a caller uses) and `implementation` (the body) both count as capability, and a type with code usually declares both. Ask what a person would recognise an asset of the type by, and what it does, and point each role at the file that says it. For text, that is the asset's description: the file your template starts with a `[[describe]]` block, which the author writes or `services describe` fills in (see "Ask your assets to say what they are"). **`data`.** `extractor: verbatim` embeds a file's text as it is; `symbols` embeds the declared signatures of code. `source` is `{ file }` or `{ files: [...] }`. Never index a file name (`source: { field: name }`): one or two words carry nothing to match. **`content`.** `modality: image` embeds the picture itself, so a text query matches what the asset looks like. A type whose assets are looked at makes the picture its identity. **`facets`.** What a query narrows and re-ranks the matches by. `file` is embedded whole, so keys nobody declared in it are still found. Each further key is computed for every asset and states a value for every one, including `false`: a file can imply "not rigged" but never say it, and a query separates rigged from unrigged only because the unrigged ones say `rigged: false`. A key is `{ type: bool | number | enum, filter?: range, from }`, where `from` is `{ file, field }` (a field of one of the asset's files, dotted for nesting), `{ metadata: key }`, or `{ components: { contains | any_outside } }` (what the asset's entities carry). ## What blocks a push A push checks every asset it carries against its type. These refuse it: - a required file that is missing, a `content` check that fails, a `described` file not written yet; - an error from the type's `validate`. Unlisted files and warnings do not. A `described` file blocks only a push that changes the asset. When a push is refused, the message names each asset and what it lacks. `world.publishBlockers()` and `zm status` read the same list without pushing. ## Typing a result from the asset (`refShapes`) A `ref` method whose result depends on the asset (one entry per child folder, per row of a config, per control a map declares) can only be annotated as `{ [string]: Thing }`, which accepts any key. `refShapes` states the result for each asset instead: a function returning a Luau type expression for that asset, and the module whose types the expression uses. Read the asset; never run it. ```lua -- inputMap.assetType/behavior.luau M.refShapes = { activate = function(self): (string, string) local names = {} for _, control in ipairs(M.ref.controls(self)) do table.insert(names, control.name .. ": Handle") end if #names == 0 then return "", "" end return "{ " .. table.concat(names, ", ") .. " }", "@builtin::modules.zinput.scheme" end, } ``` With it, `map.jump:onPressed(fn)` is checked and `map.noexisting` is reported. A per-asset type applies where the call site names which asset: a component field whose default names it, or an annotation `AssetRef<"inputMap", "<identity>">`. `asset.resolve(name, category)` carries only the category, and a name computed at runtime carries nothing, so calls on those keep the declared return. The type belongs to the call's result: index it there, or bind what you need from it there, and the names stay checked. `require("@builtin::assetTypes.assetType.shared.refShapes").published()` shows what was published: `categories` (each type's method surface) and `returns` (per-asset results by identity, then method). An identity missing from `returns` was never published. Results are recomputed when an asset is written; at most 64 assets of one type are read. ## Putting an asset in a scene (`ref.instantiate`) A caller writes one piece of code against every instantiable type, so what `instantiate` returns is fixed: ```lua local Instantiable = require("@builtin::assetTypes.assetType.shared.instantiable") M.ref = { instantiate = function(self, target, opts) local root = Instantiable.root(self, target, opts) -- compose the asset under `root`, now return Instantiable.result(self, root, idMap) end, } ``` **In.** `target` is the entity the asset lands under, or onto for a hierarchy type; with none, the type spawns a new root. `position`, `rotation` (three numbers in degrees, or a quaternion), `scale`, `name` and `temporary` mean the same for every type: `Instantiable.root` applies them to a root you make, `Instantiable.place` to one you adopt. Document any options of your own in the hook's `--!arg` docs. **Out.** `(root, idMap)`. `root` is the composed root, live when you return: build synchronously, never defer to a component's `awake`. `idMap` maps each original id to the spawned one, so a component that composes the asset again on every load can pass it back in and keep references into the composition. Every call goes through `Instantiable.result`, which refuses a root that is not live and turns a missing `idMap` into `{}`. ## Inspecting an asset (`ref.inspect`) `asset.inspect(ref)` builds a record every asset shares (`identity`, `name`, `guid`, `source`, `typeName`, `typeDefinitionPath`, `scope`, `origin`, `description`, `tags`), then calls `ref.inspect(self)` for the type's own `detail`: ```lua M.ref = { inspect = function(self) -- read the asset's own files, never runtime state: inspect works on an asset -- that has not been compiled, uploaded or registered return { --[[ what makes this asset what it is ]] } end, } ``` Without it, the record is the shared part alone, and an agent inspecting the asset learns nothing of what it is. A hook that raises leaves `detail` empty and sets `record.warning`. ## Discovery - `asset.list("assetType")`: every registered type. - `asset.inspect("<typename>")`: the type, its README and its `about.yaml` texts. - `asset.resolve("<typename>", "assetType")`: the type itself.

# mesh A mesh is renderable geometry — vertices and triangle indices, and, for a skinned mesh, the per-vertex skinning data that binds it to a skeleton. A component that draws geometry references a mesh, and the renderer binds the mesh's GPU resource for that entity. > New to how a mesh exists as an asset, as CPU-side vertex data, and as a live > GPU resource (and how `renderer.mesh.*` moves between them)? Read > `core/resource-model` first. Geometry is stored in `data.zmsh`; the GPU resource is keyed by the asset's guid. ## Create `asset.create("mesh", name, opts)` writes the geometry and registers the mesh. `opts` is raw geometry — flat arrays; `positions` and `indices` are required, `normals` and `uvs` optional: ```luau asset.create("mesh", "tri", { positions = { 0,0,0, 1,0,0, 0,1,0 }, -- [x,y,z, ...] (required) indices = { 0, 1, 2 }, -- [i0,i1,i2, ...] (required, 0-based) normals = { 0,0,1, 0,0,1, 0,0,1 }, -- [x,y,z, ...] (optional) uvs = { 0,0, 1,0, 0,1 }, -- [u,v, ...] (optional) }) ``` The full authorable geometry, all flat arrays unless noted: | Field | Shape | Notes | |---|---|---| | `positions` | `[x,y,z, ...]` | required | | `indices` | `[i0,i1,i2, ...]` | required; 0-based, counter-clockwise for the front face (see Conventions) | | `normals` | `[x,y,z, ...]` | optional; the surface's outward direction | | `uvs` | `[u,v, ...]` | texture UVs, optional; `(0,0)` is the image's top-left | | `colors` | `[r,g,b,a, ...]` | optional | | `tangents` | `[x,y,z,w, ...]` | optional (`w` = handedness) | | `uvs1` | `[u,v, ...]` | the lightmap UV set, optional | | `unwrapUvs` | boolean | generate `uvs1` when it is absent | | `skinning` | `{ joints, weights }` | per-vertex skin binding (four each per vertex) | | `skins` | array of skin tables | the skeleton (see `renderer.mesh.decode` for the shape) | | `morphTargets` | array of `{ name?, positions, normals? }` | the shapes the mesh blends towards, each a per-vertex displacement | `encode` / `decode` round-trip every one of these, so a **skinned** mesh can be built in engine, not only imported. Pass `unwrapUvs = true` to generate a lightmap UV set at creation time. ## Conventions Geometry is read against these whether it arrived through `asset.create`, `renderer.mesh.create`, or an importer. | Convention | How the engine reads the geometry | |---|---| | Index base | `indices` count vertices from **0** — index `0` is the first `positions` triple. The Luau array carrying them is 1-based like any other, so `indices[1]` is the first triangle's first index, and vertex `v` has its x at `positions[v * 3 + 1]`. | | Triangle winding | A triangle's **front** face is the one whose three vertices turn **counter-clockwise** as the viewer sees them. Put another way, `cross(v1 - v0, v2 - v0)` points out of the front face. | | Back faces | A material culls its back faces by default, so a triangle turned away from the camera draws nothing where it stands and whatever is behind it shows through. | | Normals | `normals` give the surface its outward direction and shade the face. Which side of a triangle draws comes from the index order alone, so a normal pointing away from the side the winding draws leaves that face standing and shades it as if the light were behind it. | | UVs | `(0, 0)` samples the first texel of an image — its top-left corner — and `v` grows downward through it. | | Axes | Model space carries the world's basis: `+X` right, `+Y` up, and `-Z` the direction an entity's `transform.forward` points. | Winding is what the author states: the inward faces of a room and a sky shell seen from inside are geometry meant to be wound the other way, and `asset.create` writes the index order it is handed. Two levers turn a face around: ```luau indices = { 0, 2, 1 } -- the same three vertices, reversed asset.create("material", "two_sided", { -- or keep the order and draw both sides shader = "@builtin::shaders.pbr", render = { cull = "none" }, }) ``` `cull = "front"` draws the far side by itself, which is what an inverted-hull outline is built on, and `"back"` is the default. `.shader` documents the whole `render` block a material's `mat.yaml` carries. A mesh states which way its own triangles face, so the question is answerable off the geometry — every triangle whose cross product agrees with the normal it carries is wound to draw the side that normal points at: ```luau local cpu = meshRef:load() local g = cpu:geometry() local function facesOutward(t: number): boolean -- t counts triangles from 0 local i = { g.indices[t * 3 + 1], g.indices[t * 3 + 2], g.indices[t * 3 + 3] } local function p(k: number, c: number): number return g.positions[i[k] * 3 + c] end local ax, ay, az = p(2,1) - p(1,1), p(2,2) - p(1,2), p(2,3) - p(1,3) local bx, by, bz = p(3,1) - p(1,1), p(3,2) - p(1,2), p(3,3) - p(1,3) local cx, cy, cz = ay*bz - az*by, az*bx - ax*bz, ax*by - ay*bx local n = i[1] * 3 return cx * g.normals[n+1] + cy * g.normals[n+2] + cz * g.normals[n+3] > 0 end local inward = 0 for t = 0, #g.indices // 3 - 1 do if not facesOutward(t) then inward += 1 end end cpu:unload() ``` ## Built-in primitive meshes The engine ships blockout geometry every world references by bare name (`{ model = "cube" }`). Each one is centred on its local origin, so an entity's `scale` reads directly as the size the mesh covers in the world: | Mesh | Extent (x, y, z) | Local AABB | |---|---|---| | `cube` | 1 x 1 x 1 | `-0.5, -0.5, -0.5` .. `0.5, 0.5, 0.5` | | `sphere` | 1 x 1 x 1 | `-0.5, -0.5, -0.5` .. `0.5, 0.5, 0.5` | | `cylinder` | 1 x 1 x 1 | `-0.5, -0.5, -0.5` .. `0.5, 0.5, 0.5` | | `cone` | 1 x 1 x 1 | `-0.5, -0.5, -0.5` .. `0.5, 0.5, 0.5` | | `octahedron` | 1 x 1 x 1 | `-0.5, -0.5, -0.5` .. `0.5, 0.5, 0.5` | | `rounded_box` | 1 x 1 x 1 | `-0.5, -0.5, -0.5` .. `0.5, 0.5, 0.5` | | `capsule` | 0.5 x 1 x 0.5 | `-0.25, -0.5, -0.25` .. `0.25, 0.5, 0.25` | | `torus` | 1 x 0.3 x 1 | `-0.5, -0.15, -0.5` .. `0.5, 0.15, 0.5` | | `plane` | 1 x 0 x 1 | `-0.5, 0, -0.5` .. `0.5, 0, 0.5` | | `ground_quad` | 1 x 0.1 x 1 | `-0.5, -0.05, -0.5` .. `0.5, 0.05, 0.5` | | `ground_hex` | 1.732 x 0.1 x 2 | `-0.866, -0.05, -1` .. `0.866, 0.05, 1` | | `shader_ball` | 0.933 x 1 x 0.933 | `-0.467, -0.5, -0.467` .. `0.467, 0.5, 0.467` | `plane` is a flat quad in the XZ plane, so it has no vertical extent at all and scaling it on Y moves nothing. `meshRef:load():getBounds()` reads the same numbers back off any mesh, built-in or authored. ## Put a mesh on an entity A component draws a mesh through a `resource("mesh")` field, which accepts the mesh **by name, by ref, or as a `MeshHandle`** — the component resolves whatever you give it. The builtin `Model` and `SkinnedModel` both expose a `model` field: ```luau entity.find("box").component.add("Model", { model = "tri" }) -- by name entity.find("box").component.add("Model", { model = asset.ref("tri") }) -- by ref entity.find("box").component.add("Model", { model = meshHandle }) -- a MeshHandle (below) ``` ## Runtime mesh — no asset Build geometry straight onto the GPU and render it without creating an asset. The `resource("mesh")` field takes the returned `MeshHandle` directly: ```luau local h = renderer.mesh.create({ positions = {0,0,0, 1,0,0, 0,1,0}, indices = {0,1,2} }) entity.find("box").component.add("Model", { model = h }) ``` Its geometry reads back off the handle. `renderer.mesh.geometry(mesh)` returns the same flat-array `MeshGeometry` `create` takes, carrying every stream the mesh has — so a runtime mesh can be inspected, edited, and rebuilt without ever becoming an asset: ```luau local geom = renderer.mesh.geometry(h) -- { positions, indices, tangents?, ... } geom.positions[1] = 0.5 local h2 = renderer.mesh.create(geom) ``` An optional stream is present only when the mesh carries one, so `geom.tangents` answers whether the mesh has a tangent basis and `geom.uvs1` whether it has a second UV set. ## Read geometry — `meshRef:load()` `:load()` decodes `data.zmsh` into the CPU store and returns a CPU handle carrying `vertexCount` / `indexCount`: | Method | Returns | |---|---| | `cpu:getVertices()` | array of `{ pos = {x,y,z}, normal = {x,y,z}, uv = {u,v} }`, one per vertex | | `cpu:getTriangles()` | array of `{ v1, v2, v3 }`, each a full vertex (the shape above) | | `cpu:getBounds()` | `{ min = {x,y,z}, max = {x,y,z} }` — the local-space AABB | | `cpu:geometry()` | the complete `MeshGeometry` — flat arrays, every stream the mesh carries | | `cpu:encode()` | the `data.zmsh` bytes | | `cpu:unload()` | drop this guid's CPU copy | ```luau local cpu = meshRef:load() local v = cpu:getVertices()[1] -- { pos = {x,y,z}, normal = {x,y,z}, uv = {u,v} } local aabb = cpu:getBounds() cpu:unload() ``` By default the CPU copy is transient (decode → read → `unload`). Set `keepCpu` to keep it resident — see Settings. ## Write geometry back — `meshRef.primary` The inverse of reading: encode a `MeshGeometry` and write it to the asset's primary content file. The assetType picks the write up and re-uploads the live GPU mesh, so the change shows without a reload: ```luau local geom = renderer.mesh.geometry(meshRef) geom.tangents = computeTangents(geom) -- add a stream it did not carry vfs.write(meshRef.primary, renderer.mesh.encode(geom), { overwrite = true }) ``` `meshRef.primary` is the asset's `data.zmsh` path. This is the route for a stream with no setting of its own; `keepCpu` + `meshRef:setVertices` moves positions in place, and `lightmapUvs` regenerates the second UV set (both below). ## GPU handle — `meshRef:handle()` `:handle()` uploads the geometry (Disk → CPU → GPU) and returns a `MeshHandle`, cached on the asset so every consumer shares ONE GPU entry. A component does this for you when you pass it the mesh; call it directly only for the runtime/low-level path. ## Settings — `meshRef:settings()` / `meshRef:setSettings(patch)` A mesh's settings are declared in `settings.luau` and live in `settings.yaml`. `:settings()` returns them with every declared default filled in. `:setSettings(patch)` writes any subset — sibling settings are preserved, and a patch that fails the schema is refused, naming the field and why. | Setting | Type | Default | Meaning | |---|---|---|---| | `keepCpu` | boolean | `false` | Keep the CPU geometry copy resident — for an in-use mesh — so geometry can be read repeatedly without re-loading. | | `lightmapUvs` | string | `"keep"` | The mesh's second (lightmap) UV set. `"keep"` leaves the stored geometry's set as-is; `"generate"` unwraps a fresh non-overlapping set; `"none"` strips it. See below. | | `clusterLod` | boolean | `true` | How deep the cluster set is built. Every static mesh draws through clusters, from the frame it materialises (its `lod0` set) until its bake lands. `true` (default) builds the LOD hierarchy; `false` builds one level, drawn at full detail. | ```luau local s = meshRef:settings() -- { keepCpu = false } meshRef:setSettings({ keepCpu = true }) ``` `keepCpu` is an active lifecycle control, and only ever holds geometry for a mesh that is **in use** (GPU-resident): - Setting it **on** while the mesh is in use loads the CPU copy immediately. - Setting it **on** for a mesh that is **not** in use loads nothing — the copy is retained the next time the mesh is materialised, so an unused mesh is never pinned in memory. - Setting it **off** drops a resident CPU copy (the renderer keeps drawing from the GPU). `clusterLod` is the same kind of lifecycle control, for the depth of the cluster set rather than the CPU copy: - Setting it **off** on a mesh in use rebakes it as one level of clusters (`single`), drawn at full detail. - Setting it **on** on a mesh in use rebakes the LOD hierarchy (`dag`). - A mesh that is not in use bakes at the depth the setting asks for when it next materialises. Acting on either setting for a mesh in use can read the mesh's stored geometry, and where the geometry is fetched on first read that read spans frames. `meshRef:settingsPending()` answers whether one is still in flight; once it answers `false`, every settings change made so far has reached the mesh. ### Second UV set (`lightmapUvs`) A mesh can carry a **second**, independent UV set (`uv1`) alongside its texture UVs (`uv`) — a distinct per-vertex channel, non-overlapping where the texture UVs tile and reuse charts. `lightmapUvs` controls whether the stored geometry keeps one, generates one, or drops it: | Value | Effect | |---|---| | `"keep"` | Leave the stored geometry's `uv1` as-is (the default). | | `"generate"` | Unwrap a fresh non-overlapping `uv1` (near-planar charts packed into `[0,1]` with gutters). | | `"none"` | Strip the `uv1` set. | ```luau meshRef:setSettings({ lightmapUvs = "generate" }) ``` Changing the setting reprocesses the asset's geometry in **edit** mode; a change in play mode never rewrites the source. The reprocess round-trips the geometry through the codec, so positions, normals, tangents, skinning, and the skeleton are preserved — only the `uv1` set changes. A runtime mesh carries `uv1` the same way: pass `uvs1` (or `unwrapUvs = true`) to `renderer.mesh.create`. ## Read vertices — `meshRef:getVertices()` With `keepCpu` on for an in-use mesh, read its vertices straight from the resident CPU copy: ```luau meshRef:setSettings({ keepCpu = true }) -- on an in-use mesh local verts = meshRef:getVertices() -- { { pos = {x,y,z}, normal = {x,y,z}, uv = {u,v} }, ... } ``` If the CPU copy isn't resident — `keepCpu` is off, or the mesh isn't in use — it errors loudly, naming the reason and the remedy, rather than silently loading a throwaway copy: ``` mesh:getVertices: cannot read vertices — keepCpu is off, so no CPU copy is kept. Turn on CPU retention for an in-use mesh first: meshRef:setSettings({ keepCpu = true }). ``` ## Morph targets — `meshRef:morphTargets()` A mesh can carry morph targets: shapes it blends towards, each a per-vertex displacement from the base geometry. Every target carries the name it was authored under, and an imported model keeps the one its source file gave its blend shapes, so content addresses a shape as the thing it means rather than as the ordinal it happened to import at. ```luau for i, name in meshRef:morphTargets() do print(i, name) end -- 1 Eyes_Blink ``` An entity blends them with `ecs.MorphWeights`, weight `i` driving target `i`. `renderer.mesh.morphWeights(mesh, { Eyes_Blink = 1 })` builds that ordered array from weights named by shape — shapes left out sit at 0, and an unknown name errors listing the ones the mesh carries. ## Discovery | Call | Shows | |---|---| | `asset.list("mesh")` | every registered mesh | | `asset.inspect("<name>")` | a text report about the mesh (metadata, source, status) | | `meshRef:settings()` | the resolved settings | | `meshRef:settingsPending()` | whether a settings change is still reading the stored geometry | | `meshRef:morphTargets()` | the shapes it blends towards, named, in target order | For the on-disk shape of a mesh asset, run `asset.inspect("<name>")` or read the type's `type.yaml` — those are the live source of truth. ## Related - `renderer.mesh.*` — the GPU/CPU resource layer (`create` a runtime GPU mesh, `encode`/`decode` the `ZMSH` payload, `readback` GPU → CPU). `:load`/`:handle` wrap it; see `man renderer`. - `.material` + `.shader` — what shades the geometry. - `.bundle` — container assets that carry `.mesh` interiors. ## In the Inspector Selecting a mesh opens its **Geometry** section, after the asset's identity and before its Settings. It reports what `data.zmsh` holds, decoded once per payload version: vertices, triangles, the bounds and their size, the vertex streams beyond positions (normals, uvs, uvs1, colors, tangents, skinning), and, when the mesh has them, its skin joints and morph targets. While the renderer holds the mesh's cluster hierarchy, the section also reports its cluster and level counts. A payload is one index stream, so the section names no submeshes. A mesh folder with no `data.zmsh` says so.

# Model Loads and displays a 3D mesh on an entity. Disabling the component hides the mesh. Supports procedural meshes (`cube`, `sphere`, ...), model files, and remote URLs. Tint and outline are shader effects applied to the mesh. **Material lives on this component.** There is no standalone `Material` component — a material only renders where there is a mesh to render it on, so the `material` field is part of Model (and SkinnedModel). Set it at add time or assign the field later; properties are registry-wide. Public fields: `model`, `material` (`AssetRef<material>`), `tintR/G/B`, `tintBlend`, `outlineR/G/B`, `outlineIntensity`. Methods: `:setTint(color, blend?)` (color: `{r, g, b}` array or `{r=, g=, b=}` map), `:clearTint()`, `:setOutline(color, intensity?)`, `:clearOutline()`, `:setMaterialProperty(prop, value)`, `:getMaterialProperty(prop)`, `:getMaterialPropertyNames()`. ```luau entity(id).component.add("Model", { model = "cube", material = "gold" }) entity(id).component.get("Model").material = "checkerboard" -- swap material entity(id).component.get("Model"):setTint({1, 0, 0}, 0.5) entity(id).component.get("Model"):setMaterialProperty("roughness", 0.2) ``` **Tint is synced.** Every `tint*` field replicates, so `:setTint` is the colour every participant sees. A colour that changes every frame on many entities (a stress map, a heat map, a damage flash, per instance colour) belongs in an instance-data lane instead: wear `@builtin::materials.instance_color` (or `instance_color_unlit`) and write `renderer.instanceData.set(id, 2, r, g, b, coverage)`, which replicates nothing and costs about a twentieth of a tint write. `guides { path = "topics/rendering-instance-data" }` has the lane layout.

# Locomotion Blend-space-driven locomotion for entities running the characterController package. Reads horizontal velocity from a sibling `MovementState` (or, as a fallback, `CharacterController`) component on the parent and feeds a single 2D blend space (strafe-angle on X, speed on Y) with idle / walk-{F,L,R,B} / run-{F,L,R,B} / sprintF clips. Each clip's point sits at the speed the clip carries this body at: its retarget bake measures how fast the ground passes under the stance foot on this body's legs, so the feet move with the ground at whatever speed the body moves. A clip that plays without a measured speed sits at its gait's `walkSpeed` / `runSpeed` / `sprintSpeed`. Pair on the same entity (or a parent of) a `SkinnedModel`. The component creates the AnimGraph, polls for the SkinnedModel child once start() has run, registers the clips as blend-space points and plays the graph. `update()` damps speed + angle and writes them to the active blend space each frame. This supersedes the older FSM-based Locomotion controllers (crouch / jump / fall / land / turn-in-place state machine). Those behaviours can be added back as separate layered graphs once the blend-space driver has settled.

# Text3D Renders text in 3D world space. The quad auto-sizes to fit the text content and never clips. Positioning works like TextMeshPro: `offsetX/Y/Z` is a local offset from the entity, `pivotX/pivotY` is the anchor within the quad, and `billboard` makes it face the camera. With `billboard = false` the text reads from the entity's own forward, the local -Z that `transform.forward` reports and that `entity:lookAt` aims. Sizing — three fields, two jobs: - `worldHeight` — the quad's height in **world units** (default `1.0`). This is the one field that resizes a label, and it holds that height under every transform between the label and the world: a label hung off a shrunken detail box on a model comes out the size it asked for, and so does one whose own entity carries a `localScale`. Width follows the rasterised text's aspect. Measure the result with `getWorldSize()`, which reports the extent the quad is drawn at. - `fontSize` — the **raster resolution** in texels (default `32`). Higher values sharpen the texture and change wrapping against `maxWidth`; the world-space size stays `worldHeight`. - `scale` — rasterisation scale multiplier applied at raster time. Resolution only, like `fontSize`. `maxWidth` is the width the text wraps at, in pixels of the raster `fontSize` states; `0` keeps it on one line. A label already drawn is laid out again when the field is written, so a caller re-wraps one label to line after line rather than making a label per line. `alphaCutoff` decides whether the letters are a surface. At `0` (the default) the text is pure alpha blending: it draws over what is behind it and leaves the depth buffer alone, so a screen-space effect that reads scene depth — volumetric fog, screen-space shadows — integrates the whole distance behind the letters and the text sits inside it. Above `0`, coverage at or over the threshold is drawn opaque and written to depth, so those effects stop at the glyph shape instead. `0.5` reads well for most fonts; higher thins the letters, lower keeps more of the antialiased edge. Public fields: `content`, `fontSize`, `color`, `alignment`, `richText`, `maxWidth`, `outline`, `outlineColor`, `background`, `scale`, `worldHeight`, `alphaCutoff`, `shadowX/Y`, `fontFamily`, `weight`, `slant`, `offsetX/Y/Z`, `pivotX/Y`, `billboard`. `weight` and `slant` are strings (`"regular"` / `"bold"`, `"normal"` / `"italic"`). Methods: `setText(content)`, `setStyle(options)`, `getText()`, `getSize()`, `getWorldSize()`, `refresh()`. ```luau entity(id).component.add("Text3D", { content = "Hello World" }) entity(id).component.add("Text3D", { content = "HP: 100", worldHeight = 0.5, fontSize = 96, color = "red", offsetY = 2.0, pivotY = 0 }) -- A title that keeps its letters crisp through volumetric fog. entity(id).component.add("Text3D", { content = "RAISING", worldHeight = 3.0, alphaCutoff = 0.5 }) ``` A label that is not showing, or came out in a face you did not ask for, reads back out of the text system: `text.observe()` lists every live text object with the entity that owns it and the texture its raster is in, and `text.face(h)` names the font face the shaper actually used against the `fontFamily` that was requested. `topics/text` walks both.

# `retarget` module `require("modules.retarget")` — skeletal animation retargeting in readable Luau. Map a clip authored on one humanoid rig onto another, preserving the target's shape. The behaviour lives here, in Luau, so an agent can follow and tweak it. ## How it works Each rig maps onto the humanoid avatar type — a role → bone map derived from the skeleton's structure, with the author's overrides laid over it (`rig:qualify()`, see the `rig` asset type). Retarget is two steps: 1. **Bone map** — source bone → its role → the target bone filling that role. Roles are the shared vocabulary, so any two rigs interoperate through their mappings without a per-pair table. 2. **Shape-preserving transfer** — the target keeps its own bone lengths and rest orientations; the animation contributes only delta-from-rest motion. Rotations are bind-pose-corrected (the target reproduces the source's world-space motion relative to its own rest). Only the pelvis and the root carry translation: the pelvis's offset is taken through its animated source parent, stood on the axis the source stands along, sized by the leg-length ratio (thigh plus shin, the same in every pose) and re-expressed in the target pelvis's animated parent frame, then applied relative to the target's bind. A source root's travel rides the target root, or folds onto the target pelvis when the target has no root. Every other bone keeps the target's own offset, so no limb or spine stretches. Retarget is **cold**: `bake` once per (clip, target rig) and cache; the hot path just samples the baked clip, exactly like a native one. ## Surface - `parseRig(rig)` → enriched rig. Accepts a parsed `.rig` table, a `.rig` JSON string, or an already-parsed rig (idempotent). - `plan(srcRig, tgtRig)` → `{ mapped, unmappedSource, unmappedTarget, … }` — which roles map across the rigs, and which don't (the diagnostic). - `bake(clip, srcRig, tgtRig)` → a decoded clip table in the target's bone space. `clip` is a decoded clip (`{ name, duration, channels, bone_names }`). - `bakeBytes(clipBytes, srcRig, tgtRig, cacheKey?)` → retargeted clip `zanim` bytes, with an in-memory cache keyed by `cacheKey`. - `loadRig(ref)` → parsed rig from a `.rig` asset. - `clearCache(cacheKey?)` → drop cached bakes (call after editing a rig profile). ## Example ```lua local retarget = require("modules.retarget") local src = retarget.loadRig(asset.ref("synty_character", "rig")) local tgt = retarget.loadRig(asset.ref("hero", "rig")) -- inspect the mapping local plan = retarget.plan(src, tgt) print(plan.mapped.leftarm.source, "->", plan.mapped.leftarm.target) -- bake a walk clip onto the hero rig (cold, cached), then sample it like any clip local walkBytes = vfs.read(asset.source("walk", "animation") .. "/data.zanim") local walkOnHero = retarget.bakeBytes(walkBytes, src, tgt, "walk|hero") local bind = skeleton.bindClip(walkOnHero, heroBoneOrder) ```

# scene_instantiable (module) The instantiation contract's shared implementation. An asset type opts into scene instantiation by defining `instantiate(self, target?, opts?)` on its behaviour `ref` table; this module carries the parts that mean the same thing for every type, so a caller writes ONE piece of code against all of them. ```lua local root, idMap = ref:instantiate(target?, opts?) ``` ## The contract **IN — the base opts.** `target` is an owning entity ref: the instance lands under (or, for a hierarchy type like a bundle, onto) that owner. With no target the type spawns a fresh root. `position`, `rotation`, `scale`, `name` and `temporary` place that root and mean the same for every type. `rotation` takes three numbers as pitch/yaw/roll in DEGREES, or four as a quaternion. A type may honour more opts of its own — `params` for a type built from declared inputs, `idMap` / `diff` / `sourceTag` for the bundle override contract — and says so in its own `instantiate` docs. **OUT — the two returned values.** Every type returns the same pair: - **`root`** — the composed root, as an `EntityRef`. Composition is **synchronous**: the root and everything the type built under it are live the moment the call returns, so a caller can parent to it, read its components and hand it on in the same statement. There is no frame to wait for and no callback. - **`idMap`** — the `originalId -> runtimeId` map naming what the composition spawned, `{}` for a type with no addressable children. **Never nil.** A component that re-composes the asset on every load (`Asset`) keeps this map and passes it back in, which is how a cross-entity reference into the composition — `SkinnedModel.skeletonRoot` pointing at a bone — survives a reload. The return is enforced, not merely described: `AssetRef` dispatches every `ref:instantiate(...)` through `result` on the way out, whether or not the type called it. A type that returns something else fails at its own call rather than handing its caller a nil root or a map that is sometimes absent. ## Exports - `M.root(self, target?, opts?) -> root` — stand the root entity for a type that spawns one: parented to `target`, born temporary when `opts.temporary`, named `opts.name` else the asset's own name, placed. - `M.place(root, opts?) -> root` — apply the placement opts to a root the type already has (the adopt path: a bundle exploding onto its target, a sceneModule reconciling under one). - `M.result(self, root, idMap?) -> (root, idMap)` — return through the contract. Checks `root` is a live entity ref, normalises a missing map to `{}`, and errors naming the asset type when either is something else. - `M.isOwned(opts?) -> boolean` — whether a component drives this call. The `Asset` / `SceneModule` components tag their own calls with `sourceTag`; they hold the reference and re-compose on every load. An untagged call came straight from `ref:instantiate(...)` and has no such owner. - `M.own(root, self, idMap?) -> root` — hand an already-composed root to an `Asset` component pointing at `self`, so the reference and its map persist and the composition is rebuilt on the next load. The component adopts the live composition rather than building a second one. - `M.check(value, constraint) -> ok, reason?` — the `sceneInstantiable` field-constraint validator, also registered under that kind on load. ## The field constraint `Field.instantiableRef` emits `constraint = { kind = "sceneInstantiable" }`, and this module registers the validator for it on load. Given a written value: 1. `nil` passes — the field is optional (no asset assigned). 2. Reads the value's identity — a bare string, or a table's `__ref` / `guid` / `identity` / `name`. 3. Resolves it (`asset.resolve(identity)` — any category) and asks the resolved ref `ref:canInstantiate()`: true iff the asset's type defines an `instantiate` method. This is what lets `Field.instantiableRef` accept by CAPABILITY rather than a hardcoded type list — a new scene-instantiable asset type is accepted the moment it defines the hook, with no edit to the field or its consumers.

# PlayerNameLabel Drives this entity's `Text3D` with the owning player's name, read from the nearest ancestor `PlayerAvatar`'s synced `displayName` so every peer renders the same name without a local registry lookup. The label re-rasterises when the display name changes, and in play it hides itself on the local player's own avatar, since name labels exist so other players are identifiable. A label shows a name or nothing: an avatar with no `PlayerAvatar` (a stock avatar placed as a non-player character) or one whose `displayName` is empty has its label's text emptied and the label hidden. Location: `src/lua/lib/components/PlayerNameLabel.component`

# Asset Promote the bundle's spawned children from temporary to permanent scene state and remove the Asset component, "baking" the bundle's contents directly into the owning scene. Subsequent saves persist the baked entities verbatim and stop replaying the bundle template. Location: `src/lua/lib/components/Asset.component`

# references What content of a carried mount means by the asset references it holds. A carried mount holds the closure of an asset of another world, and that content names assets the way its own world named them: by the guid, path or identity the closure states. Read at the site of the asset holding them, inside the mount, those references name the closure's own copies (each known in this session by its session guid) and the engine library at the version the closure was built against, through `asset.tryResolve(ref, type, site)`. The open world's asset under the same guid or name is another asset. A bundle of a carried mount composes from its template through `records`, and an `Asset` instance of it measures its overrides against the same records, so a reference the closure answers is the same value on both sides. ## Exports - `M.site(path, identity?) -> (site?, prefix?)` - where an asset of a carried mount stands: its path in the mount (its carried identity when no path is given) and the prefix its mount spells content with (`@carried.<key>::`). Both nil for an asset of the open world. - `M.close(value, site, prefix) -> value` - a copy of decoded component data with every asset-reference envelope (`{ __ref, type?, name? }`), at any depth, naming what the closure at `site` means by it: the guid it resolves to there, or, while the mount answers nothing for it, the reference spelled in the mount (`@carried.<key>::<reference>`), which waits on the mount and applies once the mount holds the asset. A component reference (`componentType` beside `__ref`) stays as written. - `M.records(template, path, identity?) -> template` - the records of an entity template as the asset at `path` composes them: closed through `close` for an asset of a carried mount, `template` itself for an asset of the open world. ## Usage ```luau local references = require("modules.api.engine.carried.references") local records = references.records(bundleRef:getTemplate(), bundleRef.path, bundleRef.identity) local site, prefix = references.site(bundleRef.path, bundleRef.identity) if site ~= nil then local data = references.close({ material = { __ref = guid, type = "material" } }, site, prefix) end ```

# Humanoid Marker component for entities carrying a skeleton conforming to the standard humanoid bone layout (Synty / Unreal-Mannequin convention). Content reads a humanoid body's bones and attachment sockets through this component instead of re-walking the descendant tree, and seats items on those sockets with `:attach`. ## Bone naming convention ``` Hips Spine_01 → Spine_02 → Spine_03 → Neck → Head └ Eyes, Eyebrows, Jaw UpperLeg_R / UpperLeg_L LowerLeg_R / LowerLeg_L Ankle_R / Ankle_L Ball_R / Ball_L → Toes_R / Toes_L Clavicle_R / Clavicle_L Shoulder_R / Shoulder_L Elbow_R / Elbow_L Hand_R / Hand_L IndexFinger_01..04 / Thumb_01..04 / Finger_01..04 ``` Mixamo / Unity-Humanoid imports go through a bone-rename pass at import time (tracked separately). ## Fields | Field | Type | Notes | |---|---|---| | `height` | number | Foot-to-head height in T-pose, metres. Default 1.8. | | `eye_height` | number | Foot-to-eyes height, metres. Default 1.65. | | `bones` | `{ [string]: entity }` | Computed; bone-name → entity-proxy map. Re-walks on read. | | `sockets` | `{ [string]: entity }` | Computed; role (`righthand`, `head`, …) → the bone filling it on this body, through the body's RetargetProfile. | ## Methods | Method | Returns | Notes | |---|---|---| | `:bone(name)` | `entity \| nil` | Nil-safe single-bone lookup; same as `self.bones[name]`. | | `:socket(point)` | `entity \| nil` | The bone at a role, or at an exact bone name. | | `:attach(point, childId, opts?)` | `entity \| nil` | Seats `childId` on the socket bone at the socket's frame, moved by `opts.position` / `opts.rotation` / `opts.scale`. Position and scale are metres in the humanoid's own space, whatever bone units the rig was authored in; rotation is relative to the bone, as a quaternion `{ x, y, z, w }` or Euler degrees `{ pitch, yaw, roll }`. An option outside those three, or a value in none of those forms, raises with the item left as it was. Returns the socket bone. | | `:attachments()` | `{ { id, point, position, rotation, scale } }` | Every item seated with `attach`, with the point and transform it was seated with. An avatar body swap re-seats each on the new body. | ## Usage ```luau -- Read a specific bone local h = entity(playerId).component.get("Humanoid") local head = h.bones.Head -- entity proxy local handR = h:bone("Hand_R") -- nil-safe lookup -- Seat a hat 12 cm above the head, on any humanoid body local hat = entity.spawn("hat") h:attach("head", hat.id, { position = { 0, 0.12, 0 } }) -- Read height for camera mounting local cam = entity.spawn("eye_cam", { parent = playerId }) cam.localPosition = { 0, h.eye_height, 0 } ``` ## Tag convention Bundles carrying a humanoid skeleton tag themselves with both `playerVisual` AND `humanoid` in their `.metadata`. Tooling can filter to humanoid-conforming visuals via `asset.list("bundle", nil, { fields = { tags = { "playerVisual", "humanoid" } } })`.

# json JSON encode/decode library for Luau. Encodes Lua values to JSON strings and decodes JSON strings back to Lua values. Used for communication with the Rust side of the engine, the VFS read/write bridge, and any wire-format that needs JSON. Pure Luau, no engine dependencies. Compact and pretty-printed encoders, plus a hand-rolled decoder that streams the input by position so it works under WASM as well as native. ## Exports - `Json.encode(value: any, indent?: string, currentIndent?: string) -> string` — compact encode. Functions / unknown types and NaN/Inf encode as `null`. - `Json.encodePretty(value: any, indentStr?: string) -> string` — pretty-printed encode with sorted object keys (diff-friendly). - `Json.encodeArgs(...: any) -> string` — encode varargs as a JSON array. - `Json.decode(str: string) -> any` — decode a JSON string. Returns the decoded value, or `nil` + error message on failure. ## Usage ```luau local Json = require("@builtin::modules.json") local widget = { type = "button", text = "Click Me" } local compact = Json.encode(widget) -- '{"text":"Click Me","type":"button"}' local pretty = Json.encodePretty(widget, " ") local decoded = Json.decode(compact) local v, err = Json.decode("oops") -- v = nil, err = error message ``` ## Notes - Object keys are sorted alphabetically in both encoders for consistent output across runs. - Numeric keys on objects are stringified at encode time (JSON has no numeric keys). Pure-integer key sets get detected as arrays via `isArray` and encoded with brackets. - NaN, +Inf, -Inf encode as `null` — JSON has no representation. Round trips through `decode` recover `null` (Lua `nil`), so they don't preserve. - Unicode `\uXXXX` escapes decode to UTF-8 by hand to stay WASM-safe. Only the BMP is covered; supplementary planes via surrogate pairs are not. - Functions encode as `null`. - Decode is character-streamed — no regex, no `string.match` patterns on the whole input — so the line-and-column information needs to be reconstructed from the position offset.

# SkinnedModel Component that drives skinned model playback and animation graph integration. Like `Model`, it carries the `material` field (`AssetRef<material>`) — material lives on the model that renders it, not as a standalone component. Set it at add time or assign `entity(id).component.get("SkinnedModel").material = "..."` later; `:setMaterialProperty` / `:getMaterialProperty` / `:getMaterialPropertyNames` operate on the assigned material (registry-wide). **Tint is synced.** Every `tint*` field replicates, so `:setTint` is the colour every participant sees. A colour that changes every frame on many characters (a damage flash, a team colour, a heat map) belongs in an instance-data lane instead: wear `@builtin::materials.instance_color` (or `instance_color_unlit`) and write `renderer.instanceData.set(id, 2, r, g, b, coverage)`, which replicates nothing. `guides { path = "topics/rendering-instance-data" }` has the lane layout. ## Blend model `skinning` chooses how the pass combines a vertex's joint influences. - `"linear"` (default) averages the joint matrices themselves. The average of two rotations is not a rotation, so a strongly twisted joint loses volume toward its axis — at a 180° twist a limb collapses onto the axis entirely. - `"dualQuaternion"` averages the joints' rigid motions as unit dual quaternions and renormalises, so the blend is a rotation at every weight and the cross-section is carried through the twist. Non-uniform joint scale rides along as a separately blended stretch. It costs a quaternion extraction per influence, so it is worth setting on characters whose wrists, shoulders or spine twist far, and leaving off elsewhere. ```lua entity.find("hero").component.get("SkinnedModel").skinning = "dualQuaternion" ``` A rig at rest renders identically under either model. ## Render self-check A few frames after its mesh attaches, a SkinnedModel checks that the mesh names something the engine can draw (on the GPU, or held off the device until this display puts it back) and that the pose it is drawn in has not collapsed it: the posed vertices the skinning pass wrote are measured against the mesh's own bind-pose extent, so a 1 cm part of a prop is judged by its own size. A mesh that fails is swapped for the builtin ERROR marker, drawn un-skinned with the error material, and the reason is logged. Setting `model` again takes the marker down and checks the new mesh. `renderCheck()` answers the verdict: `{ state = "pending" | "passed" | "failed" | "skipped", reason }`. ```lua local v = entity.find("prop_part").component.get("SkinnedModel"):renderCheck() if v.state == "failed" then print(v.reason) end ```

# assetType runtime The machinery that reads a `<typename>.assetType/behavior.luau` and turns its declarations into live behaviour. A `behavior.luau` is a table of declarations — `ref` methods, `modules` shared code, an `events` schema, a `namePattern`, `refShapes`, and the `onCreate` / `onRegister` / `onChange` / `onDelete` / `validate` / `settingsDefaults` / `settingsCorrections` hooks. None of it runs itself. This is the code that runs it, and it lives here because reading a type's declarations is the **assetType type's own behaviour** — the same way `material.assetType` owns what a `.material` does. ## Sub-modules | Module | Reads | Responsibility | |---|---|---| | `ref.module` | `ref`, `modules` | Builds every `AssetRef` envelope, attaches the shared metatable, and dispatches per-type methods and shared modules onto it. Also owns edit-mode write-behind persistence. | | `create.module` | `onCreate`, `namePattern`, `validate` | Backs `asset.create`: resolves the type, checks the name against its pattern, runs `onCreate` (or clones `template/`), and writes the instance. `validate.module` beside it checks a creation `opts` table against the type's `createSchema`. Before running `onCreate`, resolves the type's settings chain (below) and hands the result to the hook as `opts.settings`. | | `settings.module` | `settings`, `settingsDefaults`, `settingsCorrections` | A type's declared settings schema and where its values live (`type.yaml`'s `settings:` block). `Settings.resolveForCreate` layers the schema's own defaults, the type's own `settingsDefaults(name, opts, asked)` hook (a DEFAULT the schema can't express — a name-derived convention, a fact read off a payload the caller handed it, a value following a field `asked` shows a higher layer naming; any later layer overrides it), the Preset Manager, an importer's settings, the caller's `settings` table, then the type's own `settingsCorrections(values, name, opts)` hook (a CROSS-FIELD CONSTRAINT the schema can't express, applied last over the fully merged values). A correction over a default/preset/importer value lands silently; a correction that would override what the caller's own `settings` table explicitly asked for refuses the creation instead, naming the field and why. Neither hook is ever handed a table to mutate; each returns what it wants changed (`settingsCorrections` may also return a `{ [field]: reason }` table for that refusal message). `Settings.cloneValues` deep-copies a values table — `create.module` hands `onCreate` a copy, never the table it stamps. `Settings.valuesOf` / `writeValues` read and write an asset's own values file. | | `typeYaml.module` | `type.yaml` | The folder a type lives in and its parsed `type.yaml`, decoded once per content version of the file. `settings.module` and `inspector.module` read their blocks through it. `about` / `aboutAt` read a type's `about.yaml` (`intent`, `function`, `usage`), leaving out any key that is empty or still starts with `[[describe]]`; `aboutRows` and `aboutMarkdown` lay the texts out for the Inspector and the `types/<name>` guide. | | `inspector.module` | `type.yaml`'s `inspector:` block | Which inspector a type declares for its assets (`inspector: { type: ... }` or `{ instance: ... }`), and the declaration that file returns — the sections it adds, the generic ones it replaces, and their order — or the problem that kept it from loading. | | `onRegister.module` | `onRegister` | Fires an instance's once-only registration hook — on arrival, on world load, and for `@builtin` library instances. | | `changeDispatch.module` | `onChange`, `onDelete`, `refShapes` | Routes a VFS source write or a folder delete to the enclosing typed asset's type hooks. | | `refShapes.module` | `refShapes`, `ref` | Publishes what every `AssetRef<category>` answers to, so a member read on an asset-typed value is checked against that category's real surface. | | `events.module` | `events` | The per-asset event runtime behind `ref.events`. | | `instantiable.module` | `ref.instantiate` | The instantiation contract an asset type opts into: `root` stands the root entity, `place` applies the base placement opts to one the type adopted, and `result` shapes the `(root, idMap)` every `instantiate` returns. Also registers the `sceneInstantiable` field-constraint validator. | | `declaration.module` | `type.yaml` | The type's decoded declaration, read once and held until a write inside an `.assetType` folder; what every question about a type as a whole reads. | | `previewRecipe.module` | `type.yaml` `preview:` | How an instance's `preview.png` is produced: which of the four recipes (`instantiate`, `image`, `surface`, `custom`) the type declares, and what that recipe needs. | ## Reaching it ```luau local rt = require("@builtin::assetTypes.assetType.shared") rt.ref.loadTypeBehavior("material") ``` Fields resolve lazily. The prelude requires the sub-modules directly, in dependency order (`ref`, then `changeDispatch`, `onRegister.install()`, `refShapes.install()`) — a table that required all six on load would take that ordering away from it.