À l’intérieur d’Immortals of Aveum l’interview technique de Digital Foundry’

Inside Immortals of Aveum Digital Foundry's Technical Interview

Sur le plan technologique, Immortals of Aveum d’Ascendant Studios est un jeu très important. À l’exception de Fortnite, créé par Epic Games lui-même, c’est le premier jeu triple-A à être livré avec toutes les fonctionnalités de pointe d’Unreal Engine 5 en place. Cela inclut Nanite basé sur la microgéométrie, capable de niveaux de détail étonnants, ainsi que Lumen – une solution d’illumination globale basée sur le ray tracing et des cartes d’ombre virtuelles. Avant Fortnite, The Matrix Awakens était le seul jeu UE5 basé sur console que nous avons vu avec ces fonctionnalités – il était magnifique mais posait des problèmes de performances évidents.

Non seulement Ascendant utilise toutes les fonctionnalités d’UE5, mais le jeu vise également les 60 images par seconde sur consoles. C’est donc un jeu très ambitieux, mais comme l’a révélé la critique de DF d’hier, le calcul GPU a ses limites, donc la qualité de l’image doit nécessairement en souffrir, avec FSR 2.2.1 utilisé pour l’upscaling depuis une résolution de base de 720p sur Xbox Series X et PlayStation 5.

Lors du processus d’examen, nous étions très motivés pour en savoir plus sur ce qui fait avancer le jeu, donc lorsque EA nous a offert l’opportunité de parler avec l’équipe de développement, nous avons sauté sur l’occasion. Alex Battaglia et Tom Morgan ont discuté avec Mark Maratea, Julia Lichtblau et Joe Hall d’Ascendant Studios – voici cette conversation.

Depuis combien de temps Immortals est-il en développement – et l’idée était-elle toujours de produire quelque chose qui ressemble à un jeu de tir à la première personne magique ou cela a-t-il évolué pendant le projet ?

Mark Maratea : La société a été créée pour faire ce jeu, et cela a pris une partie importante du temps pour s’organiser… puis le Covid est arrivé, donc le recrutement est devenu une période très intéressante. Ce jeu a cinq ans, pour ainsi dire.

• Ben Affleck critique les récents nerfs de Valorant
• Armored Core 6 a été terminé en n’utilisant que des coups de ...
• Zelda Les Larmes du Royaume, un joueur construit un impressionnant...

Julia Lichtblau : Quelques mois après que Brett [Robbins] ait fondé le studio, il nous a remis à Dave Bogan, le directeur artistique principal, et à moi ce document de présentation de 60 pages, qui était apparemment un jeu de tir magique. Il avait la prémisse de base de [l’antagoniste] Jack et de cette grande intrigue. Évidemment, certaines choses ont changé, comme les subtilités du combat, mais il savait que Brett voulait faire ce jeu de tir magique parce que c’était quelque chose qui n’existait pas auparavant, et c’était un jeu auquel il voulait vraiment jouer et qu’il voulait créer.

Étant donné le moment, j’imagine que le jeu n’a pas commencé sur Unreal Engine 5 car il n’existait pas – donc a-t-il commencé sur Unreal Engine 4 et a-t-il migré vers UE5 ? Comment cela s’est-il passé ?

Mark Maratea : Le projet a commencé avec UE 4.20, qui est sorti en juillet, et la société a été fondée en août [2018]. Lorsque la société a commencé, tout a été fait en blueprint sans modifications du code du moteur, comme s’il s’agissait d’un petit projet indépendant pour le prototyper… Cela aurait pu changer ; la réalité des décisions commerciales à ce sujet est que si quelqu’un s’était présenté comme éditeur trois mois après le début et avait dit : “vous venez, mais vous utilisez Frostbite ou autre chose”, cela aurait nécessité un changement de cap. Nous avons la chance d’avoir une source de financement très généreuse… un partenaire incroyable, ce qui nous donne l’autonomie pour prendre ces décisions. Nous avons commencé avec la version vanilla 4.20, vanilla 4.21, moteur personnalisé 4.23, 4.25, 4.26, UE5 preview, UE5 réel, UE5.1, et maintenant nous livrons avec UE 5.1.1.

Donc, vous avez mentionné que vous avez commencé avec des blueprints et un changement minimal de code, mais avec la version 4.23, vous êtes passé à un moteur personnalisé, quels étaient ces changements plus importants qui ont rendu cela différent ?

Mark Maratea : Vous savez, le début de tous ces changements avait tendance à être “…et ensuite un designer ou un artiste a demandé cette chose impossible, et donc nous avons dû apporter un changement au moteur.” Pour le niveau des ruines en particulier, nous avons dû faire de la magie sur la version UE4 en raison de la disposition du niveau ; nous avons dû déplacer le soleil dans le ciel. Cela ne semble pas être un gros problème jusqu’à ce que vous vous souveniez qu’UE4 est basé sur un éclairage précalculé, donc cela est devenu un gros problème et a nécessité beaucoup de travail.

Ce jeu a toujours été un jeu de 10 livres dans un sac de cinq livres. Notre système de combat a évolué et est devenu la genèse de beaucoup de nos changements de moteur, car nous avons construit notre système de combat sur le système de capacité de jeu Unreal, qui était conçu pour un MOBA. C’est un bon cadre pour un système de capacités répliquées en réseau et nous l’utilisons pour chaque arme du jeu – des armes à tir rapide, des armes visées et contrôlées – nous sommes donc vraiment sortis des limites de ce système. Donc la première série importante de changements a consisté à prendre le système de jouabilité du jeu et à le faire fonctionner comme nous le voulons pour le combat.

La prochaine grande chose était la composition du monde – comment le jeu diffuse [des données], où tout est-il situé. Nous avons apporté d’énormes changements à ce système afin de pouvoir accueillir ces mondes extra-larges et de les traverser tout en les maintenant dans notre budget mémoire… et puis la magie de l’UE5 se produit et la composition du monde n’existe plus car ils l’ont rendu obsolète. Comme vous pouvez l’imaginer, cela a été une transition pour nous tous – l’ingénierie, toutes nos équipes de contenu, les artistes de niveau et les concepteurs de niveau en particulier. Nous leur avons dit “voici la nouvelle bible pour construire un jeu” et ils ont répondu “d’abord, vous devez apprendre à écrire… et ensuite, c’est fou”. C’était un énorme projet d’innovation au niveau du studio, nous avons dû prototyper quelle était la bonne façon de faire, établir les règles, comprendre ce qu’Epic n’avait pas fait correctement, changer le fonctionnement de notre jeu, réécrire les règles encore une fois, et tout cela a été un processus continu jusqu’aux six derniers mois.

Nous avons passé Noël en 5.1 et j’ai passé mes vacances de Noël à intégrer [cette version]… quand nous sommes passés à 5.1, nous ne pouvions pas charger d’actifs dans le jeu, donc j’ai dû essentiellement réécrire le chargeur d’actifs entier en deux jours pour ne pas perdre tout notre progrès.

C’est le prix à payer pour rester à jour, n’est-ce pas ?

Mark Maratea : Ouais, mais ça en valait absolument la peine.

Avez-vous sélectionné des fonctionnalités de pré-mise en cache des shaders de la version 5.11 ou 5.2 ?

Je suis en train de discuter sur Slack pour savoir si nous devons prendre quelque chose de la version 5.2 pour nous aider avec cela. Donc, la mise en cache PSO en 5.1 fonctionne, mais si vous regardez le code, la première ligne est un commentaire qui dit “ceci ne fonctionne pas, ne l’utilisez pas”, et il y a des sorties anticipées pour aller vers d’autres sections de code. Ils ont essayé de faire une pré-mise en cache adaptative, ce qui a provoqué des fuites de mémoire et finalement des plantages lors de la libération des actifs – ce qui est mauvais – mais tout cela est corrigé en 5.2. Malheureusement, nous sommes juste à la frontière entre la version 5.1.0 et la version 5.2 [qui fonctionnent chacune] d’une certaine manière, et la version 5.1.1 qu’ils ont essayé de faire fonctionner mais qui ne fonctionne pas tout à fait.

Nous avons donc dû changer certaines choses, nous utilisons la pré-mise en cache PSO combinée avec le cache normal DX12. Il y a une ligne jetable dans la documentation [d’Epic] qui dit : “quand vous faites une mise en cache PSO, par défaut, il mettra en cache tous les PSO qu’il peut trouver et ensuite les chargera tous en une fois”. Et cette partie “les charger tous en une fois” [pose problème]. Nous avons beaucoup de shaders dans notre jeu, nous avons fait un système incroyable et différent qui utilise des embranchements dynamiques, et nous avons même réécrit une partie du pipeline de shaders, ce qui nous permet de gagner 3-4 ms sur nos temps de rendu, c’est vraiment sérieux. Le revers de la médaille, c’est que cela augmente les permutations de shaders, donc nous avons 5,7 millions de shaders avec des permutations complètes… cela génère 563 000 objets PSO, donc lorsque vous lancez le jeu, il essaie de charger un demi-million de PSOs.

Est-ce que cela explique ce que j’ai vu lorsque j’ai chargé le jeu sans le fichier .ini ? [note : le code de la version de test PC a été livré sans un fichier .ini crucial, causant des problèmes initiaux rapidement résolus] J’ai l’habitude de voir le processeur fonctionner à plein régime [lors de la précompilation des shaders], mais ici c’était comme si le processeur avait du mal à atteindre une utilisation maximale.

Mark Maratea : Ouais, c’est tout lié à l’I/O. C’est en quelque sorte la pire version de l’I/O car vous chargez les PSOs du cache dans la mémoire, vous les traitez, puis vous les sauvegardez sur votre disque C :. Ainsi, vous contournez toutes les optimisations car il doit accéder à un autre disque – la plupart des gens n’ont plus leur bibliothèque Steam sur leur disque C : – et vous contournez les choses DMA et DirectStorage ne fonctionne pas, donc vous subissez une certaine pénalité.

Tu as mentionné DirectStorage – l’utilises-tu sur les consoles Xbox Series ou sur PC ?

Mark Maratea : Oui, si [DirectStorage] est disponible, Unreal essaiera automatiquement de l’utiliser. Nous utilisons également l’async compute, ce qui est un excellent boost de vitesse lorsqu’il est associé à DirectStorage, car cela nous permet de charger directement des compute shaders sur le GPU, puis de faire des calculs magiques pour améliorer l’apparence du jeu et le rendre encore plus génial. Cela nous permet d’exécuter des particules GPU avec Niagara sans surcharger le CPU de manière asynchrone et sans affecter le thread du jeu.

J’ai joué les 25 premières minutes du jeu et je n’ai eu aucun problème de compilation des shaders, ce qui est rare pour un jeu utilisant l’Unreal Engine.

Mark Maratea : Vous n’aurez aucun accroc PSO dans tout le jeu. Je le dis à voix haute maintenant, publiquement, c’est enregistré.

Qu’est-ce que cela a été d’implémenter Nanite dans le jeu, et comment cela se compare-t-il à la méthode habituelle d’auteur de LOD ? Était-ce facile à utiliser ?

Julia Lichtblau : Du côté artistique, nous avons en fait commencé à construire ce jeu sur Unreal 4, donc beaucoup de nos premiers kits ont été développés selon ce pipeline traditionnel. Lorsque nous sommes passés à Nanite et UE5, il y avait beaucoup d’excitation car nous pouvions intégrer beaucoup plus de détails dans les assets eux-mêmes… [À l’origine], il y avait un modèle haute résolution réalisé dans ZBrush, qui était ensuite réduit pour obtenir la texture et le matériau classiques tout en maintenant un nombre de polygones bas. Mais lorsque nous sommes passés à Nanite, nous avons tout simplement pu revenir à l’utilisation des assets haute résolution. Trouver comment déplier quelque chose d’aussi dense a nécessité une réflexion importante sur le flux de travail, car vous devez maintenant gérer beaucoup plus de GameTopics, des millions… Une fois dans le moteur, c’était assez incroyable de pouvoir ajouter des millions et des millions de polygones dans le moteur sans qu’il plante complètement.

Il y a eu quelques moments lors de l’importation où le drapeau Nanite ne s’accrochait pas, et nous devions réimporter une bibliothèque de plusieurs millions de polygones, nous demandant pourquoi le moteur avait des saccades lorsque nous regardions dans cette direction. On pouvait voir qu’Unreal ne savait pas comment gérer cela, mais dès que vous cochez cette case, il gère tout. Il gère les LOD dynamiques et les clusters de manière à accélérer considérablement notre flux de travail, et c’était assez incroyable de passer à la vue Nanite et de voir les clusters s’ajuster en temps réel et voir comment tout est optimisé. Cela nous a permis de construire ce jeu beaucoup plus rapidement avec une équipe aussi réduite.

Comment avez-vous décidé de ce qui était fait avec Nanite ?

Julia Lichtblau : Lorsque nous sommes passés à Unreal [5], nous avons activé Nanite sur tout ce que nous pouvions. Je pense que la version 5.0 n’était pas compatible avec la végétation, cela est venu un peu plus tard, mais dès que nous avons pu avoir de la végétation Nanite, nous l’avons activé. Ensuite, nous avons commencé à nous demander “est-ce que cela a vraiment besoin d’être Nanite ?” Nous avons rencontré certains assets qui posaient problème en raison de leur construction et de la façon dont les UV étaient configurés, nous avons donc dû retravailler certains de ces assets pour les rendre compatibles avec Nanite ou les modifier complètement et revenir à la méthode traditionnelle. Nous ne pouvions pas utiliser [Nanite] pour les objets en mouvement, comme les drapeaux. Nous avons vraiment tout mis dans le panier Nanite, pour en apprendre davantage. Maintenant, nous avons pu créer une énorme page Confluence [wiki d’entreprise] sur la manière de gérer Nanite à l’avenir.

Comment Nanite et les virtual shadow maps se traduisent-ils sur des consoles comme la PS5 et la Series X/S ?

Julia Lichtblau : Du côté artistique, nous n’avons pas vraiment eu à ajuster quoi que ce soit, mais peut-être que Mark a fait des choses en coulisse pour que cela fonctionne, afin que nous, les artistes, n’ayons pas à nous en préoccuper autant !

Mark Maratea : Je dirais que d’une certaine manière, cela fonctionne mieux sur les consoles, étrangement. La géométrie virtualisée de Nanite est très orientée vers le streaming, elle dépend beaucoup de l’entrée/sortie disque. Donc UE5 réécrit le pipeline d’entrée/sortie et les optimisations qu’ils ont faites pour les SSD NVMe. C’est conçu pour fonctionner sur les consoles. Sur PC, je n’ai aucune idée de la bande passante d’entrée/sortie de qui que ce soit… Le seul inconvénient sur console, c’est que lorsque vous utilisez Nanite, vous avez vraiment besoin d’utiliser des textures virtuelles en streaming, vous avez vraiment besoin d’un pool de textures virtuelles très volumineux. Les consoles ont une mémoire fixe, mais [une seule carte graphique] peut avoir plus de mémoire que la PS5. Donc optimiser pour les deux est vraiment difficile.

Nanite fait un bon travail en utilisant la mémoire disponible, mais l’exception à cela est que les pools de textures virtuelles dans UE ne peuvent pas être redimensionnés – ils doivent être initialisés au démarrage du moteur et ne peuvent plus être modifiés, [ce qui fournit] une mémoire contiguë entièrement allouée, ce qui est merveilleux du point de vue des performances mais [vous pouvez rencontrer des problèmes où, par exemple] il y a un calice très loin, deux pixels, et il a besoin d’une partie d’une texture [d’une allocation de pool de 500 Mo], et vous n’en avez plus tant que la texture n’a pas disparu. Le PC s’en moque [si vous manquez de mémoire]; dans le pire des cas, il utilise la mémoire virtuelle. La console dit “Je n’ai pas de mémoire virtuelle, je suis bloquée.” Et elle ne plantera pas, mais cela causera d’importants problèmes. Cela a provoqué ce qui était connu en interne sous le nom de bug de paysage infâme, où vous vous promeniez simplement dans certaines parties du jeu et c’était comme si quelqu’un avait peint un paysage d’anime sur le sol, car il ne pouvait pas allouer pour le pool de textures virtuelles.

Nanite semble avoir facilité la vie du côté artistique ; y a-t-il un moment dans le jeu dont vous êtes particulièrement fier, un moment de démonstration de ce que vous pouvez faire avec Nanite et que vous n’auriez pas pu faire sans UE 5.1 ?

Julia Lichtblau : Nous devons vraiment pousser cela à chaque niveau. Il y a un niveau avec un colosse géant, un énorme mécha, et il a une géométrie courbée très complexe avec beaucoup de détails ; à l’intérieur, chaque petite rivet est présent et les fentes dans le sol sont modélisées pour que vous puissiez voir tous ces actifs cylindriques et hautement détaillés qui bougent de manière étrange et que nous avons pu ajouter de plus en plus de détails… Nanite a vraiment ouvert le monde à la création de niveaux encore plus beaux, car nous ne sommes plus obligés de nous fier aux cartes normales et à ce genre de truc qui se dégrade [à un certain angle de vue]. Ce problème n’existe plus, car la géométrie est réellement présente… vous pouvez vous en approcher de très près et elle aura toujours cette courbure et ces détails. C’était vraiment cool d’expérimenter avec différentes textures, surfaces, formes et styles architecturaux. Du côté artistique, c’était vraiment amusant de pousser cela à travers le jeu.

Joe Hall : Avec les effets visuels dans UE 5.1, ils ont introduit la transparence avec Nanite, ce dont nous avions vraiment besoin. Il y a un niveau dans une bibliothèque où ce métal doit se corroder en fonction de la progression du joueur, ce sont donc des actifs Nanite qui se corrodent réellement avec des effets d’émission et de particules et en utilisant le maillage de secours à l’intérieur. C’est vraiment impressionnant.

Nous allons devoir capturer ces moments pour notre couverture…

Mark Maratea : Pour être honnête, les 10 premières minutes du jeu après la cinématique du théâtre, nous faisons le panoramique du Seren Underbridge – tout cela est en temps réel, dans le jeu, avec une géométrie Nanite entièrement éclairée, dans une zone partitionnée du monde. C’est énorme – je pense que beaucoup d’entre nous oublient à quel point c’est époustouflant ; tous les autres jeux l’auraient [prérendu]. Éclairage en temps réel, éoliennes sur ces bâtiments qui tournent en temps réel, maillages animés… à chaque fois que je regarde ça, je remarque un nouveau détail. Notre équipe artistique est tout simplement phénoménale, avec ce qu’elle a fait avec UE5. Cela évite la vallée dérangeante, ça va directement vers “oui, c’est une ville normale”.

Avec Nanite, vous pouvez utiliser la réplication, la rotation et la mise à l’échelle du même objet pour construire des zones – comment introduisez-vous de la variation dans les environnements ? Y a-t-il un système d’usure ? Y a-t-il des détails mélangés pour ajouter de la variation à certains actifs ?

Julia Lichtblau : Nous n’avons pas de système d’usure ; nous avons utilisé différentes instances de matériaux pour ajouter, par exemple, différentes couleurs de peinture aux bâtiments, et toute une série de décalcomanies qui permettent d’avoir, par exemple, certaines zones plus effritées, ou des éclaboussures de saleté, ou des graffitis, ce genre de choses. Une grande partie consistait simplement à ajouter de la géométrie [faite à la main] – prendre un bâtiment et ajouter un tas d’accessoires autour. Nous avons construit ces planifications de bidonvilles qui avaient beaucoup d’accessoires interchangeables, donc ils n’étaient pas placés à la main au départ – mais nous avons pu y ajouter ce détail artistique, cette sensation de lieu habité pour raconter une histoire environnementale, donc je pense que cela nous a permis d’ajouter de la variété à la plupart de ces actifs.

Avec 60fps sur les consoles, utilisez-vous le logiciel Lumen ? Et avec PC, obtenez-vous automatiquement le logiciel Lumen, ou choisissez-vous entre le Lumen matériel et logiciel en fonction de votre configuration ?

Mark Maratea : Oui [pour le Lumen logiciel sur les consoles]. [Sur PC], c’est actuellement du logiciel, nous avons des options pour les deux. Cela revient aux problèmes de mise en cache de PSO – il s’avère qu’à partir du moment où vous activez le Lumen matériel, cela double vos permutations de shaders car il construit les versions matérielles et logicielles, et j’ai décidé que nous ne devrions pas faire cela aux gens tout de suite.

Une des choses que vous pouvez faire avec la mise en cache de PSO pour éviter certains de ces problèmes est d’utiliser un système de masquage. Je dois donc revenir en arrière et recapturer tous les [10 millions] de PSO dans le jeu. Et je dois instrumenter le jeu avec un bitflag uint64 qui indique, c’est la première étape, c’est la deuxième étape, c’est la troisième étape, tout au long du jeu, puis faire la pré-mise en cache, dans l’ordre, à différents moments, à différents niveaux. Je dois donc construire ce petit système et l’insérer, puis nous pourrons mettre le Lumen matériel sans qu’il provoque une reconstruction du shader de cinq minutes au début du jeu.

Avec le Lumen matériel, avec tous ses détails éloignés, allez-vous rencontrer des problèmes de CPU ?

Oui. Le thread de dessin est très sollicité. Le plus grand changement du logiciel au Lumen matériel est qu’il passe de 200m à 1000m. Il y a un problème secondaire surprenant lorsque vous commencez à ajouter des sources de lumière cinq fois plus éloignées, c’est que vous obtenez maintenant des réflexions de lumières cinq fois plus éloignées. Lumen aime vraiment gérer les réflexions sur tout, et nous avons beaucoup de lumières, donc maintenant vous commencez à jouer avec d’autres paramètres pour éviter d’avoir trop de réflexions sur tous vos matériaux brillants. L’équipe de Julia aime les matériaux brillants, nous en avons beaucoup, donc c’est un équilibre constant entre avoir trop peu et trop de réflexions. Si vous optimisez dans la mauvaise direction, cela devient soit confus, soit cela devient comme une fête de paillettes, aucun des deux n’est génial. Nous sommes donc en train de faire un équilibre très serré pour [équilibrer le taux de rafraîchissement et la fidélité visuelle]. Cela nécessite beaucoup de tests, et vous ne pouvez pas casser d’autres choses en le faisant.

Notre spécification minimale actuelle est un RX 5700 XT et un RTX 2080. Je suppose que les spécifications mises à jour sont entre les mains des gens ; nous avons en fait réussi à baisser un peu les spécifications minimales. Nous avons beaucoup travaillé pour les faire descendre bien en dehors de tout ce qui prend en charge le RTX. L’effet secondaire de cela, évidemment, est que nous devons nous assurer que le logiciel [Lumen] sur PC ne se détériore pas lorsque nous commençons à optimiser pour le matériel [Lumen].

En revenant à Lumen, il atteint le réglage ultra pour l’illumination globale et les réflexions. Où se situent les consoles dans ces réglages ?

Mark Maratea : Elles sont essentiellement en mode moyen, visant du 1080p à 60fps avec mise à l’échelle.

Il est incroyable de voir le jeu supporter Nanite et Lumen dès le départ sur les consoles à 60fps. Est-ce que cela faisait partie du plan depuis le début ? Y a-t-il eu un moment où vous avez envisagé d’opter pour du 30fps ?

Mark Maratea : Nous avons passé les deux premières années à poursuivre notre cible visuelle [plutôt qu’une cible de fps], avec l’équipe artistique en tête de cette charge. En parallèle, nous avions l’équipe de combat et [le directeur du jeu] Brett qui travaillaient, et l’équipe de Joe qui s’assurait que les visuels du combat répondaient aux objectifs de conception. Une fois que ces deux choses se sont solidifiées, nous avions une machine qui tournait régulièrement à 45-50fps en mode développement – et Brett jouait à ça et a dit : “OK, non, je n’aime plus le 30. Ce jeu doit être à 60, le combat ne donne pas la bonne sensation à 30.” Et donc en tant qu’équipe, nous avons pivoté.

Nous avons depuis éliminé beaucoup de ces accrocs, ce qui nous a permis de faire baisser un peu nos spécifications minimales. Je ne recommande à personne de le faire, mais si quelqu’un devait lancer [une GTX] 1060 sur ce jeu, il fonctionnerait en fait. Ce n’est pas optimisé pour cela ; ce n’est pas non plus une carte de 8 Go, donc vous devriez être vraiment prudent. Unreal devient très en colère si vous n’avez pas assez de mémoire d’ombre virtuelle pour la résolution à laquelle vous jouez. Si vous jouez en 1080p, ce n’est pas un si gros problème, mais en tant que joueur PC élite exclusif en 4K, je peux vous dire que c’est un très gros problème lorsque je manque de mémoire d’ombre. C’est le côté technique de cela, mais c’est vraiment une question artistique. Une fois que nous avons décidé du 60, les équipes de Julia et de Joe ont emprunté des chemins formidables pour faire fonctionner le RT à ce stade.

Et qu’en est-il des autres paramètres équivalents aux consoles ? La PS5 et la Series X sont-elles en mode moyen pour la plupart des paramètres, ou peuvent-elles passer en ultra pour certains ?

Mark Maratea : Malgré la parité [de performances], la Series X et la PS5 gèrent les choses différemment. Le calcul asynchrone fonctionne très bien sur l’une, mais moins bien sur l’autre, ce qui modifie la charge du GPU. Une partie de l’accordage [des consoles] nous a poussés à développer l’outil de performance que nous avons sur PC. Nous avons répertorié toutes les variables de rendu existantes dans le système d’accordage Unreal, toutes les gammes possibles, et nous avons exécuté le jeu [avec toutes les combinaisons de paramètres], 17 000 fois. Nous avons compris les compromis entre performances et visuels pour toutes ces choses. Ensuite, nous nous sommes réunis avec le département artistique et nous avons trouvé un compromis satisfaisant, ce qui nous a permis de créer l’un des jeux console les plus beaux jamais réalisés, qui fonctionne avec un très bon taux de rafraîchissement.

Le menu graphique du PC calcule une note pour votre CPU et votre GPU. Sur quoi est-elle basée ?

Mark Maratea : Epic a développé un programme de benchmark synthétique [que nous utilisons] et extrait des chiffres réels [visibles par l’utilisateur], c’est donc de là que ça vient. Le CPU correspond essentiellement aux performances d’un seul cœur, le GPU correspond à toutes les performances du GPU. Un CPU de spécifications minimales se situe autour de 180 ou 200, l’ultra est d’environ 300 ; une GPU de spécifications minimales se situe autour de 500, l’ultra commence à partir d’environ 1200, ce qui correspond à une 7900 XT ou à un 4080.

La confession est que cela est sorti de notre accordage pour les consoles, ce qui signifie, si vous lisez entre les lignes, que j’étais sous la douche il y a quelques semaines et j’ai eu cette idée géniale de créer cet outil de performance. Maintenant, toutes ces données arrivent grâce à cela, [ce qui nous permet] de fournir des données [sur les coûts de différents paramètres graphiques] aux utilisateurs… [Si] quelqu’un a un nouveau processeur ou une nouvelle carte graphique, cela nous donne de nouveaux points de données qui peuvent changer les chiffres. Il s’agit essentiellement de regrouper une énorme quantité de données sur une grande variété de matériel, puis de faire de très bonnes suppositions.

Est-ce prêt pour les futurs matériels, ou nécessite-t-il encore beaucoup d’ajustements manuels ?

Mark Maratea : La version actuelle est très manuelle, mais la version que vous allez voir sera nettement meilleure. Si ce jeu se vend comme je l’espère d’ici le jour 60, il prendra en compte différents algorithmes d’upscaling, différentes résolutions, le ray tracing activé ou désactivé, et fera essentiellement des prédictions d’apprentissage automatique sur l’évolution des taux de rafraîchissement.

Cela me rappelle l’indice de performance de Windows [introduit avec Windows Vista]. J’étais toujours triste que les jeux n’aient pas fini par l’utiliser car je trouvais que c’était une très bonne idée. Votre blog mentionne l’utilisation de FSR 2 sur console, qu’est-ce qui vous a poussé à choisir FSR 2 plutôt que TSR ?

Mark Maratea : Les performances. Nous utilisons FSR 2.2.1, nous sommes [sur] la dernière version d’AMD. Il offre des performances nettement meilleures en matière d’upscaling et l’upscaling de TSR présente beaucoup plus de flou que DLSS ou FSR. Nous discutons constamment avec AMD, Intel et Nvidia pour minimiser les problèmes, et chacun de leurs GPU individuels fait tourner tout cela dans leurs laboratoires de compatibilité, et nous avons fait beaucoup d’efforts pour travailler avec eux. Il est un peu plus difficile pour Epic de publier un changement de moteur pour [résoudre les problèmes de TSR].

Qu’en est-il des résolutions spécifiques sur consoles – FSR 2 en mode ultra cible-t-il la 4K, ou est-ce un réglage supérieur ?

Mark Maratea : Sur consoles uniquement, il effectue un upscaling adaptatif – nous examinons ce à quoi vous êtes connecté du point de vue de l’écran… et il y a une partie de la logique qui dit que si une PS5 Pro sort, elle effectuera un upscaling à différents niveaux de qualité – ce sera la qualité FSR 2 plutôt que la performance standard FSR 2.

Donc, si vous jouez au jeu sur un écran 1080p, vous pourriez potentiellement avoir des performances différentes par rapport à un écran 4K ?

Mark Maratea : Exactement.

Pour les shaders à branchement dynamique dont vous avez parlé, pouvez-vous expliquer les différences entre l’UE5 de base et ce que vous faites ?

Mark Maratea : Oui, je tiens à créditer cela à Joe Weyland, c’est son bébé. C’est un peu comme un document technique de niveau Siggraph. Nous travaillons là-dessus depuis environ 3,5 ans. Nous avons un système hiérarchique de complexité croissante lorsque vous construisez vos shaders – vous pouvez imaginer que le paramètre de base est “est-ce brillant”, puis il y a un sous-enfant qui est “est-ce brillant ou rugueux”, ou autre chose. Avec ce genre de système, il y a beaucoup d’instructions dont vous n’avez pas besoin ; elles vont être évaluées comme “ne pas utiliser”… mais la façon dont le pipelining fonctionne, le GPU doit quand même les évaluer, ce qui semble être une perte de ressources GPU.

Nous avons donc mis en place un système intelligent de branches dynamiques qui nous permet de pré-élaguer les chemins de nœuds qui ne seront pas utilisés pour un matériau particulier. C’est une décision en temps réel, ce qui nous permet de faire beaucoup de choses dans l’éditeur où les gens peuvent immédiatement ajuster quelque chose et voir les changements de performances et visuels en temps réel. Mais ces décisions sont finalement exécutées en temps réel. Cela nous permet d’avoir différentes branches avec des extensions spécifiques à chaque IHV, comme des extensions de shaders exclusives à Nvidia où nous ne vérifions même pas sur une carte AMD. Cela nous permet, en fonction de la complexité de la scène, d’obtenir quelque chose autour de 2-5ms. Ce sont un groupe de personnes très intelligentes qui ont passé beaucoup de temps à construire leur travail de toute une vie et franchement, c’est incroyable.

Est-il même possible de considérer une version PS4 ou Xbox One du jeu, compte tenu de l’annonce de Jedi: Survivor pour les consoles de dernière génération?

Absolument pas. Il n’y a pas de version de Lumen qui fonctionne sur les consoles de dernière génération, même en mode logiciel. Si quelqu’un arrivait avec un camion-benne rempli d’argent [et disait] que nous voulons que vous démontiez tous vos niveaux et que vous les rendiez compatibles avec l’éclairage précalculé, et que vous simplifiez toutes vos textures pour qu’elles puissent tenir dans la mémoire de la console de dernière génération. Ce serait un gros camion-benne. Et cela, après que Joe, Julie et moi sommes partis en vacances tropicales pendant six mois, puis nous reviendrions et je ferais votre portage sur console de dernière génération. Je veux dire, vous demandez essentiellement si nous pouvons reconstruire tout le jeu en désactivant un tas de fonctionnalités clés et en réduisant notre budget artistique à un quart?

Absolument. Je dirais chez Digital Foundry… nous n’avons pas encore vu suffisamment de sorties nouvelle génération, surtout après trois ou quatre ans dans cette génération. Nous sommes de grands défenseurs du jeu en 60fps, mais pour les versions console, une mode de 30fps de meilleure qualité ou de résolution plus élevée est-il envisageable ?

Mark Maratea: Nous faisons essentiellement cela pour l’utilisateur ; nous avons des espaces non-combats où nous avons échangé la fréquence d’images contre la fidélité visuelle… vous allez trouver des zones qui baissent un peu, [sans] aucun combat là-bas et elles vont avoir un aspect extraordinaire. Elles sont déjà en mode qualité. Puis, au fur et à mesure que vous entrez dans des zones de combat, nous commençons à faire des compromis – il y a moins de lumières dynamiques, il y a moins de choses uniques, nous commençons à supprimer des personnages accessoires qui pourraient apparaître sur un RTX 4090 afin de maintenir la fréquence d’images.

Joe [Hall], y a-t-il quelque chose que vous voudriez dire à propos des effets visuels dont vous êtes vraiment fier, ou quelque chose que vous avez réussi à intégrer dans le jeu et dont vous ne pensiez pas que ce serait possible ?

Joe Hall: Ramener la couleur. Ramener la couleur dans les combats, de manière réaliste mais aussi magique. C’est certainement quelque chose. Garder [le jeu] à 60fps, viser une qualité et une fidélité élevées d’un moment à l’autre est quelque chose dont nous pouvons être fiers. Je suis fier de l’équipe et de tous les efforts qu’elle a déployés, de la façon dont nous avons repoussé les limites. Je suis vraiment reconnaissant que l’UE 5.1 existe. C’est excitant pour les joueurs de se lancer dedans !