Three-Live: 3D creado por IA en web y móvil

Aspectos destacados y evidencia actual

Three-Live ayuda a los desarrolladores a convertir código de escenas de Three.js escrito por IA en contenido 3D que puede mostrarse en la web y en aplicaciones móviles nativas. Su idea central es utilizar un subconjunto compatible de Three.js como descripción de escena portátil y, después, compilar la escena resultante en GLB o USDZ. Proporciona un compilador, renderizadores e integraciones; un modelo externo puede escribir el código.

Fuente de las imágenes del Studio, la arquitectura y las figuras de XR: Google Open Source Blog.

El repositorio está bajo la organización de Google, pero indica explícitamente que no es un producto de Google con soporte oficial. Su README actual etiqueta el proyecto como Beta. Los ejemplos oficiales muestran geometría procedimental, materiales PBR, animación e interacción espacial en WebGL2/WebXR, Android Filament y Jetpack XR, y Apple RealityKit. Estos ejemplos muestran flujos de trabajo previstos, no una garantía de rendimiento para todos los dispositivos.

El artículo de lanzamiento informa de tiempos de compilación habituales de 2–5 milisegundos, sin un protocolo completo de referencia para hardware y escenas. Esta cifra no debe interpretarse como la latencia total de imagen a 3D. El repositorio también incluye un conjunto de evaluación de 100 indicaciones y un conjunto de pruebas rápidas de 10 scripts que cubren la compilación, los diagnósticos de funciones no compatibles, el renderizado, la simulación y la reparación en un turno; su mera presencia no demuestra que todos los scripts generados funcionen.

Del código a una escena nativa

Un autor o modelo de programación construye mallas, materiales, transformaciones y grupos mediante la API compatible. El host ejecuta el script en un entorno restringido. En plataformas nativas, ThreeEngine integra el motor JavaScript Boa en Rust, restablece el estado de la escena y el estado global, ejecuta el script y extrae un SceneGraph tipado de los búferes sin procesar. El punto de entrada de GLB pasa ese grafo a write_glb; rutas independientes producen USDZ. La representación intermedia es un grafo de escena explícito, no un espacio latente 3D aprendido.

Los límites de ejecución son importantes porque el código generado puede contener bucles descontrolados o una cantidad excesiva de geometría. En el código fuente revisado, la ejecución de scripts en producción está limitada a 500 milisegundos, y el reloj se comprueba cada 10.000 códigos de operación de la VM. Los límites de la escena incluyen 100.000 vértices y 1.000 mallas. Se aplica un plazo independiente de empaquetado a la transcodificación. Estos son límites de protección definidos por la implementación, no mediciones de velocidad de renderizado ni una afirmación de aislamiento perfecto. La ruta web utiliza un worker, con un iframe de origen opaco opcional; el acceso a la red y al almacenamiento está restringido.

Después de la compilación, los adaptadores de plataforma cargan el recurso en el renderizador de destino. Android utiliza Filament e integraciones de XR; las plataformas de Apple utilizan RealityKit; el navegador tiene su propio renderizador WebGL2 y compatibilidad con WebXR. Los rasgos declarativos de userData.xr describen comportamientos compatibles, como agarrar o anclar espacialmente. El comportamiento dinámico en tiempo de ejecución requiere la integración de tiempo de ejecución correspondiente: una vista previa estática del modelo del sistema operativo no conserva una interacción JavaScript arbitraria.

El flujo de trabajo del agente añade un ciclo de verificación. La CLI puede validar un script, renderizar una hoja de contactos de cuatro vistas y convertir recursos; su interfaz MCP expone estas operaciones a los agentes de programación. El sistema de evaluación puede devolver diagnósticos del compilador y críticas visuales para un turno de reparación. Esto conecta la generación de código con una geometría y un encuadre observables, mientras que las funciones de API no compatibles o degradadas siguen siendo aspectos que deben inspeccionarse, no darse por resueltos.

Aplicaciones y estado del desarrollo

Three-Live es relevante para visores de productos procedimentales, escenas educativas editables, prototipos de RA y creación de contenido 3D asistida por IA dentro de aplicaciones. Puede reducir el trabajo de creación de escenas específico de cada plataforma, pero no promete compatibilidad total con aplicaciones Three.js arbitrarias. Las opciones de paquetes y binarios incluyen npm, herramientas de Rust, bibliotecas de Android y Apple Swift Package Manager; el repositorio utiliza Apache-2.0.

El registro de cambios oficial de funciones no publicadas es la base de las direcciones de desarrollo aquí descritas. Enumera la generación de imagen a escena en tiempo de ejecución con comprobaciones de calidad espacial y reparación en un turno, además de la aceleración opcional de escenas WebGPU y Gaussian-splat. Estas son entradas implementadas de la rama de desarrollo, no promesas de que todas las versiones empaquetadas las incluyan. La ruta de imagen comprueba el número mínimo de mallas, los límites finitos, la cobertura de la cámara y las superposiciones críticas; esas comprobaciones no demuestran una reconstrucción fiel de la imagen de entrada.

Esta revisión examinó el punto de entrada del compilador, los límites de ejecución, la representación de la escena, la documentación de evaluación y el registro de cambios. No instaló el SDK ni midió el rendimiento en dispositivos.