Three-Live: KI-geschriebenes 3D für Web und Mobilgeräte

Höhepunkte und aktuelle Belege

Three-Live hilft Entwicklern dabei, von KI verfassten Three.js-Szenencode in 3D-Inhalte umzuwandeln, die im Web und in nativen mobilen Anwendungen angezeigt werden können. Die zentrale Idee besteht darin, eine unterstützte Teilmenge von Three.js als portable Szenenbeschreibung zu verwenden und die daraus resultierende Szene anschließend in GLB oder USDZ zu kompilieren. Das Projekt stellt einen Compiler, Renderer und Integrationen bereit; ein externes Modell kann den Code schreiben.

Bildquelle für die Abbildungen zu Studio, Architektur und XR: Google Open Source Blog.

Das Repository befindet sich unter der Organisation von Google, weist jedoch ausdrücklich darauf hin, dass es sich nicht um ein offiziell unterstütztes Google-Produkt handelt. Die aktuelle README bezeichnet das Projekt als Beta. Offizielle Beispiele zeigen prozedurale Geometrie, PBR-Materialien, Animationen und räumliche Interaktion über WebGL2/WebXR, Android Filament und Jetpack XR sowie Apple RealityKit hinweg. Diese Beispiele veranschaulichen vorgesehene Workflows und stellen keine geräteübergreifende Leistungsgarantie dar.

Der Einführungsartikel berichtet von typischen Kompilierungszeiten von 2–5 Millisekunden, jedoch ohne ein vollständiges Benchmark-Protokoll für Hardware und Szenen. Dieser Wert darf nicht als gesamte Latenz von Bild zu 3D verstanden werden. Das Repository enthält außerdem eine Evaluierungssuite mit 100 Prompts und eine Smoke-Suite mit 10 Skripten, die Kompilierung, Diagnosen zu nicht unterstützten Funktionen, Rendering, Simulation und Reparaturen in einem Durchlauf abdecken. Allein ihre Existenz ist jedoch kein Beleg dafür, dass jedes generierte Skript funktioniert.

Vom Code zur nativen Szene

Ein Autor oder Codierungsmodell erstellt Meshes, Materialien, Transformationen und Gruppen über die unterstützte API. Der Host führt das Skript in einer eingeschränkten Umgebung aus. Auf nativen Plattformen bindet ThreeEngine die JavaScript-Engine Boa in Rust ein, setzt den Szenen- und globalen Zustand zurück, führt das Skript aus und extrahiert aus rohen Puffern einen typisierten SceneGraph. Der GLB-Einstiegspunkt übergibt diesen Graphen an write_glb; separate Pfade erzeugen USDZ. Die Zwischendarstellung ist ein expliziter Szenengraph und kein erlerntes 3D-Latent.

Ausführungsbegrenzungen sind wichtig, da generierter Code Endlosschleifen oder übermäßige Geometrie enthalten kann. Im geprüften Quellcode ist die Ausführung von Produktionsskripten auf 500 Millisekunden begrenzt; die Zeit wird alle 10.000 VM-Op-Codes überprüft. Zu den Obergrenzen für Szenen gehören 100.000 Vertices und 1.000 Meshes. Für die Transkodierung gilt eine separate Frist für die Paketierung. Dies sind durch die Implementierung definierte Schutzbegrenzungen und keine Messungen der Rendergeschwindigkeit oder ein Anspruch auf perfekte Isolation. Der Webpfad verwendet einen Worker mit einem optionalen Iframe aus einer undurchsichtigen Origin; Netzwerk- und Speicherzugriff sind eingeschränkt.

Nach der Kompilierung laden Plattformadapter das Asset in den Zielrenderer. Android verwendet Filament- und XR-Integrationen; Apple-Plattformen verwenden RealityKit; der Browser verfügt über einen eigenen WebGL2-Renderer und WebXR-Unterstützung. Deklarative userData.xr-Eigenschaften beschreiben unterstützte Verhaltensweisen wie Greifen oder räumliche Verankerung. Für das Verhalten zur Laufzeit ist die entsprechende Laufzeitintegration erforderlich: Eine statische Vorschau des Betriebssystemmodells bewahrt keine beliebige JavaScript-Interaktion.

Der Agenten-Workflow ergänzt eine Verifizierungsschleife. Die CLI kann ein Skript validieren, ein Kontaktblatt mit vier Ansichten rendern und Assets konvertieren; ihre MCP-Schnittstelle stellt diese Vorgänge Codierungsagenten zur Verfügung. Das Evaluierungs-Framework kann Compilerdiagnosen und visuelle Kritiken für einen Reparaturdurchlauf zurückgeben. Dadurch wird die Codegenerierung mit beobachtbarer Geometrie und Bildkomposition verbunden, während nicht unterstützte oder beeinträchtigte API-Funktionen weiterhin geprüft werden müssen, statt sie einfach vorauszusetzen.

Anwendungen und Entwicklungsstatus

Three-Live ist für prozedurale Produkt-Viewer, bearbeitbare Bildungsszenen, AR-Prototypen und KI-gestützte 3D-Erstellung innerhalb von Anwendungen relevant. Es kann den plattformspezifischen Aufwand für die Szenenerstellung reduzieren, verspricht jedoch keine vollständige Kompatibilität mit beliebigen Three.js-Anwendungen. Zu den Paket- und Binäroptionen gehören npm, Rust-Tools, Android-Bibliotheken und der Apple Swift Package Manager; das Repository verwendet Apache-2.0.

Das offizielle Unreleased-Changelog bildet die Grundlage für die hier beschriebenen Entwicklungsrichtungen. Es führt die Laufzeitgenerierung von Szene aus Bildern mit räumlichen Qualitätsprüfungen und Reparaturen in einem Durchlauf sowie eine optionale WebGPU-Szene und Gaussian-Splat-Beschleunigung auf. Dabei handelt es sich um Einträge aus dem Entwicklungszweig und nicht um Zusagen, dass jede paketierte Version diese Funktionen enthält. Der Bildpfad prüft die Mindestanzahl an Meshes, endliche Grenzen, die Kameraabdeckung und kritische Überschneidungen; diese Prüfungen belegen keine originalgetreue Rekonstruktion des Eingabebilds.

Für diese Prüfung wurden der Compiler-Einstiegspunkt, Ausführungsbegrenzungen, die Szenendarstellung, die Evaluierungsdokumentation und das Changelog untersucht. Das SDK wurde nicht installiert und die Leistung auf Geräten nicht gemessen.