Three-Live: AI-Written 3D Across Web and Mobile

Highlights and Current Evidence

Three-Live helps developers turn AI-written Three.js scene code into 3D content that can be displayed on the web and in native mobile applications. Its central idea is to use a supported subset of Three.js as a portable scene description, then compile the resulting scene into GLB or USDZ. It supplies a compiler, renderers, and integrations; an external model can write the code.

Image source for the Studio, architecture, and XR figures: Google Open Source Blog.

The repository is under Google’s organization but explicitly says it is not an officially supported Google product. Its current README labels the project Beta. Official examples demonstrate procedural geometry, PBR materials, animation, and spatial interaction across WebGL2/WebXR, Android Filament and Jetpack XR, and Apple RealityKit. These demonstrate intended workflows rather than a device-wide performance guarantee.

The launch article reports typical compilation times of 2–5 milliseconds without a complete hardware-and-scene benchmark protocol. That figure must not be read as total image-to-3D latency. The repository also includes a 100-prompt evaluation suite and a 10-script smoke suite covering compilation, unsupported-feature diagnostics, rendering, simulation, and one-turn repair; their presence alone is not evidence that every generated script works.

From Code to a Native Scene

An author or coding model constructs meshes, materials, transforms, and groups through the supported API. The host executes the script in a constrained environment. On native platforms, ThreeEngine embeds the Boa JavaScript engine in Rust, resets scene/global state, executes the script, and extracts a typed SceneGraph from raw buffers. The GLB entry point passes that graph to write_glb; separate paths produce USDZ. The intermediate representation is an explicit scene graph, not a learned 3D latent.

Execution limits matter because generated code can contain runaway loops or excessive geometry. In the reviewed source, production script execution is capped at 500 milliseconds, with the clock checked every 10,000 VM opcodes. Scene ceilings include 100,000 vertices and 1,000 meshes. A separate packaging deadline applies to transcoding. These are protective limits defined by the implementation, not render-speed measurements or a claim of perfect isolation. The web path uses a worker, with an optional opaque-origin iframe; network and storage access are constrained.

After compilation, platform adapters load the asset into the target renderer. Android uses Filament and XR integrations; Apple platforms use RealityKit; the browser has its own WebGL2 renderer and WebXR support. Declarative userData.xr traits describe supported behaviors such as grabbing or spatial anchoring. Live runtime behavior requires the corresponding runtime integration: a static operating-system model preview does not preserve arbitrary JavaScript interaction.

The agent workflow adds a verification loop. The CLI can validate a script, render a four-view contact sheet, and convert assets; its MCP interface exposes these operations to coding agents. The evaluation harness can return compiler diagnostics and visual critiques for one repair turn. This connects code generation to observable geometry and framing, while unsupported or degraded API features remain something to inspect rather than assume away.

Applications and Development Status

Three-Live is relevant to procedural product viewers, editable educational scenes, AR prototypes, and AI-assisted 3D authoring inside applications. It can reduce platform-specific scene-authoring work, but does not promise full compatibility with arbitrary Three.js applications. Package and binary options include npm, Rust tooling, Android libraries, and Apple Swift Package Manager; the repository uses Apache-2.0.

The official Unreleased changelog is the basis for development directions here. It lists runtime image-to-scene generation with spatial quality checks and one-turn repair, plus optional WebGPU scene and Gaussian-splat acceleration. These are implemented development-branch entries, not promises that every packaged release includes them. The image path checks minimum mesh count, finite bounds, camera coverage, and critical overlaps; those checks do not prove faithful reconstruction of the input image.

This review inspected the compiler entry point, execution limits, scene representation, evaluation documentation, and changelog. It did not install the SDK or measure performance on devices.