Rendu à 500 km/h dans Gear.Club Unlimited 3

Eden Games a consacré 25 ans à la création de jeux de course, où les performances sont aussi cruciales que la fidélité visuelle. Leur dernière sortie, Gear.Club Unlimited 3 (GCU 3), pousse cet équilibre plus loin : C'est un jeu de course arcade à 60 fps capable de diffuser de grands environnements à des vitesses approchant les 500 km/h tout en ciblant des matériels allant des consoles aux PC haut de gamme avec traçage de rayons.

Sortie le 19 février 2026, GCU 3 est également le premier titre à être livré avec le pipeline de rendu personnalisé entièrement développé par Eden Games, qui fait ses débuts sur la Nintendo SwitchTM 2 avant de se déployer sur d'autres plateformes plus tard cette année.

Nous avons parlé avec Nasim Bouguerra, programmeur graphique principal, et Florian Falavel, programmeur de rendu senior, sur la construction d'une architecture pilotée par GPU, l'adaptation du traçage de rayons sur les différentes plateformes et le maintien de performances stables sous des contraintes de diffusion extrêmes.

Quels ont été les plus grands défis de rendu auxquels l'équipe a été confrontée lors de la construction GCU 3?

Nasim Bouguerra (NB) : L'un de nos principaux défis était de maintenir un taux de 60 images par seconde tout en diffusant des données mondiales à des vitesses allant jusqu'à 500 km/h. À cette vitesse, même les petits ralentissements, tels que le chargement des ressources, les points de synchronisation et la collecte des ordures, brisent immédiatement l'immersion dans le jeu. L'élimination de ces pointes est devenue un objectif d'ingénierie prioritaire.

GCU 3 a également été notre premier jeu sur la Nintendo Switch 2, nous avons donc dû optimiser le nouveau matériel dans des délais serrés. Parallèlement, il s'agissait de la première version de production de notre pipeline de rendu entièrement interne. Cela signifiait stabiliser l'architecture, valider la scalabilité sur toutes les plateformes et régler les chemins spécifiques à chaque plateforme simultanément.

Pourquoi avez-vous décidé de créer un pipeline d' rendu scriptable personnalisé ?

N.B. : En 2019, nous avons créé notre propre pipeline d' rendu scriptable pour évoluer sur des matériels très différents. Cela nous a donné un contrôle total sur les performances et les fonctionnalités, a permis un système entièrement piloté par le GPU et a pris en charge des technologies modernes comme DLSS 4.5, FSR 4, XeSS 2 et le traçage de parcours. Depuis lors, nous avons publié quatre jeux sur cette chaîne de production, et GCU 3 représente son évolution la plus significative à ce jour.

Comment Unity 6 a-t-il influencé votre chaîne de rendu et votre pile graphique de bas niveau ?

Florian Falavel (FF) : Unity 6 nous offre un meilleur accès et une plus grande flexibilité au niveau du backend de rendu, nous permettant de tirer parti des fonctionnalités graphiques de bas niveau et de créer des solutions optimisées et sur mesure. Nous nous appuyons également sur les plugins de rendu natifs pour intégrer des fonctionnalités qui ne sont pas encore exposées dans Unity, telles que NVIDIA DLSS sur PC et Nintendo Switch 2, le denoisseur NRD pour le traçage de rayons et d'autres outils avancés. Ce niveau de contrôle est essentiel pour un streaming haute performance tout en maintenant une qualité visuelle stable sur toutes nos plateformes cibles.

Comment le rendu piloté par GPU change-t-il la manière dont vous concevez les environnements et les circuits de course ?

FF : Le rendu piloté par GPU élimine les goulets d'étranglement liés à la soumission du CPU, permettant des environnements beaucoup plus denses et des circuits de course plus complexes. Nous l'associons à un système de texture virtuelle personnalisé pour le terrain et les accessoires, afin que les artistes puissent utiliser des ressources haute résolution tout en gardant la mémoire et les performances prévisibles. Le résultat est une complexité de scène plus élevée sans compromettre le taux d'images de 60 images par seconde.

À des vitesses approchant les 500 km/h, le streaming devient crucial. Comment gérez-vous le rendu, le streaming des ressources et la gestion de la mémoire pour éviter les saccades ?

N.B. : Le streaming était l'un de nos plus grands défis. Nous avons construit un système de streaming entièrement multithreadé, capable de saturer l'entrée/sortie de la Nintendo Switch 2 sans à-coups. Nous avons également consacré du temps à supprimer autant d'allocation de GC que possible pendant le jeu et activé la collecte de déchets incrémentale pour garantir que les baisses d'images liées à la collecte de déchets soient rares lors des courses.

Nos systèmes de terrain et de texturation virtuelle utilisent également des boucles de rétroaction pour charger uniquement les données nécessaires, exactement quand elles sont nécessaires. Cette approche maintient le streaming fluide même à des vitesses extrêmes.

Quelles techniques de rendu et d'optimisation du GPU ont été essentielles pour atteindre 60 images par seconde sur la Nintendo Switch 2 ?

FF : Sur la Nintendo Switch 2, chaque étape du pipeline devait justifier son coût. Nous avons étroitement intégré DLSS à notre système de résolution dynamique pour rester dans les limites des budgets GPU, et nous nous sommes fortement appuyés sur le calcul asynchrone pour chevaucher les charges de travail et maximiser l'occupation.

Notre architecture pilotée par GPU a également réduit la surcharge du CPU, ce qui a aidé à maintenir la cohérence lors de scénarios de jeu intenses. Un profilage approfondi de la plateforme a guidé les décisions au niveau du passe, où nous avons réduit les étapes gourmandes en bande passante, réorganisé les transitions de ressources et éliminé les blocages de synchronisation.

Le taux de rafraîchissement variable a fourni une marge de sécurité supplémentaire, en lissant les cas limites rares sans masquer les problèmes systémiques.

En quoi votre approche du rendu diffère-t-elle sur les plateformes autres que la Nintendo Switch 2 ?

N.B. : Nous commençons par une configuration complète de fonctionnalités, puis nous profilons chaque système dans des conditions de jeu réelles. À partir de là, nous adaptons ou spécialisons sélectivement les fonctionnalités par plateforme plutôt que de maintenir des chemins de rendu entièrement séparés, et nous itérons pour trouver les meilleures utilisations de ce que les plateformes peuvent offrir.

Sur PC, nous offrons aux joueurs accès à la suite complète de fonctionnalités de rendu que nous prenons en charge, y compris HDR, prise en charge ultra-large, DLSS et traçage de parcours en temps réel. Nous proposons également des options d'évolutivité afin que même sur des appareils à faible puissance comme le Steam Deck, les joueurs puissent profiter du jeu avec les mêmes visuels de base.

L'objectif n'est pas d'avoir des pipelines différents. C'est une dégradation contrôlée au sein d'un cadre unique et évolutif.

Qu'est-ce qui a motivé votre équipe à miser si fortement sur le traçage de rayons, et comment cette décision a-t-elle façonné à la fois vos objectifs visuels et vos contraintes techniques pendant le développement ?

N.B. : Le traçage de rayons est essentiel à la fois pour des visuels physiquement précis et pour une itération plus rapide pour nos artistes de l'éclairage. Nous l'avons intégré du développement initial à la production des niveaux et à l'exécution, et nous avons veillé à ce que tous les systèmes, du terrain et des accessoires à l'éclairage et aux matériaux, fonctionnent comme prévu. Il nécessite également des GPU à haute mémoire pour les artistes pendant la production, car la mémoire de la structure d'accélération de traçage de rayons (RTAS) est un goulot d'étranglement clé avec le traçage de rayons.

Pouvez-vous nous expliquer comment vous avez intégré l'éclairage global (GI) en utilisant un traceur de chemins de référence, et comment ce travail a informé ou contrasté avec la solution de traçage de chemins en temps réel utilisée dans la version PC ?

FF : Le traçage de rayons est l'épine dorsale de notre flux de travail d'éclairage global. Nous avons construit un traceur de chemins de référence pour la précision, qui valide notre système GI intégré et donne aux artistes des résultats prévisibles. Cela accélère l'itération, leur permettant de prévisualiser un éclairage presque final avant de déclencher la cuisson complète.

Sur PC, nous avons ajouté un traceur de parcours basé sur ReSTIR en temps réel pour le matériel haut de gamme, en restant proche de la vérité de base. Le traçage de rayons est un investissement à long terme, et nous avons collaboré étroitement avec Unity pour affiner et stabiliser les API de rendu.

Comment la collaboration avec l'équipe de traçage de rayons d'Unity a-t-elle influencé le pipeline de rendu final ?

FF : Notre pipeline piloté par GPU nécessitait une fonctionnalité de traçage de rayons que les premières versions d'Unity ne fournissaient pas. Nous avons ajouté la possibilité d'injecter des données générées par le GPU dans la structure d'accélération, en introduisant des API telles que RayTracingAccelerationStructure.AddInstancesIndirect, et intégré NVIDIA Shader Execution Reordering via un plugin de rendu natif pour améliorer les performances du traçage de parcours. Cette collaboration a façonné notre architecture finale, nous permettant d'étendre le traçage de rayons tout en restant fidèles à notre approche axée sur le GPU.

Comment les technologies modernes de mise à l'échelle s'intègrent-elles dans votre stratégie de rendu globale ?

N.B. : La mise à l'échelle moderne est essentielle pour équilibrer la netteté visuelle et les performances. Les solutions basées sur l'apprentissage automatique peuvent même offrir un meilleur lissage des contours que les méthodes traditionnelles comme le lissage des contours temporel (TAA). Sur PC, nous prenons en charge notre propre échantillonneur temporel, NVIDIA DLSS 4.5, AMD FSR 4 et Intel XeSS 2, offrant ainsi une flexibilité maximale.

Cela dit, le redimensionnement n'est pas une solution miracle. Il fonctionne mieux lorsque le pipeline sous-jacent est déjà efficace, ce qui nous permet d'équilibrer netteté, performances et qualité d'image, en particulier sur les consoles avec des contraintes plus strictes.

Quel conseil donneriez-vous aux développeurs pour élaborer une stratégie de rendu ?

N.B. : Commencez par comprendre les besoins réels de vos artistes et de vos joueurs, et concevez vos systèmes de rendu pour répondre efficacement à ces besoins. Évitez la complexité inutile, concentrez-vous sur le meilleur parti à tirer des systèmes existants et gardez votre approche simple et évolutive. Toujours profiler sur votre matériel cible. Les optimisations peuvent réduire les performances si elles ne sont pas testées là où cela compte.

FF : Je suis d'accord. Identifiez les fonctionnalités visuelles qui comptent vraiment et construisez votre stratégie autour d'elles. Ne vous sentez pas obligé d'implémenter toutes les fonctionnalités. Donnez la priorité à ce qui est important pour maintenir à la fois les performances et la qualité visuelle.

Pour en savoir plus sur les projets réalisés avec Unity, visitez le Page des ressources.

*Nintendo Switch est une marque déposée de Nintendo.