Unity 6.6 saca WebGPU de la fase experimental y lo deja desactivado
Unity lanzó Unity 6.6 el 1 de septiembre. Es una versión con «soporte», lo que significa que recibe el mismo compromiso de estabilidad que una LTS hasta que llegue la 6.7, y es la última parada de la línea Unity 6 antes de esa LTS. El titular para cualquiera que publique en un navegador es una frase de la entrada que el equipo de Web Graphics publicó una semana antes: «a partir de Unity 6000.6, la API gráfica WebGPU deja de ser experimental y pasa a ser una función con soporte completo».
Unity llevaba utilizando WebGPU como backend experimental desde la versión 6.1, a principios de 2025. Ya hablamos de ello en su momento y desde entonces hemos seguido la evolución en los navegadores, desde la incorporación de WebGPU en Safari hasta su llegada a todos los navegadores principales. Ahora el motor se ha puesto al día.
El recorrido de la propia Unity por las novedades de la versión 6.6
Qué permite activar WebGPU
La razón por la que WebGPU es especialmente importante en Unity son los shaders de cómputo. WebGL 2 nunca los tuvo, por lo que todas las funciones de Unity que dependen del cómputo en la GPU simplemente estaban ausentes de las compilaciones web. Con WebGPU seleccionado, las compilaciones web obtienen GPU Resident Drawer y descarte de oclusión por GPU, reescalado mediante Spatial-Temporal Post-Processing, VFX Graph con partículas simuladas por GPU, Adaptive Probe Volumes y skinning mediante cómputo. Las escenas de demostración de Unity para la publicación fueron Fantasy Kingdom, una densa ciudad estilizada, y el interior de una nave espacial repleto de partículas de VFX Graph, ambos ejecutándose en un navegador.
Las partículas de VFX Graph se simulan en la GPU, por eso nunca estuvieron disponibles en WebGL 2. Imagen: Unity.
También hay un modo de compatibilidad más ligero para el hardware que declara compatibilidad con WebGPU, pero no puede manejar el conjunto completo de funciones. Así, la misma compilación llega a más dispositivos sin que el desarrollador tenga que hacer nada.
Lo que Unity decidió no hacer
WebGPU no está activado de forma predeterminada. WebGL 2 sigue siendo la API gráfica predeterminada para las compilaciones web. Para usar WebGPU, hay que abrir los ajustes del reproductor web, desmarcar la selección automática de la API gráfica y añadir WebGPU a la lista. Unity prueba las API por orden de prioridad durante la ejecución y recurre a la siguiente cuando la primera no está disponible.
WebGPU debe añadirse manualmente a la lista de API gráficas. Imagen: Unity.
La publicación incluye dos advertencias de esas que pueden costarte un día entero si no las ves. En primer lugar, los navegadores solo exponen WebGPU en un contexto seguro, por lo que una compilación servida desde un archivo local o un host HTTP normal pasa silenciosamente a WebGL 2 y te dejará preguntándote por qué han desaparecido tus funciones de cómputo. En segundo lugar, según las propias palabras de Unity: «no todos los dispositivos que declaran compatibilidad con WebGPU ofrecen experiencias consistentes». Por eso la versión 6.6 añade Graphics Device Filtering, un conjunto de reglas que fuerza el uso de la alternativa en navegadores, GPU o controladores concretos que hayas identificado como problemáticos.
El resto de las novedades web de la versión 6.6 gira en torno al tamaño y la memoria. WebAssembly64 permite que una compilación para navegador direccione hasta 16 GB de memoria en lugar del anterior límite de 4 GB, en Chrome y Edge 128 o posteriores y Firefox 129 o posterior. Progressive Asset Loading entrega los recursos por escena en lugar de descargarlos todos de antemano, de modo que el jugador puede empezar en la primera escena mientras el resto se carga progresivamente. Ambas funciones abordan los dos motivos por los que históricamente ha sido difícil apostar por los juegos web de Unity: ocupaban demasiado y se quedaban sin memoria.
El resto de la versión
Fuera del navegador, Fast Enter Play Mode es ahora el modo predeterminado para los proyectos nuevos y vuelve a cargar la escena sin recargar el dominio. Unity presenta este cambio como preparación para la transición de Unity 7 a CoreCLR. Por fin, los diccionarios se serializan de forma nativa en el Inspector. Una nueva ventana Build Analysis registra el historial y las métricas de las compilaciones, mientras que Content Directories organiza el contenido local con integración de Addressables y compatibilidad con DirectStorage en Windows y Xbox. El ejemplo de Unity sobre las mejoras en los shaders es una compilación cuyo tiempo bajó de 1 hora y 46 minutos a 32 minutos tras convertir las variantes de palabras clave en ramas dinámicas.
Qué supone esto para los juegos web
Nosotros trabajamos directamente con three.js y WebGPU, así que el hecho de que Unity consolide su backend no es tanto una amenaza competitiva como una confirmación. El cómputo de GPU en el navegador es ahora una vía con soporte en el motor que cuenta con la mayor base instalada, lo que significa que más juegos se publicarán contando con esta tecnología, más jugadores se toparán con casos límite de compatibilidad y los proveedores de navegadores sentirán más presión para resolverlos. Ya explicamos cómo se comparan WebGPU y WebGL para juegos y analizamos las opciones de motores para la web, y el consejo de ambos artículos sigue vigente: publica con WebGPU activado y WebGL 2 como alternativa, prueba en hardware modesto real y considera que «el navegador dice que es compatible» es solo el principio de la cuestión.
Que Unity deje WebGPU desactivado de forma predeterminada es la decisión correcta para una versión con soporte, pero también es una señal. La API está lista. El parque de dispositivos todavía no es uniforme, y el motor que tiene que ejecutarse en todos ellos lo sabe mejor que nadie.