How A Plague Tale: Innocence Frame Renders

Préface

Comme dans mes autres études, commençons par l'introduction. Aujourd'hui, nous regardons le dernier jeu du développeur français Asobo Studio. La première fois que j'ai vu une vidéo de ce jeu l'année dernière, quand un collègue a partagé une bande-annonce de gameplay de 16 minutes avec moi. La mécanique du «rat contre la lumière» a attiré mon attention, mais je ne voulais pas vraiment jouer à ce jeu. Cependant, après sa sortie, beaucoup ont commencé à dire qu'il semblait avoir été fait sur le moteur Unreal, mais ce n'est pas le cas. J'étais curieux de voir comment fonctionne le rendu et à quel point les développeurs ont été inspirés par Unreal en général. J'étais également intéressé par le processus de rendu d'un troupeau de rats, car dans le jeu, il semblait très convaincant et, de plus, c'est l'un des éléments clés du gameplay.

Quand j'ai commencé à essayer de capturer le jeu, j'ai pensé que je devais abandonner, car rien ne fonctionnait. Bien que le jeu utilise DX11, qui est maintenant pris en charge par presque tous les outils d'analyse, je n'ai pu faire fonctionner aucun d'entre eux. Lorsque j'ai essayé d'utiliser RenderDoc, le jeu s'est écrasé au démarrage, et la même chose s'est produite avec PIX. Je ne sais toujours pas pourquoi cela se produit, mais heureusement, j'ai pu effectuer plusieurs captures à l'aide de NSight Graphics. Comme d'habitude, j'ai élevé tous les paramètres au maximum et j'ai commencé à chercher des trames adaptées à l'analyse.

Rupture de trame

Après avoir fait quelques captures, j'ai décidé d'utiliser l'un des tout début du jeu pour l'analyse d'images. Il n'y a pas beaucoup de différence entre les poignées, et en plus, je peux éviter les spoilers.

Comme d'habitude, commençons par la dernière image:


La première chose que j'ai remarquée était un équilibre complètement différent dans ce jeu d'événements de rendu par rapport à ce que j'ai vu dans d'autres jeux plus tôt. Il existe de nombreux appels de tirage ici, ce qui est normal, mais étonnamment, seuls quelques-uns d'entre eux sont utilisés pour le post-traitement. Dans d'autres jeux, après le rendu des couleurs pour obtenir le résultat final, le cadre passe par de nombreuses autres étapes, mais dans A Plague Tale: Innocence la pile de post-traitement est très petite et optimisée pour seulement quelques événements de rendu / informatique.

Le jeu commence à construire un cadre en rendant GBuffer avec six cibles de rendu. Fait intéressant, toutes ces cibles de rendu ont un format entier non signé 32 bits (à l'exception d'un) au lieu des couleurs RGBA8 ou d'autres formats spécifiques à ces données. Cela a été difficile car j'ai dû décoder chaque canal manuellement en utilisant la fonction Custom Shader de NSight. J'ai passé beaucoup de temps à déterminer quelles valeurs sont encodées dans des cibles 32 bits, mais il est possible que j'ai raté quelque chose de toute façon.


GBuffer 0

La première cible contient des valeurs d'ombrage en 24 bits et d'autres valeurs pour les cheveux en 8 bits.


GBuffer 1

La deuxième cible ressemble à une cible RGBA8 traditionnelle avec différentes valeurs de contrôle de matériau dans chaque canal. Pour autant que je sache, le canal rouge est métallique (il n'est pas entièrement clair pourquoi certaines feuilles en sont marquées), le canal vert ressemble à une valeur de rugosité et le canal bleu est le masque du personnage principal. Aucune des captures que j'ai faites n'utilisait le canal alpha.


GBuffer 2

La troisième cible ressemble également à RGBA8 avec albédo dans les canaux RVB, et le canal alpha dans chaque capture que j'ai faite était complètement blanc, donc je ne comprends pas très bien ce que ces données devraient faire.


GBuffer3

La quatrième cible est curieuse car sur toutes mes captures elle est presque entièrement noire. Les valeurs ressemblent à un masque d'une partie de la végétation et de tous les cheveux / fourrure. Cela a peut-être quelque chose à voir avec la translucidité.


GBuffer 4

La cinquième cible est probablement une sorte d'encodage normal, parce que je ne les ai vus nulle part ailleurs, et le shader semble échantillonner des cartes normales, puis sortir vers cette cible. Dans cet esprit, je n'ai pas compris comment les visualiser correctement.


Profondeur de GBuffer 5


Masque de GBuffer 5

Cette dernière cible est une exception car elle utilise un format à virgule flottante 32 bits. La raison en est qu'il contient la profondeur linéaire de l'image et que le bit de signe code un autre masque, masquant à nouveau les cheveux et une partie de la végétation.

Une fois la création de GBuffer terminée, la résolution de la carte de profondeur est réduite dans le shader de calcul, puis les cartes d'ombre (cartes d'ombre directionnelles en cascade du soleil et cartes de profondeur cubique des sources lumineuses ponctuelles) sont rendues.


Rayons crépusculaires

Après avoir terminé les cartes d'ombre, vous pouvez calculer l'éclairage, mais avant cela, les rayons divins sont rendus dans une cible distincte.


SSAO

Au stade du calcul de l'éclairage, un shader de calcul est effectué pour calculer le SSAO.


Géométrie opaque éclairée

L'éclairage est ajouté à partir de cartes cubiques et de sources lumineuses locales. Toutes ces différentes sources de lumière, combinées avec les cibles rendues ci-dessus, forment une image HDR illuminée en conséquence.


Éléments de rendu proactifs

Les éléments rendus en rendu proactif sont ajoutés au-dessus de la géométrie opaque illuminée, mais ils ne sont pas particulièrement visibles dans cette scène.

Après l'accumulation de toutes les couleurs, nous avons presque terminé, il n'y a que quelques opérations de post-traitement et l'interface utilisateur.


La résolution des couleurs est réduite dans le nuanceur de calcul, puis augmentée pour créer un effet de floraison très beau et doux.


Après avoir composé tous les résultats précédents, ajouté la saleté de la caméra, l'étalonnage des couleurs et enfin la correction d'image tonale, nous obtenons les couleurs de la scène. La superposition de l'interface utilisateur nous donne une image depuis le début de l'article.

Il convient de mentionner quelques éléments intéressants sur le rendu:

• L'instanciation (duplication de géométrie) n'est utilisée que pour les maillages individuels (il semble que ce soit uniquement pour la végétation). Tous les autres objets sont rendus dans des appels de dessin séparés.
• Il semble que les objets soient triés approximativement d'avant en arrière, à quelques exceptions près.
• Il semble que les développeurs n'aient fait aucun effort pour regrouper les appels de tirage en termes de paramètres matériels.

Les rats

Comme je l'ai dit au début de l'article, l'une des raisons pour lesquelles j'ai voulu explorer ce jeu était à cause de la façon de rendre la meute de rats. La décision m'a déçu à certains égards: il semble qu'elle ait été prise par la force brute. Ici, j'utilise des captures d'écran d'une autre scène du jeu, mais j'espère qu'il n'y a pas de spoilers.


Comme avec d'autres objets, les rats ne semblent pas avoir de duplication de géométrie, à moins que nous n'atteignions la distance à laquelle nous passons au dernier niveau de détail du maillage (LOD). Voyons comment cela fonctionne.


LOD0


LOD1


LOD2


LOD3

Les rats ont 4 niveaux LOD. Fait intéressant, au troisième niveau, la queue est courbée vers le corps, contrairement à la quatrième queue. Cela signifie probablement que les animations ne sont actives que pour les deux premiers niveaux. Malheureusement, NSight Graphics ne semble pas avoir suffisamment d'outils pour le tester.


Pas de duplication (instanciation) de rats.

Avec duplication.


Dans la scène ci-dessus, le nombre de rats suivant a été rendu:

• LOD0 - 200
• LOD1 - 200
• LOD2 - 1258
• LOD3 - 3500 (avec duplication de la géométrie)

Cela nous fait comprendre qu'il existe une limite stricte sur le nombre de rats qui peuvent être rendus sur les deux premiers LOD.

Dans la capture que j'ai faite, je n'ai pas pu identifier de logique reliant les rats aux LOD individuels. Parfois, les rats plus proches de la caméra ne sont pas très détaillés, et parfois les rats à peine visibles ont des détails élevés.

En conclusion

Plague Tale: Innocence est très intéressant en termes de rendu. Ses résultats m'ont sans aucun doute impressionné, ils servent très bien le gameplay. Comme avec tout moteur propriétaire, ce serait formidable d'entendre une analyse plus détaillée de la bouche des développeurs eux-mêmes, surtout parce que je n'ai pas pu confirmer certaines de mes théories. J'espère que mon article parviendra un jour à quelqu'un d'Asobo Studio et qu'ils verront que les gens sont intéressés par cela.