Three-Live : la 3D écrite par l’IA sur le Web et mobile

Points clés et éléments actuels

Three-Live aide les développeurs à transformer du code de scène Three.js écrit par une IA en contenu 3D pouvant être affiché sur le web et dans des applications mobiles natives. Son idée centrale consiste à utiliser un sous-ensemble pris en charge de Three.js comme description de scène portable, puis à compiler la scène obtenue en GLB ou USDZ. Il fournit un compilateur, des moteurs de rendu et des intégrations ; un modèle externe peut écrire le code.

Source des images du Studio, de l’architecture et des figures XR : Google Open Source Blog.

Le dépôt est placé sous l’organisation Google, mais précise explicitement qu’il ne s’agit pas d’un produit Google officiellement pris en charge. Son README actuel qualifie le projet de version bêta. Les exemples officiels illustrent la géométrie procédurale, les matériaux PBR, l’animation et l’interaction spatiale sur WebGL2/WebXR, Android Filament et Jetpack XR, ainsi qu’Apple RealityKit. Ils présentent les workflows prévus plutôt qu’une garantie de performances sur tous les appareils.

L’article de lancement indique des temps de compilation typiques de 2 à 5 millisecondes, sans protocole complet de benchmark matériel et scène. Ce chiffre ne doit pas être interprété comme la latence totale entre l’image et la 3D. Le dépôt comprend également une suite d’évaluation de 100 prompts et une suite smoke de 10 scripts couvrant la compilation, les diagnostics de fonctionnalités non prises en charge, le rendu, la simulation et la réparation en un tour ; leur seule présence ne prouve pas que chaque script généré fonctionne.

Du code à une scène native

Un auteur ou un modèle de programmation construit des maillages, des matériaux, des transformations et des groupes via l’API prise en charge. L’hôte exécute le script dans un environnement contraint. Sur les plateformes natives, ThreeEngine intègre le moteur JavaScript Boa en Rust, réinitialise l’état de la scène et l’état global, exécute le script et extrait un SceneGraph typé à partir de tampons bruts. Le point d’entrée GLB transmet ce graphe à write_glb ; des chemins distincts produisent des fichiers USDZ. La représentation intermédiaire est un graphe de scène explicite, et non un latent 3D appris.

Les limites d’exécution sont importantes, car le code généré peut contenir des boucles sans fin ou une géométrie excessive. Dans le code source examiné, l’exécution des scripts en production est limitée à 500 millisecondes, l’horloge étant vérifiée toutes les 10 000 opcodes de la VM. Les plafonds de scène comprennent 100 000 sommets et 1 000 maillages. Une échéance distincte de création de paquet s’applique au transcodage. Il s’agit de limites de protection définies par l’implémentation, et non de mesures de vitesse de rendu ni d’une garantie d’isolation parfaite. Le chemin web utilise un worker, avec une iframe d’origine opaque facultative ; l’accès au réseau et au stockage est limité.

Après la compilation, les adaptateurs de plateforme chargent l’élément dans le moteur de rendu cible. Android utilise Filament et les intégrations XR ; les plateformes Apple utilisent RealityKit ; le navigateur dispose de son propre moteur de rendu WebGL2 et de la prise en charge de WebXR. Les attributs déclaratifs userData.xr décrivent des comportements pris en charge tels que la préhension ou l’ancrage spatial. Le comportement en temps réel nécessite l’intégration d’exécution correspondante : un aperçu statique du modèle par le système d’exploitation ne conserve pas une interaction JavaScript arbitraire.

Le workflow d’agent ajoute une boucle de vérification. La CLI peut valider un script, générer une planche-contact à quatre vues et convertir des éléments ; son interface MCP expose ces opérations aux agents de programmation. Le banc d’évaluation peut renvoyer les diagnostics du compilateur et des critiques visuelles pour un tour de réparation. Cela relie la génération de code à une géométrie et un cadrage observables, tandis que les fonctionnalités d’API non prises en charge ou dégradées restent des éléments à examiner plutôt qu’à écarter par hypothèse.

Applications et état du développement

Three-Live est pertinent pour les visualiseurs de produits procéduraux, les scènes éducatives modifiables, les prototypes AR et la création 3D assistée par IA au sein des applications. Il peut réduire le travail de création de scènes spécifique aux plateformes, mais ne promet pas une compatibilité complète avec les applications Three.js arbitraires. Les options de paquet et de binaire comprennent npm, les outils Rust, les bibliothèques Android et Apple Swift Package Manager ; le dépôt utilise Apache-2.0.

Le journal des modifications non publié officiel constitue la base des orientations de développement présentées ici. Il répertorie la génération d’image vers scène en temps réel avec des contrôles de qualité spatiale et une réparation en un tour, ainsi qu’une accélération facultative des scènes WebGPU et des splats gaussiens. Il s’agit d’entrées implémentées dans la branche de développement, et non de promesses que chaque version empaquetée les inclura. Le chemin image vérifie le nombre minimal de maillages, les limites finies, la couverture de la caméra et les chevauchements critiques ; ces contrôles ne prouvent pas une reconstruction fidèle de l’image d’entrée.

Cette analyse a examiné le point d’entrée du compilateur, les limites d’exécution, la représentation de la scène, la documentation de l’évaluation et le journal des modifications. Elle n’a pas installé le SDK ni mesuré les performances sur des appareils.