Skip to content

Ingesting unmodified games

The headline capability: vgai’s editor can load and edit a three.js game it didn’t author, without modifying the game’s code.

The render-accessor trap captures the game's live scene for direct in-realm editing
Capture the live scene and edit it directly — the live objects are the document.

IngestRootAdapter (packages/editor/src/authoring/ingest-root-adapter.ts) captures an unmodified game’s live scene + camera via the render-accessor trap — it observes the game’s own renderer.render(scene, camera) call to grab the objects, with zero edits to the game. It returns a MountedRoot that drives its own loop.

After capture, the host adopts the game’s canvas into the editor’s game pane. A hybrid DOM+canvas game — a React/R3F app with HTML HUDs, overlay panels, or drei <Html> portals — can declare the element that owns its canvas by setting window.__vgaiGameRoot in its entry module; the host then adopts that root wholesale, so the game’s DOM UI travels with its canvas instead of stranding at page level over the editor chrome. Games that declare nothing keep the bare-canvas behavior. The whole game-side obligation is ordinary embed hygiene: create a container, mount into it, declare it, and keep your own position: fixed UI contained (transform: translateZ(0) on the container).

LiveThreeAuthoringAdapter implements the AuthoringAdapter directly over the live Object3D tree — it does not fabricate a SceneEntity. It is the same adapter that drives a first-party live scene, parameterized by an identity provider: a foreign game gets structuralIdentity, so nodes get structural-path ids (stable across reloads) and selection/transform/inspector work on the foreign objects as-is.

Vendored reference copies are live-only: edits drive the running game and nothing persists them — the vendored source is never touched. A game you own persists through the ingest-authoring model: edits become ordinary source edits in YOUR files. There is no sidecar of any kind.