Hacia dónde va el 3D en la web

Predecir el futuro del 3D en la web es fácil de hacer mal, porque el campo produce demostraciones espectaculares cada semana y casi ninguna llega a producción. Lo que sí se puede hacer es separar lo que ya está ocurriendo, con implementaciones enviadas y APIs estables, de lo que sigue siendo investigación. Esta lección hace esa separación con los tres movimientos que de verdad están cambiando cómo se construye una experiencia 3D, y con una lista honesta de lo que todavía no.

WebGPU: de novedad a base

WebGPU está en los tres motores por defecto desde que Safari 26 lo implementó en septiembre de 2025, en macOS, iPadOS, iOS y visionOS. Eso cierra el círculo que Chrome abrió y que Firefox completó: ya no es una API experimental sino una API disponible.

Lo que eso significa en la práctica es más matizado que “usa WebGPU”. WebGL 2 sigue siendo la base más segura por cobertura de dispositivos antiguos, y lo seguirá siendo unos años más, porque la disponibilidad de una API en la última versión de un navegador no es lo mismo que su disponibilidad en el parque de dispositivos reales. El enfoque correcto no es sustitución sino mejora progresiva, y Three.js lo hace por ti: WebGPURenderer cae automáticamente a WebGL cuando no hay WebGPU.

import * as THREE from 'three/webgpu';

const renderer = new THREE.WebGPURenderer({ antialias: true });
await renderer.init();          // asincrono: hay que esperarlo

// Saber por que camino has entrado, para adaptar lo que no es portable
const usandoWebGPU = renderer.backend.isWebGPUBackend === true;

init() es la diferencia estructural más visible al migrar: obtener un dispositivo de WebGPU es asíncrono, así que la construcción del renderer también lo es. Todo el arranque de la aplicación pasa a ser una función asíncrona, y eso obliga a repensar el orden del montaje si tu código asumía construcción síncrona.

Las tres cosas que WebGPU aporta de verdad, por orden de impacto real:

Compute shaders. Es la ganancia grande y la única que no tiene equivalente en WebGL. Simulaciones de partículas, física, ordenación, generación procedural y postprocesado avanzado se ejecutan en la GPU sin los trucos de escribir a texturas. Un sistema de un millón de partículas con física deja de ser una proeza y pasa a ser un ejercicio.

Menos coste de CPU por llamada. El modelo de WebGPU valida los pipelines por adelantado y graba comandos en lotes, en lugar de validar cada llamada como hace WebGL. En escenas limitadas por CPU la diferencia es sustancial.

Funcionalidades que WebGL no tiene. Render bundles, dibujo indirecto, storage textures, multiview en XR. Cada una habilita técnicas que en WebGL exigían rodeos o eran imposibles.

Y la parte incómoda: si tu escena está limitada por relleno, migrar a WebGPU no la va a acelerar. Los fragment shaders hacen el mismo trabajo. La migración vale la pena por compute y por CPU, no como acelerador general.

TSL: la abstracción que sí hacía falta

TSL, el lenguaje de shading de Three.js, se presenta habitualmente como “escribe una vez, compila a GLSL y a WGSL”. Es cierto y es lo de menos. Lo que TSL cambia de verdad es que el shader deja de ser una cadena de texto y pasa a ser un grafo de objetos.

Un shader como cadena no se puede componer. Extender un MeshStandardMaterial en WebGL exige interceptar la compilación y hacer sustituciones de texto sobre el código generado, lo que se rompe cada vez que Three cambia una línea de sus chunks. Un shader como grafo se compone asignando nodos a puntos de extensión:

import * as THREE from 'three/webgpu';
import { mix, uv, sin, time, vec3, positionLocal, float } from 'three/tsl';

const material = new THREE.MeshStandardNodeMaterial();

// El color sale de un grafo, no de una cadena
material.colorNode = mix(
  vec3(0.1, 0.3, 0.8),
  vec3(0.9, 0.4, 0.2),
  uv().y,
);

// Y el desplazamiento de vertices, de otro
material.positionNode = positionLocal.add(
  vec3(0, sin(positionLocal.x.mul(4).add(time)).mul(0.1), 0),
);

Todo el resto del MeshStandardMaterial sigue funcionando: las luces, las sombras, el entorno, el tone mapping. Solo has reemplazado dos nodos del grafo. En GLSL directo, ese mismo resultado exige reimplementar la iluminación entera o pelearse con sustituciones de texto frágiles.

Las tres consecuencias que se derivan de esto y que se subestiman:

Composición real. Un efecto escrito como función de TSL se reutiliza en cualquier material, se pasa como parámetro y se combina con otros. Es código, no plantillas de texto.

Optimización del grafo. El compilador sabe qué nodos se usan y puede eliminar los que no contribuyen al resultado. Un shader escrito a mano con ramas muertas las paga; un grafo las poda.

Un solo lenguaje. Los mismos nodos sirven para render y para compute. La curva de aprendizaje se paga una vez.

El coste honesto: TSL es una capa más entre tu intención y el código que ejecuta la GPU, y depurar a través de ella es más indirecto. Cuando el resultado no es el esperado, hay que poder mirar el shader generado, y esa capacidad existe pero es menos inmediata que leer tu propio GLSL.

Gaussian splatting: fotorrealismo sin malla

El splatting de gaussianas es el cambio conceptual más profundo de los últimos años, porque no optimiza el pipeline: lo sustituye por otro.

La idea es abandonar el triángulo como primitiva. Una escena se representa como millones de gaussianas tridimensionales, cada una con posición, orientación, escala, opacidad y color dependiente de la dirección de vista. Renderizar consiste en proyectar cada gaussiana a pantalla, ordenarlas por profundidad y mezclarlas. No hay mallas, no hay UV, no hay texturas, no hay iluminación calculada: el color ya incluye la luz con la que se capturó.

Las escenas se obtienen entrenando el conjunto de gaussianas a partir de fotografías o vídeo, con un proceso de optimización que ajusta los parámetros hasta que las vistas renderizadas coinciden con las capturadas. El resultado es fotorrealismo genuino en escenas reales, con reflejos, transparencias y detalle fino que una malla fotogrametrizada no consigue.

Lo que cambia para el desarrollo web:

La captura sustituye al modelado. Un espacio real se convierte en una escena navegable con un móvil y tiempo de cómputo, sin un artista 3D.

El coste de render es de relleno puro. No hay coste de vértices ni de iluminación. Es mezcla alfa ordenada, mucha, sobre muchos píxeles.

La ordenación es el cuello. Millones de primitivas transparentes hay que ordenarlas por profundidad cada vez que la cámara se mueve, y ese es exactamente el problema que los compute shaders resuelven bien. Es una de las razones por las que el splatting y WebGPU avanzan juntos.

Las limitaciones que hoy lo mantienen fuera de la mayoría de los proyectos son igual de concretas. Los ficheros son grandes, del orden de decenas o cientos de megabytes para una escena, aunque los formatos comprimidos están reduciéndolo rápido. La escena es estática: animar gaussianas es investigación activa, no una funcionalidad. No hay iluminación: no puedes cambiar la luz ni proyectar sombras de objetos nuevos sobre la escena capturada. Y la integración con geometría convencional es incómoda, porque mezclar triángulos opacos con una nube de primitivas transparentes exige cuidado con la profundidad.

Three.js en la versión de referencia no incluye un renderizador de gaussianas en su núcleo ni en sus addons: el trabajo vive en librerías de terceros que se integran como un objeto más de la escena. Es la señal habitual de una técnica que funciona pero cuya API todavía no se ha estabilizado.

Lo que está llegando y lo que lleva años a punto de llegar

Cerrar con una separación honesta, porque la diferencia entre ambas listas es donde se pierde el tiempo.

Está llegando de verdad. El uso de compute para todo lo que antes se hacía con trucos: partículas, física, ordenación, generación de terreno. La consolidación de KTX2 y de la cuantización de geometría como el pipeline estándar de assets, no como una optimización avanzada. La mejora sostenida de WebXR en visores autónomos, con multiview y capas de composición. Y el 3D como parte normal de una página, cargado en diferido dentro de una isla, en lugar de como una experiencia aparte a pantalla completa.

Lleva años a punto de llegar. El trazado de rayos acelerado por hardware en la web: existe en las APIs nativas y no hay una propuesta madura para exponerlo. Las mallas de nivel de detalle continuo al estilo de los motores de sobremesa: la técnica existe, la infraestructura de streaming que necesita no. Los avatares interoperables entre plataformas: el problema es de acuerdos, no técnico, y por eso lleva una década. Y la inferencia de modelos generativos en el navegador para producir geometría en tiempo real: las demostraciones son impresionantes y el coste sigue siendo prohibitivo para una web normal.

La regla para juzgar cualquier novedad que aparezca después de esta lección es la misma que ha servido durante todo el track. Pregunta qué recurso consume, si hay una implementación enviada en más de un motor, y qué se rompe cuando no está disponible. Una técnica que no responde a las tres es una demostración, y las demostraciones son valiosas para aprender y peligrosas para planificar.