Renderización a 500 km/h en Gear.Club Unlimited 3

Eden Games lleva 25 años desarrollando videojuegos de carreras, en los que el rendimiento es tan importante como la calidad visual. Su último lanzamiento, Gear.Club Unlimited 3 (GCU 3), lleva ese equilibrio aún más lejos: Se trata de un juego de carreras Arcade a 60 FPS capaz de realizar streaming de entornos de gran tamaño a velocidades que rozan los 500 km/h, y está pensado para un amplio rango de dispositivos, desde consolas hasta ordenadores de gama alta con trazado de rayos.

Lanzado el 19 de febrero de 2026, GCU 3 es también el primer título que incorpora el proceso de renderizado personalizado y ya consolidado de Eden Games, que se estrena en la Nintendo Switchᵀᴹ 2 antes de llegar a otras plataformas a lo largo de este año.

Hablamos con Nasim Bouguerra, programador gráfico jefe, y con Florian Falavel, programador sénior de renderizado, sobre el desarrollo de una arquitectura basada en la GPU, la adaptación del trazado de rayos a diferentes plataformas y el mantenimiento de un rendimiento estable bajo condiciones extremas de streaming.

¿Cuáles fueron los mayores retos de renderizado a los que se enfrentó el equipo durante el desarrollo de GCU 3?

Nasim Bouguerra (NB): Uno de nuestros principales retos fue mantener una velocidad constante de 60 FPS mientras streamábamos datos del mundo a velocidades de hasta 500 km/h. A esa velocidad, incluso los pequeños atascos —como la carga de recursos, los puntos de sincronización y la recolección de basura— rompen de inmediato la inmersión en el juego. La eliminación de esos picos se convirtió en uno de los principales objetivos de ingeniería.

GCU 3 fue también nuestro primer juego para la Nintendo Switch 2, por lo que tuvimos que optimizarlo para el nuevo hardware con plazos muy ajustados. Al mismo tiempo, esta fue la primera versión de producción de nuestro completo proceso de renderizado interno. Esto implicaba estabilizar la arquitectura, validar la escalabilidad en todas las plataformas y ajustar las rutas específicas de cada plataforma al mismo tiempo.

¿Por qué decidiste crear un canal de renderizado programable personalizado?

NB: En 2019, desarrollamos nuestro propio canal de renderizado programable para adaptarnos a equipos de hardware muy diversos. Nos proporcionó un control total sobre el rendimiento y las funciones, permitió crear un sistema totalmente basado en la GPU y fue compatible con tecnologías modernas como DLSS 4.5, FSR 4, XeSS 2 y el trazado de rutas. Since then, we have launched four games with this development process, and GCU 3 represents its most significant advancement to date.

¿Cómo ha influido Unity 6 en tu proceso de renderizado y en tu pila gráfica de bajo nivel?

Florian Falavel (FF): Unity 6 nos ofrece un mayor acceso y flexibilidad en el motor de renderizado, lo que nos permite aprovechar las funciones gráficas de bajo nivel y crear soluciones optimizadas y personalizadas. También utilizamos complementos de renderizado nativo para integrar funciones que aún no están disponibles en Unity, como NVIDIA DLSS en PC y Nintendo Switch 2, el denoiser NRD para el trazado de rayos y otras herramientas avanzadas. Este nivel de control es esencial para garantizar un streaming de alto rendimiento y mantener una calidad visual estable en todas nuestras plataformas de destino.

¿Cómo cambia el renderizado basado en GPU tu forma de abordar la creación de entornos y circuitos de carreras?

FF: El renderizado basado en la GPU elimina los cuellos de botella en el procesamiento de la CPU, lo que permite crear entornos mucho más densos y circuitos de carreras más complejos. Lo combinamos con un sistema personalizado de texturizado virtual para terrenos y elementos del decorado, de modo que los artistas puedan utilizar recursos de alta resolución sin que ello afecte al rendimiento ni al consumo de memoria. El resultado es una mayor complejidad de la escena sin comprometer la velocidad de fotogramas de 60 FPS.

A velocidades que rozan los 500 km/h, el streaming se vuelve fundamental. ¿Cómo gestionas el renderizado, el streaming de recursos y la gestión de la memoria para evitar los tirones?

NB: El streaming fue uno de nuestros mayores retos. Hemos creado un sistema de streaming totalmente multithreading, capaz de saturar las dos interfaces de E/S de la Nintendo Switch sin problemas. También dedicamos tiempo a eliminar en la medida de lo posible las asignaciones de GC durante el juego, y activamos la recolección de GC incremental para garantizar que las caídas de fotogramas relacionadas con este proceso sean poco frecuentes en las carreras.

Nuestros sistemas de texturas virtuales y de terreno también utilizan bucles de retroalimentación para cargar únicamente los datos necesarios, justo cuando se necesitan. Este método garantiza un streaming fluido incluso a velocidades extremas.

¿Qué técnicas de renderizado y optimizaciones de la GPU fueron fundamentales para alcanzar los 60 FPS en la Nintendo Switch 2?

FF: En la Nintendo Switch 2, cada fase del proceso de desarrollo tenía que justificar su coste. Hemos integrado estrechamente DLSS con nuestro sistema de resolución dinámica para no sobrepasar los límites de la GPU, y hemos recurrido en gran medida al Compute asíncrono para solapar las cargas de trabajo y maximizar la ocupación.

Nuestra arquitectura basada en la GPU también redujo la carga de la CPU, lo que contribuyó a mantener la fluidez en situaciones de juego intensas. Un análisis exhaustivo de la plataforma nos permitió tomar decisiones a nivel de función, donde redujimos las etapas que consumían mucho ancho de banda, reorganizamos las transiciones de recursos y eliminamos los bloqueos de sincronización.

La frecuencia de actualización variable proporcionó un margen de seguridad adicional, suavizando casos extremos poco frecuentes sin ocultar problemas sistémicos.

¿En qué se diferencia tu enfoque de renderizado en las distintas plataformas, aparte de la Nintendo Switch 2?

NB: Empezamos con una configuración con todas las funciones activadas y, a continuación, analizamos el rendimiento de cada sistema en condiciones reales de juego. A partir de ahí, adaptamos o especializamos selectivamente las funciones para cada plataforma, en lugar de mantener rutas de renderizado totalmente independientes, y realizamos iteraciones para descubrir las mejores formas de aprovechar lo que ofrecen las plataformas.

En PC, ofrecemos a los jugadores acceso a todas las funciones de renderizado que admitimos, incluyendo HDR, compatibilidad con pantallas ultrapanorámicas, DLSS y trazado de rutas en tiempo real. También ofrecemos opciones de escalabilidad para que, incluso en dispositivos de baja potencia como la Steam Deck, los jugadores puedan disfrutar del juego con la misma calidad visual básica.

El objetivo no es contar con diferentes pipelines. Se trata de una degradación controlada dentro de un único marco escalable.

¿Qué motivó a vuestro equipo a apostar tan decididamente por el trazado de rayos, y cómo influyó esa decisión tanto en vuestros objetivos visuales como en vuestras limitaciones técnicas durante el desarrollo?

NB: El trazado de rayos es esencial tanto para lograr imágenes físicamente realistas como para agilizar el proceso de iteración de nuestros artistas de iluminación. Lo integramos desde la fase inicial de desarrollo hasta la producción y el runtime, y nos aseguramos de que todos los sistemas, desde el terreno y los elementos de decorado hasta la iluminación y los materiales, funcionaran según lo previsto. Además, los artistas necesitan GPU con gran capacidad de memoria durante la producción, ya que la memoria de la estructura de aceleración del trazado de rayos (RTAS) constituye un cuello de botella fundamental en el trazado de rayos.

¿Podrías explicarnos cómo implementaste la iluminación global (GI) utilizando un trazador de trayectorias de referencia, y en qué medida ese trabajo influyó o contrastó con la solución de trazado de trayectorias en tiempo real utilizada en la versión para PC?

FF: El trazado de rayos es la columna vertebral de nuestro flujo de trabajo de iluminación global. Hemos creado un trazador de trayectorias de referencia para garantizar la precisión, que valida nuestro sistema de iluminación global precalculada y ofrece a los artistas resultados predecibles. Esto agiliza el proceso de iteración, ya que les permite obtener una vista previa de la iluminación casi definitiva antes de iniciar el proceso de renderizado completo.

En PC, hemos incorporado un trazador de trayectorias en tiempo real basado en ReSTIR para hardware de gama alta, que se ajusta fielmente a la realidad. El trazado de rayos es una inversión a largo plazo, y hemos colaborado estrechamente con Unity para perfeccionar y estabilizar las API de renderizado.

¿Cómo influyó la colaboración con el equipo de trazado de rayos de Unity en el proceso de renderizado final?

FF: Nuestro proceso de trabajo basado en la GPU requería una función de trazado de rayos que las primeras versiones de Unity no ofrecían. Hemos añadido la posibilidad de incorporar datos generados por la GPU en la estructura de aceleración, introduciendo API como `RayTracingAccelerationStructure.AddInstancesIndirect`, y hemos integrado la reordenación de ejecución de shaders de NVIDIA VIA un complemento de renderizado nativo para mejorar el rendimiento del trazado de trayectorias. Esta colaboración dio forma a nuestra arquitectura final, lo que nos permitió ampliar el trazado de rayos sin apartarnos de nuestro enfoque basado en la GPU.

¿Cómo encajan las tecnologías modernas de aumento de resolución en tu estrategia general de renderizado?

NB: El escalado moderno es esencial para lograr un equilibrio entre la nitidez visual y el rendimiento. Las soluciones basadas en el Machine Learning pueden incluso ofrecer un mejor suavizado que los métodos tradicionales, como el suavizado temporal (TAA). En PC, somos compatibles con nuestro propio upscaler temporal, NVIDIA DLSS 4.5, AMD FSR 4 e Intel XeSS 2, lo que ofrece la máxima flexibilidad.

Dicho esto, el upscaling no es una solución mágica. Funciona mejor cuando el proceso subyacente ya es eficiente, lo que nos permite equilibrar la nitidez, el rendimiento y la calidad de la imagen, especialmente en consolas con limitaciones más estrictas.

¿Qué consejo darías a los desarrolladores a la hora de diseñar una estrategia de renderizado?

NB: Empieza por comprender qué es lo que realmente necesitan tus artistas y jugadores, y diseña tus sistemas de renderizado para satisfacer esas necesidades de manera eficiente. Evita la complejidad innecesaria, céntrate en obtener el máximo partido de los sistemas existentes y mantén un enfoque simple y escalable. Genera siempre el perfil en el hardware de destino. Las optimizaciones pueden reducir el rendimiento si no se prueban en los aspectos que realmente importan.

FF: Yo estoy de acuerdo. Identifica los elementos visuales que realmente importan y basa tu estrategia en ellos. No te sientas obligado a implementar todas las funciones. Da prioridad a lo que es importante para mantener tanto el rendimiento como la calidad visual.

Para obtener más información sobre los proyectos creados con Unity, visita la página de Recursos.

*Nintendo Switch es una marca comercial de Nintendo.