Three.js r184 estrena HTMLTexture: DOM en vivo como superficie 3D
Three.js r184 se publicó esta semana. La novedad principal es una nueva clase HTMLTexture que permite indicar a Three.js cualquier elemento HTML en vivo y usarlo como textura sobre una malla. Los botones siguen siendo interactivos, los campos de entrada conservan el foco, las animaciones CSS continúan ejecutándose y el navegador gestiona la accesibilidad y los métodos de entrada IME como siempre.
Presentación oficial de Chrome sobre la API HTML-in-Canvas en la que se basa HTMLTexture de Three.js
HTMLTexture, en un párrafo
HTMLTexture encapsula la API HTML-in-Canvas de Chrome 146. Le pasas un elemento DOM. Three.js establece layoutsubtree en el lienzo, inserta el elemento en el DOM del renderizador y proyecta su resultado rasterizado en una THREE.Texture que puede muestrearse desde cualquier material en WebGL 2 o WebGPU. Los ejemplos oficiales (webgl_materials_texture_html y webgpu_materials_texture_html) incluyen texto con formato, imágenes, SVG, un campo de entrada funcional y un botón.
En la práctica, esto significa que componentes de React, widgets de sistemas de diseño, reproductores de vídeo, gráficos o páginas completas incrustadas pueden colocarse en una pantalla curva, una valla publicitaria o un panel de interfaz dentro de una escena de Three.js, sin la habitual contrapartida de «rasterizar en un lienzo y renunciar después a la interactividad».
La limitación
La función solo está disponible donde existe la API subyacente. Por ahora, eso significa Chromium 146 o posterior con la opción chrome://flags/#canvas-draw-element activada, así que los sitios en producción todavía necesitan una alternativa. El PR deja la puerta abierta al hacer que HTMLTexture falle de forma controlada cuando la API no está disponible, pero conviene detectar la compatibilidad antes de prometer a los clientes un panel de Three.js totalmente interactivo.
Safari y Firefox no han anunciado plazos. Dado que WebGPU no alcanzó la disponibilidad general en los tres navegadores hasta finales de 2025, es probable que HTML-in-Canvas siga una trayectoria similar de dos años.
Una demostración de la comunidad de HTML-in-Canvas anterior a la llegada del contenedor de Three.js
La otra gran novedad: cero asignaciones por fotograma
El cambio menos llamativo, pero posiblemente más importante, está en la ruta crítica del renderizador. Antes de r184, renderizar 1.000 mallas a 60 FPS podía generar entre 240.000 y 500.000 objetos desechables por segundo. El recolector de basura tenía que encargarse de ellos en cada escena de larga duración. r184 elimina esas asignaciones del bucle principal de renderizado. Las sesiones prolongadas de WebXR, los visores de construcción con escenas densas y cualquier escena que permanezca activa más de los primeros 30 segundos obtienen gratis una mejora real en el tiempo de fotograma.
Otros cambios menores que merece la pena destacar
AnimationAction ahora conserva la configuración de interpolación al crearse, por lo que invertir timeScale ya no provoca saltos. AudioLoader ya no sufre condiciones de carrera con el gestor de carga. BatchedMesh e InstancedMesh dejan de lanzar errores desde getColorAt cuando no se han definido colores. Las rutas obsoletas de renderizado por instanciación de WebGL han desaparecido definitivamente. Los ejemplos incorporaron un conjunto de bolas con SSGI, nubes volumétricas en el cargador de 3D Tiles e inclinación lateral en la cámara de la montaña rusa.
Cómo lo usaríamos
Para Cinevva, el caso de uso más interesante es una interfaz dentro del lienzo para el reproductor de reels y las herramientas de creación. Ahora mismo superponemos HTML sobre Three.js. Con HTMLTexture, la capa de chat, el explorador de recursos y el campo de instrucciones pueden integrarse en geometría dentro de la escena sin perder la navegación con teclado. En cuanto la API llegue sin necesidad de activar opciones experimentales a la versión estable de Chrome, implementaremos una variante controlada mediante una bandera de funcionalidad.