Dans sa conférence, il a prêté attention au principe de base de la construction de nombreux effets dans le jeu, ou au principe de granularité. Comment le studio a mis en œuvre un système à grande échelle de destructibilité réaliste, quelles sont les limites de ses propres ressources et des performances de la plate-forme auxquelles il a été confronté, quelles optimisations il a apportées et quelles leçons il a tirées de tout cela - plus loin dans le matériel.
Donc, d'abord sur les défis auxquels le studio a été confronté.
Le jeu se déroule dans un bâtiment d'agence gouvernementale de style brutaliste qui présente des caractéristiques surnaturelles comme des murs mobiles.
La structure du siège aurait dû paraître crédible, car il s'agit d'une agence gouvernementale qui emploie des milliers de personnel de service effectuant des missions de routine. Tables, téléphones, tasses, MFP - ce sont tous les attributs habituels pour un employé de bureau que vous vous attendez à voir sur le lieu de travail, et par leur présence, ils aident à raconter qualitativement l'histoire de cet endroit même. Le brutalisme signifie des tonnes de béton, mais pas seulement: nous avons ici à la fois du bois et du verre, qui créent le look le plus approprié pour un bâtiment de service spécial.
En matière de destruction, la première chose à laquelle il faut penser est la tactilité. L'équipe de développement a été chargée d'organiser un environnement interactif riche qui crée immédiatement le sentiment de pouvoir interagir avec presque tout ce qu'il contient.
De toute évidence, le studio a fait face à certaines restrictions pendant ses travaux. Les interactions avec les objets devaient avoir l'air et se sentir réalistes. Le joueur doit avoir une certaine liberté d'action en matière de destruction, mais pas illimitée, puisque les possibilités du jeu reposent sur les performances ultimes des plateformes, de la mémoire et des exigences en matière d'intelligence artificielle. Dans le même temps, l'équipe chargée de la mise en œuvre de l'environnement destructible s'est avérée assez petite, ce qui devait également être pris en compte dans les travaux.
Ainsi, la destructibilité en jeu est basée sur le principe de la granularité. C'est aussi la base de nombreux effets spéciaux en cinématographie. Sa signification est que la nature n'est pas quantifiée. Il s'agit d'une toile continue créée à partir d'un large éventail d'objets - du plus grand au plus petit, des solides à grande échelle à la poussière et à la fumée. Si quelque chose ne se reflète pas sur l'écran, l'image entière ne fonctionnera pas.
Dans un moteur de jeu, ce principe peut être implémenté selon trois niveaux de détail différents. Les objets sur eux sont présentés sous la forme de corps rigides (corps rigides), leurs parties, parties d'accessoires, accessoires eux-mêmes et l'environnement. Ce dernier dans ce cas est une sorte de grille statique avec laquelle les objets interactifs peuvent entrer en collision. Les particules de maillage, les hiérarchies solides et les décalcomanies de matériaux donnent aux objets plus de détails sur des calques spécifiques. Ainsi, des objets solides, nous passons à leurs fragments puis aux fragments. La dernière couche est constituée des particules elles-mêmes. Les sprites de particules, les particules de braise, le sable et plus encore jouent tous un rôle important dans le remplissage de ces dégradés.
La capture d'écran ci-dessus montre un environnement statique. Il semble assez vide, bien qu'il y ait quelques détails ici: par exemple, à l'arrière-plan, vous pouvez voir la balustrade des escaliers.
Il est étonnant de voir à quel point la perception change lorsque nous commençons à remplir l'espace d'objets avec lesquels nous pouvons interagir directement.
En ce qui concerne le flux de travail dans Remedy, il est en fait assez trivial. Les artistes d'environnement fournissent des modules de géométrie de niveau et des accessoires pour l'assemblage, après quoi le département VFX configure les plates-formes et les animations de destruction cinématographique. Enfin, le résultat est ensuite envoyé au propre moteur de Remedy, Northlight.
Il était nécessaire de décider d'une approche quant à la façon dont tout fonctionnerait, et l'équipe a opté pour une procédure.
Qu'est-ce que ça veut dire?
L'approche procédurale est un traitement et une interprétation des données basés sur des règles.
Les informations sur le monde du jeu sont représentées par des modèles contenant des métadonnées sur les matériaux. Ainsi, vous pouvez définir, par exemple, que les sièges du banc sont en tissu, la base est en béton, les plantes sont en fait des plantes. Après avoir défini les matériaux, vous pouvez formuler un ensemble fini de règles pour chacun d'entre eux, déterminant les réactions à toutes les actions pouvant être effectuées dans le jeu. Par exemple, de sorte que lors du tir des plantes, des morceaux de feuilles s'envolent, le béton se brise en fragments et le tuyau métallique se déforme et de l'eau en jaillit. Ensuite, toutes les données sont redirigées vers le moteur, et il réagit déjà à chaque interaction le cas échéant.
Alors pourquoi la destruction procédurale?
Parce qu'il fallait une rotation rapide et cohérente des actions, un comportement prévisible dans des conditions clairement définies. Il y a des centaines d'actifs impliqués dans le jeu. Dans l'image ci-dessus, vous pouvez voir toutes sortes de blocs qui composent des pièces, des murs, des colonnes, des escaliers, des balustrades, etc. En dessous se trouvent divers accessoires: tables, chaises, vases, plantes, ordinateurs, téléphones. Pour mettre en œuvre la destruction d'une telle variété d'objets, une équipe de seulement 1 à 3 personnes a été sélectionnée. Par conséquent, il était nécessaire de prédéterminer les modèles selon lesquels le monde fonctionne: si un objet est influencé d'une certaine manière, il est nécessaire qu'il se brise exactement comme il est prescrit pour la méthode de destruction choisie d'un matériau donné.
Il fallait donc définir un certain comportement en fonction du matériau. Pour que lorsque vous tiriez sur l'arbre, il volait en morceaux. Ou, si vous tirez sur du verre, il se briserait en éclats. Dans le même temps, les particules et les décalcomanies doivent également se comporter d'une certaine manière en fonction de la composition de l'objet.
Chaque matériau a sa propre géométrie de fracture, définie par différents niveaux. Dans l'exemple, on voit un morceau de garde-corps, à la base duquel se trouve du béton, puis un support métallique et, enfin, du bois. De gauche à droite, les étapes sont affichées au fur et à mesure de leur rupture:
- Le niveau A montre une rupture dans le béton. Il n'y a pas de décalcomanies ici, car il y a encore peu de fissures. On voit que le support est légèrement plié.
- Niveau B. Le métal a disparu, mais il reste plus de béton et de bois cassés.
- C : , .
Imaginons maintenant que nous touchions un certain coin d'un objet - alors il ne devrait pas se casser complètement, seulement une partie de celui-ci.
Ainsi, dans Control, il existe des corps solides qui sont un seul objet. Mais il y a aussi des détails reliés par des liens. Ce sont les mêmes corps rigides qu'une collision dite composée peut séparer.
Les pièces sont créées lors de l'initialisation, partagent un collisionneur commun et se déplacent en une seule pièce jusqu'à ce qu'elles se cassent. Ils sont reliés les uns aux autres par ces surfaces qui se touchent.
Parlons des connexions. Ils sont créés dans une hiérarchie géométrique basée sur des métadonnées. Les solides sont reliés les uns aux autres par une sorte de charnière - par exemple, dans le cas d'une porte ou d'un tiroir. Ils peuvent être détruits dynamiquement, encore une fois par la force de l'impulsion.
Il existe une physique spéciale de destruction des composés. Ils ne rompent pas avec l'objet - c'est-à-dire que si vous faites un trou dans la porte, la porte restera toujours un objet entier, maintenu ensemble par des connexions internes. Ainsi, si vous cassez le bloc parent RB1, la porte ne tombera pas de ses charnières: un morceau de celle-ci sera toujours attaché à l'ouverture, non affecté par l'impact. Et une porte avec un trou au milieu peut toujours être fermée et ouverte comme prévu. Ainsi, les développeurs ont voulu éviter les situations où les objets se cassent complètement, peu importe où et quelle force le coup est tombé, comme c'est le cas dans certains jeux.
La simulation propriétaire de Northlight exécute la logique de destruction et détermine quels événements et particules y réagissent. Le moteur physique NVIDIA modélise ensuite les corps rigides et tente de les intégrer aux contraintes du jeu.
La destruction elle-même est réalisée comme suit. Nous avons une géométrie d'entrée. Parfois, il est nécessaire de préparer le modèle à l'avance, de définir la géométrie de collage et de déterminer dans quels cas quelles pièces peuvent se casser. Les modèles sont ensuite envoyés à Houdini et y sont traités. Destruction in Houdini est une configuration HDA à grande échelle qui effectue des réactions basées sur le matériau et écrit des données en mémoire. Parfois, je devais corriger et définir manuellement certaines métadonnées physiques pour m'assurer que les paramètres étaient corrects, en particulier en ce qui concerne les connexions. Ensuite, toutes les données sont transférées vers le moteur, où elles sont utilisées pour créer le monde du jeu.
L'outil de destruction de Houdini ressemble à ceci. Disons que nous avons un bloc de béton comme entrée. Il est nécessaire de déterminer quelles zones peuvent casser et de fixer le matériau. Dans ce cas, le bloc effectuera la destruction selon les règles fixées pour le béton, le gérera et créera différentes hiérarchies en termes de géométrie de rendu et de collisions. Ensuite, vous devez vous assurer que la modélisation est effectuée dans le budget et le style que vous avez définis. Après cela, vous pouvez exporter le modèle vers le moteur.
Cela ressemble à ça dans le moteur. Vous avez une sorte de hiérarchie qui contient des informations sur les couches A, B, C, etc. Cela inclut le nom du matériau, que l'objet soit statique ou non, les données sur les connexions, leurs types, etc. La hiérarchie est représentée par des niveaux et les propriétés physiques diffèrent selon le nom du matériau. Si le nom est correctement spécifié, la physique est traitée par le moteur. Nous parlerons du problème des noms plus tard.
Ci-dessus, un scénario de simulation solide. Jesse tire des objets autour d'elle, et ils explosent, réalisant ainsi la physique de la destruction.
Étant donné qu'un environnement destructible est une chose gourmande en ressources et que les consoles et les PC ont leurs limites de performances, l'équipe a été confrontée à la tâche d'optimiser le système afin qu'il ne surcharge pas les appareils.
Puisqu'il était nécessaire de s'inscrire dans un certain budget de performance, une limite a été fixée à 200 solides actifs sur l'écran - de sorte que les objets en dehors de celui-ci ont complètement disparu.
Dans le cas d'événements impliquant de nombreux objets en mouvement rapide, il y a un retard dans les collisions afin que le système ait le temps de faire tous les calculs.
Le mode veille a également été implémenté pour les éléments inutilisés. Par exemple, si un bloc de béton tombe au sol, personne ne s'attend à ce qu'il commence à sauter comme une balle - il peut donc «s'endormir» assez rapidement. Cela s'applique à de nombreux objets du jeu. Pour la même raison, ils peuvent être empilés les uns sur les autres et de la même manière, ils resteront immobiles.
De plus, les espaces entre les éléments étaient remplis de particules. Ainsi, lorsqu'un objet est détruit, de la poussière ou des copeaux se forment autour de lui.
Tout dans le jeu est systématique et événementiel. Les événements de particules suivants existent:
- impact de balle, qui a un résultat différent selon le matériau;
- rompre la connexion entre deux parties; dans ce cas, une mise au rebut se produit, libérant des particules;
- destruction complète d'un objet, conduisant à sa désintégration en particules.
Ce qui précède montre le processus d'édition des particules. Dans le jeu, vous pouvez placer un certain système de particules, puis le modifier. Dans ce cas, la fréquence de formation d'étincelles change simplement. Fait intéressant, vous pouvez littéralement le changer en temps réel et obtenir immédiatement un retour instantané, puis le rejouer et voir comment l'effet fonctionne. Implémentée de cette manière, une boucle d'itération rapide vous permet de peaufiner des choses comme celle-ci jusqu'à ce qu'elles s'affichent correctement.
Une autre caractéristique des particules est la modélisation standard. De temps en temps, l'équipe devait utiliser des champs de distance signés (SDF). Grâce à cela, il était possible de s'assurer que les objets ne tombaient pas à travers le sol, ce qui aurait l'air extrêmement étrange.
Dans l'exemple ci-dessus, un objet destructible est une symbiose de particules et d'un solide. C'est ce que nous voyons. L'explosion crée de la poussière dans l'air en raison de couches supplémentaires de particules qui remplissent les lacunes manquantes dans le gradient de granularité.
Et le dernier - des décalcomanies de matériaux, dont il y en a beaucoup dans le jeu et qui sont générées dynamiquement. Fondamentalement, ce ne sont que des textures qui sont appliquées sur des objets pour créer une apparence de destruction.
Si quelque chose se brise, un autocollant fissuré apparaîtra sur l'article. Ils sont généralement créés à Houdini ou similaire. Dans Control, le choix de la décalcomanie souhaitée est effectué de manière dynamique en fonction du matériau. Cela a également permis d'utiliser une assez grande partie de la géométrie statique. Comme cela a été montré au début, il y a toujours de nombreux objets statiques autour de nous, qui peuvent également être soumis à une sorte d'influence dont il faut tenir compte.
Voilà à quoi ça ressemble. Si vous divisez le sol, le polygone lui-même restera le même, mais avec l'apparence des décalcomanies, son apparence peut beaucoup changer. Il est à noter qu'ils sont assez économiques et efficaces à utiliser.
Nous avons donc des particules, des solides et des décalcomanies. Dans cet exemple, j'ai dû faire quelques astuces, car un simple outil d'explosion ne générerait pas autant de décalcomanies. Maintenant, Jesse «jette» un objet qui peut laisser une bosse dans le sol. Dans le même temps, le sol reste un polygone statique, mais grâce aux décalcomanies, des marques d'impact restent dessus.
Abordons également le sujet des accessoires personnalisés. Il existe de nombreux objets dans le jeu à disperser - extincteurs, ordinateurs, lampes, etc. - qui ne peuvent pas être générés de manière complètement procédurale. Les artistes de l'environnement devaient encore définir manuellement les effets de chacun d'eux. Cependant, de par leur présence, le monde du jeu ne semble que plus riche et plus diversifié.
Alors, quelles leçons le studio a-t-il tirées de Control?
Les points suivants méritent d'être abordés ici:
- ;
- ;
- ;
- .
Le premier est la qualité de la géométrie. Une géométrie d'entrée incohérente peut résulter d'une mise à l'échelle et d'une orientation incorrectes, mais également d'affectations de matériaux incorrectes. Parfois, la qualité du maillage peut être trop faible, ce qui aura également un effet néfaste sur le résultat. Il arrive aussi que lorsque vous cassez un objet, vous vous rendez compte qu'il n'y a rien à l'intérieur, et c'est faux. Pour éviter de tels problèmes, il est nécessaire d'améliorer les données d'entrée, de normaliser l'ensemble du pipeline de géométrie afin que lors de l'exportation, le système avertisse si quelque chose ne répond pas aux critères et doit être corrigé. Cela aiderait à éviter les boucles de rétroaction constantes entre les différents services à la recherche du moment précis où les problèmes se posent.
De plus, ce serait bien d'avoir des outils intégrés pour que vous puissiez modéliser un objet et voir immédiatement à quoi il ressemblera une fois détruit. Évidemment, cela pose le défi de créer plus d'outils avec de meilleures interfaces, mais cela en vaut la peine.
Nous avons l'habitude de donner des noms à différentes choses. Mais le problème est que ces noms peuvent être incorrects. Par exemple, dans Control, il existe 17 désignations différentes pour le matériau «béton», et cela ne peut être imputé à personne, car il y a toujours un facteur humain. Le conseil de Richter est d'abandonner complètement la norme de dénomination. Mieux vaut n'avoir qu'une seule API de métadonnées. De cette façon, quel que soit l'outil utilisé par les artistes pour créer les accessoires, il est possible d'exporter les données vers le moteur directement à partir de là sans aucune étape intermédiaire.
Le prochain tutoriel est principalement spécifique à Houdini. L'essentiel est que souvent, lorsque vous commencez à travailler sur quelque chose, vous le refaitez plusieurs fois au cours du processus, créez des modules complémentaires et vous devez vous assurer que même après deux ans de travail, vous pourrez ouvrir le fichier source même si que l'outil de travail pouvait déjà avoir changé 20 fois. Cela signifie que vous avez besoin d'une sorte de standardisation pour travailler avec HDA. C'est ce sur quoi Remedy travaille en ce moment: s'assurer que tout est correctement distribué, pour ne jamais perdre aucune version de l'outil et avoir toujours la possibilité de répéter ce que vous avez fait dans le passé.
Il est important de noter ici que lorsque vous créez des outils automatisés, vous utilisez en fait le même logiciel que si vous faisiez tout manuellement. Et tant qu'ils ont le même backend, tout doit être parfaitement cohérent.
Les performances et les tests font partie des aspects les plus essentiels du développement.
Au départ, les tests n'étaient pas automatisés dans Remedy. Après avoir ajouté de nouveaux objets au niveau, vous deviez le parcourir manuellement pour vérifier que tout fonctionnait correctement. Mais ensuite, quelque chose a changé dans le moteur, le backend a changé, quelque chose a été optimisé et après cela, un nouveau test était nécessaire. C'est assez dangereux, car vous oublierez certainement de vérifier quelque chose. Bref, ce n'est pas le meilleur moyen, conduisant à une accumulation potentielle de bugs.
Le deuxième aspect concerne les tests de performance. Pendant longtemps, Remedy n'a mesuré aucune métrique significative comme la fréquence d'images ou le temps de calcul. Ainsi, les problèmes de performances étaient souvent découverts trop tard.
Ce qui peut être fait ici, c'est avant tout améliorer les indicateurs de performance. Il est nécessaire de déterminer quels paramètres augmenter affecteront le jeu le mieux ou le pire, afin de se fier à cela lors de l'optimisation et de la détermination d'un budget qui ne peut être dépassé.
En outre, des tests automatisés peuvent vous aider, dans lesquels vous pouvez également faire varier la sortie pour mieux démontrer l'impact des changements dans le moteur.
Vous pouvez également identifier et prendre des mesures contre la dégradation des performances. Par exemple, pour faire en sorte que lors d'événements à grande échelle, certains objets contournent des niveaux intermédiaires de destruction - par exemple, des solides allant directement aux particules.
Une autre mesure est le zonage de la zone en fonction de la charge attendue. Cette idée repose sur le fait que nous pouvons nous-mêmes déterminer dans quel domaine appliquer certaines contre-mesures afin de ne pas les appliquer à tous les actifs au niveau où cela n'est pas nécessaire. Par exemple, si bientôt des ennemis avec des grenades arrivent à temps à Jesse, il y aura évidemment trop de destruction sur le site, et pendant leur attaque, le processus de génération de destruction peut être accéléré.
En conséquence, je tiens à noter que l'équipe Remedy a fait un travail monumental, à partir duquel vous pouvez obtenir beaucoup d'idées concernant la mise en œuvre et l'optimisation du système de destruction procédurale de l'environnement.