L’un des développeurs d’Ark a salué la toute dernière version de la technologie d’Epic Games.

Quand Epic Games a lancé Unreal Engine 5.7 (UE 5.7) il y a environ un mois et demi, la mise à jour semblait, au moins sur le papier, apporter des améliorations notables sur plusieurs fronts. La fonction Nanite dédiée au feuillage, encore expérimentale, paraissait particulièrement prometteuse, tandis que MegaLights promettait d’augmenter le nombre de sources lumineuses dynamiques projetant des ombres, que les développeurs pourraient intégrer à leurs jeux sans pénaliser le taux d’images par seconde. Mais ces ajouts et changements se traduiraient-ils par des gains tout aussi concrets dans un jeu réel? WCCFTech a posé la question à Jeremy Stieglitz, cofondateur de Studio Wildcard, co-directeur créatif, lead designer, lead programmeur et directeur du développement.

Interrogé sur l’évolution de l’accueil d’Ark: Survival Ascended depuis sa sortie en accès anticipé il y a deux ans, et sur le fait que les avis les plus récents aient fini par atteindre l’évaluation « plutôt positive » sur Steam, Stieglitz a cité les progrès de performance comme raison principale. Il a ensuite précisé que UE 5.7 est déjà en test interne et qu’une sortie est attendue en mars. Selon lui, l’amélioration de performances n’est pas loin d’être qualifiée de solution miracle.

« Quand le jeu est sorti, il ne tournait pas très bien. Franchement, il ne tourne toujours pas aussi bien qu’il le devrait, mais, en termes de performances, nous avons amélioré les choses d’environ 50% depuis la sortie initiale, sur le même matériel. C’est un gain très important, mais nous ne sommes pas encore là où nous voulons être. D’où viendront les performances supplémentaires? Une grande partie provient en réalité de la toute dernière version d’Unreal Engine d’Epic, la 5.7, qui introduit plusieurs améliorations et systèmes sérieux, orientés performance. La 5.6 en apportait aussi, et nous sommes encore sur la 5.5. Ainsi, les gains de performance de la 5.6, combinés aux nouvelles fonctions de la 5.7, nous apportent encore 30 à 40% supplémentaires, côté GPU comme côté CPU. UE 5.6 a procédé à de nombreuses optimisations du render thread, ce qui permet au render thread et au game thread, ainsi qu’au GPU et au CPU, de fonctionner bien mieux en parallèle. Il y a eu de gros changements d’architecture en 5.6, et UE 5.7 ajoute un tout nouveau système pour afficher de grands volumes de feuillage, comme on l’a montré dans la démo de The Witcher IV. »

« Et nous pouvons en profiter directement. Cela fonctionne déjà en interne. Nous préparons simplement la mise en production. Il nous faudra quelques mois pour corriger tous les problèmes liés aux autres parties du moteur qui ont été mises à jour, mais nous pouvons déjà dire que nous avons gagné environ un tiers de performances sur nos cartes existantes grâce au nouveau système de tessellation et de culling Nanite que Epic a introduit dans UE 5.7 pour la végétation. Nous sommes très enthousiastes. C’est ce qui se rapproche le plus d’une solution miracle à ce stade, et c’est l’un de ces rares cas où la victoire est nette. Il n’y a pas de vraie réserve ni d’astérisque. Cela fonctionne bien mieux que la version précédente, et nous n’avons rien à sacrifier pour que cela marche. C’était ce qui se rapprochait le plus d’une solution quasi magique pour certains problèmes de performance. Nous nous attendons à ce que la mise à niveau UE 5.7 d’Ark: Survival Ascended soit disponible d’ici la fin du mois de mars de cette année », a déclaré Stieglitz.

Quand le site lui a demandé si UE 5.7 aiderait à faire disparaître les saccades que les joueurs subissent dans Ark, et plus largement dans de nombreux jeux sous Unreal Engine, Stieglitz a répondu que oui, tout en prévenant qu’il ne faut pas s’attendre à une disparition totale.

« Ce sera mieux, mais je ne sais pas si elles disparaîtront complètement, car deux facteurs entrent en jeu. Le premier, c’est que, dans Ark en particulier, une partie des saccades vient de l’initialisation d’acteurs qui ne se prêtent pas au multithreading. Quand vous jouez en ligne et que vous entrez dans une nouvelle zone où se charge une énorme base construite par quelqu’un d’autre, il faut vraiment le faire instantanément côté client dès que nous recevons les données. Nous pourrions essayer de multithread, mais UE5 est assez faible sur l’instanciation d’acteurs réseau et le multithreading. Je ne sais pas s’ils ont un système intégré pour ça. » Autrement dit, quand le client reçoit un acteur, par exemple un dinosaure ou un bâtiment, via le réseau, il le fait apparaître immédiatement pour commencer à recevoir les données réseau associées. Multipliez cela par 50 000. Si nous devons créer 50 000 structures et que nous les recevons en un gros lot de données en une seule image, cela provoquera un à-coup, comme on peut l’imaginer. Cela n’a rien à voir avec les graphismes ou le chargement de l’arrière-plan du monde. Le problème est simplement que le réseau a transmis 50 000 objets de jeu, et qu’ils doivent être préparés pour être jouables, parce que les données réseau correspondantes vont arriver.

C’est un type de saccades propre à Ark. C’est probablement celui que les joueurs ressentent le plus en ligne, surtout avec de très grandes bases. Il existe aussi un autre type de saccades, davantage lié au chargement en arrière-plan du monde. Une bonne partie a déjà été atténuée et lissée dans les versions plus récentes d’Unreal Engine, mais il y en a une qui, selon lui, est typique des jeux Unreal en général: le shader caching. L’équipe ne fait pas de pré-caching des shaders; il pense donc que le système doit générer du code shader à la volée à partir d’un intermédiaire basé sur HLSL, puis le préparer pour l’upload vers le GPU. Le comportement dépend du matériel GPU et peut provoquer des blocages. Beaucoup de jeux Unreal contournent ce souci en pré-cacheant au lancement tous les shaders possibles pour votre matériel. Stieglitz explique ne pas aimer cette approche sur Ark, car la quantité de contenu rendrait l’opération peu pratique au vu du temps nécessaire. Deuxième raison: le modding, qui rend encore plus imprévisible la liste des matériaux et shaders à compiler.

En pratique, il estime que le modding rendrait de toute façon l’idée inefficace, même si l’on ne l’appliquait qu’au contenu du jeu de base. Il y aurait toujours des à-coups car, par exemple, le jeu permet aux joueurs de créer des cosmétiques personnalisés en ligne. C’est une option désactivable, mais, par défaut, ces cosmétiques se téléchargent dynamiquement pendant la partie. On peut donc croiser des joueurs dont le personnage ou la base affiche des éléments cosmétiques arbitraires. Ceux-ci peuvent avoir des matériaux uniques, donc des shaders uniques. Il n’existe pas de vraie manière de les pré-cacher, puisqu’on ignore à l’avance de quoi il s’agit. Avec le temps, il pense que Epic pourra peut-être optimiser ces aspects encore davantage. Mais, selon lui, dans un jeu qui ne précompile pas tous les shaders, un certain niveau de saccades existera toujours. Il souligne toutefois que la situation s’est nettement améliorée entre les premières versions d’Unreal Engine 5 et UE 5.7, et il ne serait pas surpris de voir Epic poursuivre les améliorations du moteur. De leur côté, ils prévoient au moins une grosse mise à niveau du moteur par an. La mise à jour de 5.2 vers 5.5, effectuée en juin dernier, leur a permis de comprendre comment procéder de manière raisonnablement efficace. Ils le referont avec UE 5.7 en mars, un travail déjà entamé, puis à nouveau début ou mi-2027, quand Epic atteindra cette version,

« » a ajouté Stieglitz.

En somme, Unreal Engine 5.7 apporte beaucoup, mais reste encore loin de la perfection.

Forrás: WCCFTech