El renderizado en el navegador acaba de vivir su mejor mes
Por Oleg Sidorkin, CTO de Cinevva
Mientras la industria de los videojuegos pasaba marzo discutiendo sobre la IA en la GDC, el ecosistema de renderizado en el navegador avanzó en cuatro semanas lo equivalente a cinco años. Nadie convocó una rueda de prensa. Nadie publicó una opinión provocadora. Ocurrieron cinco cosas distintas que, en conjunto, cambiaron lo que significa «juego de navegador».
Babylon.js lleva años impulsando el renderizado en el navegador. La versión 9.0 dio su mayor salto hasta la fecha.
Lo que llegó en marzo de 2026
Babylon.js 9.0 se lanzó con iluminación por clústeres, una técnica de renderizado que permite manejar cientos de luces dinámicas en una escena sin destrozar el rendimiento. Hasta ahora, esta era una función propia de motores AAA. La versión también incluye iluminación volumétrica con dispersión realista de la luz, luces de área con textura para efectos como vidrieras y pantallas LED, y un editor de partículas basado en nodos. Todo funciona tanto con WebGPU como con WebGL 2.
PlayCanvas v2.17 incorporó la ordenación de splatting gaussiano ejecutada en la GPU mediante WebGPU. El splatting gaussiano, la técnica que convierte capturas fotogramétricas en escenas 3D en tiempo real, era un artículo de investigación hace dos años. Ahora se ejecuta en un motor de navegador con aceleración por GPU para la fase de ordenación.
Three.js r183 cambió el nombre de su módulo PostProcessing a RenderPipeline. Puede parecer un cambio menor de la API, pero el nombre importa. El «posprocesamiento» es algo que se añade a un proyecto personal. Una «canalización de renderizado» es infraestructura de producción. El equipo de Three.js está indicando que la biblioteca está preparada para arquitecturas de renderizado serias y estructuradas.
Chrome 146 añadió el modo de compatibilidad de WebGPU, lo que significa que las GPU más antiguas que no admiten el conjunto completo de funciones de WebGPU ahora pueden utilizarlo mediante una vía con capacidades reducidas. La base instalada compatible con WebGPU acaba de ampliarse drásticamente.
El W3C publicó WebGPU como borrador de recomendación candidata. Este es el paso formal para que se convierta en un estándar web oficial. WebGPU ya no es experimental. Está en proceso de estandarización.
Por qué este mes es diferente
Cualquiera de estos lanzamientos por separado sería digno de mención. Que los cinco hayan ocurrido en el mismo mes genera un efecto acumulativo.
Hace cinco años, «juego de navegador» significaba un juego casual en 2D, quizá con algunos efectos de Canvas si eras ambicioso. Hace tres años, se podía hacer 3D básico con una optimización cuidadosa. Hace un año, WebGPU empezó a llegar a los navegadores de producción y el límite comenzó a elevarse.
Pero marzo de 2026 es el momento en que la diferencia entre el renderizado nativo y el del navegador pasó de ser «considerable» a «reducirse rápidamente». La iluminación por clústeres era algo para lo que se necesitaba Unreal o Unity. El splatting gaussiano requería un laboratorio de investigación. Las canalizaciones de posprocesamiento con calidad de producción exigían un motor personalizado. Ahora, las tres tecnologías están disponibles en motores de navegador de código abierto que cualquiera puede instalar con npm.
Three.js Water Pro ejecutándose en WebGPU. Esto es un navegador.
Lo que creo que ocurrirá a continuación
En Cinevva apostamos desde el principio por distribuir juegos prioritariamente a través del navegador. La tesis siempre fue que la brecha de renderizado se cerraría porque la plataforma web evoluciona más rápido que los motores nativos. WebGPU tardó más de lo que esperaba, pero la convergencia ya está ocurriendo según lo previsto.
El efecto práctico está en la distribución. Un juego que se ejecuta en el navegador no necesita descarga, instalación ni un proceso de aprobación de la plataforma. Se carga desde una URL. Esa siempre ha sido la ventaja del navegador, pero solo importa cuando la calidad del renderizado es lo bastante buena como para que los desarrolladores lo elijan de verdad.
Ya hemos superado ese umbral. No para todos los juegos. No para un AAA de mundo abierto con trazado de rayos. Pero para una categoría cada vez mayor de juegos que incluyen 3D en tiempo real, iluminación dinámica, sistemas de partículas y recursos fotogramétricos, el navegador es una plataforma de destino viable. Y, a diferencia de las plataformas nativas, al otro lado no hay una comisión del 30 % para la plataforma.
La pregunta nunca fue «si los navegadores se pondrían al día», sino «cuándo». Marzo de 2026 nos dio la respuesta.
Relacionado:
- Babylon.js 9.0: iluminación por clústeres y splatting gaussiano — el análisis técnico completo
- Chrome 146 incorpora el modo de compatibilidad de WebGPU — ampliación de la base instalada compatible con WebGPU
- El desarrollo de juegos web entra en la era de WebGPU — cómo hemos llegado hasta aquí
- Comparativa de motores de juegos web — Babylon.js, Three.js, PlayCanvas y el resto
- Primeros pasos con WebGPU para desarrolladores de juegos — práctica con la nueva API
- Tecnología para mundos abiertos 3D en el navegador — la arquitectura de renderizado detrás de los mundos en el navegador