Inventory method
The documented baseline contains 19 node types and 45 engine systems. Coverage was established by
enumerating engine registrations, then checking src/world for explicit construction and
loader-generated use. A node is marked available when the engine implements it but no world script
instantiates it directly.
Interpretation
Available does not mean incomplete. It means the capability is implemented below the product layer and has not been selected for the current town.
Node coverage
| Node | Baseline instances | Status | Primary use |
|---|---|---|---|
uitext | 66 | Active | In-world text and readouts |
prim | 47 | Active | Scripted boxes, spheres, and planes |
ui | 30 | Active | In-world interface surfaces |
action | 29 | Active | Proximity interaction prompts |
particles | 10 | Active | Environmental effects |
uiview | 9 | Active | Layout inside in-world panels |
group | 9 | Active | Transform hierarchy |
anchor | 6 | Active | Attachment points |
audio | 5 | Active | Positional sound |
sky | 2 | Active | World sky configuration |
GLB loading creates mesh, skinnedmesh, collider, and
rigidbody nodes from asset conventions. They are active through the loader and are not
counted as direct script construction.
System coverage
Engine systems are lifecycle services attached to one shared World object. They cover
networking, physics, rendering, input, entities, scripts, UI, audio, assets, controls, and environment
state. Each runtime installs only the systems it needs.
| Group | Browser | Server | Headless resident |
|---|---|---|---|
| World and entities | Yes | Yes | Yes |
| PhysX simulation | Yes | Yes | Yes |
| Three.js rendering | Yes | No | No |
| Input and controls | Human input | No | Programmatic control |
| Persistence and authority | No | Yes | No |
| Audio and media output | Yes | No | No |
Implemented capabilities not selected by the town
| Capability | Engine primitive | Status | Engineering implication |
|---|---|---|---|
| MP4 and HLS surfaces | video | Available | Linked surfaces can share a decoder while retaining positional audio emitters |
| Direct world images | image, uiimage | Available | Supports images in world space or inside structured panels |
| Facing labels | nametag | Available | Camera-facing labels without custom billboard scripts |
| Physical hinges and springs | joint | Available | Enables articulated doors and connected physics objects |
| Distance-based asset substitution | lod | Available | Reduces geometry and material cost at distance |
| Placement constraints | snap | Available | Supports modular, constrained in-world construction |
| Scene-object avatars | avatar | Available | Renders a VRM independently of a connected player |
| XR controls | ClientControls | Available | Controller poses and button bindings exist but lack product-level acceptance evidence |
Runtime constraints
- Video decoding cost is per source, not per linked surface; material and draw cost still scale with visible surfaces.
- XR support in the engine is not equivalent to a tested Thirdwurld VR product path.
- Prompt-based in-world scripting requires configured model credentials and remains disabled without them.
- The repository contains no active Web3 implementation in this fork, despite upstream historical references.
- Legacy voice documentation refers to LiveKit behavior that has been removed from the current source.
Engineering priorities
| Priority | Reason | Acceptance evidence |
|---|---|---|
| Level of detail | Directly addresses rendering cost in a dense 3D town | Measured draw-call, triangle, and frame-time reduction |
| Media surfaces | Enables cinema, broadcast, and public-event use cases with existing primitives | Desktop/mobile playback, decoder count, audio, and fallback behavior |
| Physics joints | Adds physical interaction without creating a new simulation layer | Server/client agreement and failure-safe object state |
| XR | Engine support exists, but product ergonomics and performance are unverified | End-to-end headset interaction and frame budget |