La popularisation des processeurs à six et huit cœurs signifie qu'une puissance de traitement inexploitée devient disponible pour les jeux vidéo, et une partie de cette puissance peut être utilisée pour améliorer l'expérience audio des joueurs. Pour tirer parti des cœurs additionnels disponibles, les développeurs doivent paralléliser de manière agressive l'exécution du code et s'assurer que les fonctionnalités du jeu s'adaptent correctement aux différents processeurs. Cet article, basé sur un effort conjoint d'IO Interactive* et d'Intel, montre comment nous avons utilisé les processeurs multicœurs et la parallélisation pour rendre le son de Hitman 2* plus immersif. Plus précisément, nous allons parler de l'amélioration d'un domaine important et coûteux en ressources concernant l’audio de jeux : la réverbération.

À propos de Hitman 2

Hitman 2, un jeu vidéo de furtivité développé par IO Interactive, studio basé à Copenhague, est sorti en novembre 2018 ; il s’agit d’un épisode de la franchise qui a attiré des millions de fans dans le monde entier. Nos joueurs, qui prennent le contrôle de l'emblématique assassin Agent 47, explorent des niveaux vastes et vivants, et trouvent des moyens créatifs d'éliminer à la perfection des cibles importantes et bien protégées.

Qu'il s'agisse d'accéder discrètement à la cible en se déguisant en un autre personnage du jeu, d'orchestrer un accident, ou de terminer la mission pistolets dégainés, c'est au joueur de décider. Le jeu offre de nombreuses options pour chaque approche, ainsi que la possibilité de jouer avec ou contre une autre personne dans les modes multijoueurs Coop et Versus. Hitman 2 est un univers vivant qui ne cesse de s'enrichir de nouveaux lieux, de nouvelles missions et de nouveaux contenus grâce à des mises à jour régulières.

 

Le jeu est développé sur le moteur de jeu propriétaire Glacier, ainsi qu’avec Wwise comme middleware audio. De nombreux détails d'implémentation cités dans cet article seront donc spécifiques à Wwise, mais ils peuvent être facilement adaptés à n'importe quel moteur audio.

Système de réverbération simple et inconvénients

La réverbération est le phénomène qui se crée lorsque les ondes sonores sont réfléchies par les surfaces environnantes. Ces réflexions amplifient et colorent le son et le font persister après l'extinction du son original, direct. Dans les jeux vidéo, la réverbération est un outil d'immersion important, qui donne aux joueurs des indices auditifs sur les environnements où se déroule l'action. Compte tenu de la myriade de réflexions qui contribuent à un son réverbéré, la simulation précise de ce phénomène est très coûteuse en termes de calcul ; les développeurs de jeux doivent donc recourir à diverses approximations.

Une approche populaire consiste à subdiviser spatialement le monde du jeu en zones distinctes, et à attribuer un préréglage de réverbération à chaque zone. Cet article fait référence à de telles zones sous la dénomination « rooms » (pièces), par souci de cohérence avec la terminologie de Glacier et Wwise, même si elles ne représentent pas nécessairement des espaces clos. Dans ce contexte, une room est une partie d’un niveau de jeu ayant des propriétés acoustiques identiques. Par conséquent, les rooms imitent grossièrement la structure physique du niveau, représentant à la fois des environnements intérieurs et extérieurs, et même des parties de terrain ouvert. Dans Hitman 2, elles sont définies à l'aide de formes 3D telles que des cubes, des cônes, et des formes polygonales convexes, comme le montre l'image 1.

Image 1. Un exemple très simple de géométrie du son. Dans cette situation, la cabane entière est représentée par une room audio colorée en rouge.

Un préréglage de réverbération est un effet de réverbération comprenant des paramètres prédéfinis qui sont ensuite ajustés pour simuler l'acoustique d'un espace spécifique. L'effet utilisé peut être une réverbération de synthèse (comme Wwise RoomVerb) ou une réverbération à convolution. Hitman 2 utilise le plus souvent cette dernière.

Les effets de synthèse simulent la réverbération de manière algorithmique en utilisant des lignes de retard et des filtres comme le filtre en peigne ou le filtre passe-tout. Ces effets utilisent moins de CPU, mais ils ont tendance à sonner de manière moins naturelle et esthétique que la réverbération à convolution, en particulier pour des espaces à l'acoustique complexe et au temps de réverbération plus long. Ils ont également tendance à être plus difficiles à configurer pour obtenir des résultats satisfaisants.

La réverbération à convolution, quant à elle, utilise une réponse impulsionnelle préenregistrée d'un lieu réel. Une réponse impulsionnelle est créée en jouant un son court, tel qu'un éclat ou un coup de pistolet de starter, et en enregistrant la réponse acoustique de la pièce. L'échantillon audio résultant est appliqué aux sons du jeu à l'aide d’une opération de convolution, ce qui leur donne l'impression de jouer dans cette même pièce. La réverbération à convolution est lourde pour le processeur et la mémoire, et nécessite d'acheter, de trouver ou d'enregistrer des réponses impulsionnelles, ce qui peut être coûteux ou peut prendre du temps. Cependant, une fois que vous avez de bonnes réponses impulsionnelles, le son est incroyablement convaincant, recréant de manière réaliste même les environnements acoustiques complexes, et ne nécessite que peu de réglages et d'ajustements.

Le jeu vérifie en permanence dans quelle room se trouve le listener et applique le préréglage de réverbération attribué à cette pièce sur tous les sons 3D en cours de lecture. Le listener est généralement placé sur la tête du personnage contrôlé par le joueur ou sur la caméra du jeu. Simple à implémenter et assez efficace, cette solution a été utilisée dans de nombreux jeux, notamment dans la série Hitman. Cependant, elle est également très rudimentaire et présente plusieurs inconvénients importants.

L'un de ces inconvénients peut être démontré par un exemple simple. Imaginez que vous êtes un personnage du jeu qui s'abrite dans un petit bunker en béton, et qui combat des ennemis vous tirant dessus depuis une campagne vallonnée. Notre solution simple consiste à appliquer la réverbération du bunker au son des tirs de vos ennemis ainsi qu'au son de votre propre arme. Au lieu d’entendre l'écho associé aux zones ouvertes et vallonnées, les tirs des ennemis auront un son sourd et métallique, comme s'ils avaient été tirés depuis l'intérieur de votre bunker en béton. Cela ne vous donne pas, en tant que joueur, une indication correcte de l'environnement du son, et peut sembler peu naturel. Dans la vie réelle, le son provenant des champs est d’abord coloré et enrichi des réflexions et des échos provenant des collines, et de manière plus marquée que par les réflexions des murs du bunker où se situe le joueur.

Pour résoudre ce problème, la réverbération de chaque son devrait simuler les réflexions des surfaces qu’il rencontre lorsqu’il se propage vers le listener. Encore une fois, cela serait très coûteux en ressources CPU. Mais nous pouvons nous en approcher approximativement en relevant les différentes rooms que le son traverse avant d'atteindre le listener, et en appliquant à la chaîne les préréglages de réverbération de ces rooms sur ce son. Même en appliquant uniquement la réverbération de la room où se trouve l'émetteur du son sur chaque son individuel, on peut, dans de nombreux cas, obtenir de meilleurs indices spatiaux qu'en appliquant sur tous les sons la réverbération de la room où se trouve le listener.

Regardez la vidéo de l'image 2 pour une démonstration de différentes réverbérations et de différentes façons de les appliquer à des sons dans Hitman 2.

Image 2. Explication d'une fonctionnalité audio : La vidéo sur la réverbération illustre les points abordés dans cette section.

Utiliser la réverbération des zones à partir desquelles ou à travers lesquelles le son se propage pose plusieurs défis :

• Coût en ressources CPU pour le rendu des effets de réverbération
• Détection des rooms
• Application à la chaîne des effets de réverbération
• Directionnalité de la réverbération
• Adaptation à différents processeurs

Examinons chacun de ces points en détail.

Coût en ressources CPU pour le rendu des effets de réverbération

Les effets de réverbération ont tendance à être lourds pour le CPU, ce qui oblige les jeux à minimiser le nombre d'instances d'effets actives en même temps. Par conséquent, les effets de réverbération ne sont généralement pas appliqués à des sons individuels. Au lieu de cela, les sons qui ont besoin d'un certain effet de réverbération sont acheminés vers un bus auxiliaire qui effectue un sous-mix et applique l'effet souhaité une seule fois. L'intensité de la réverbération pour chaque son est simplement gérée par un contrôle de volume spécifique, appelé valeur d'envoi (« send »), lorsque le son est mixé dans un bus. Il s’agit de la pratique standard dans la plupart des jeux. Dans Wwise, le routing se fait sur les émetteurs des sons en utilisant l’API SetGameObjectAuxSendValues.

Hitman 2 a plusieurs dizaines de bus de réverbération représentant des environnements types, comme le montre l'image 3. Chaque room du jeu se voit attribuer un de ces bus par les concepteurs sonores.

 Image 3. Hiérarchie des bus de réverbération dans notre projet Wwise.

Un effet placé sur un bus n'est rendu que lorsque ce bus est actif ou, en d'autres termes, lorsque des sons sont acheminés vers ce bus. Les bus qui ne jouent pas de sons restent inactifs et leurs effets n'utilisent généralement pas de ressources CPU. Une exception à cette règle se produit lorsque tous les sons acheminés vers le bus sont terminés, mais que le bus reste actif afin de finir de jouer l’extinction du son généré par ses effets, comme la résonance de la réverbération.

Empreinte CPU de la solution précédente

La solution précédente est peu coûteuse en termes d'utilisation du CPU. L’acheminement de tous les sons vers le bus de la room où se situe le listener signifie que nous ne rendons qu'un seul effet de réverbération. Il y a plusieurs bus actifs simultanément lorsque le listener se trouve près de portals qui connectent des rooms entre elles (par exemple, des portes et autres ouvertures). Dans ce cas, nous devons acheminer les sons non seulement vers le bus de la room où se trouve le listener, mais aussi vers les bus des rooms situées de l'autre côté des portals environnant. Cela permet d'assurer une transition fluide de la réverbération lorsque le listener se déplace d'une pièce à l'autre. Malgré cela, le nombre de bus actifs ne dépasse jamais deux ou trois, ce qui rend le coût CPU des effets utilisés moins préoccupant.

Empreinte CPU de notre nouvelle solution

La situation est totalement différente dès lors que nous commençons à acheminer les sons vers les bus des rooms où ils se trouvent. Étant donné que le nombre maximum de sons joués simultanément (plafond de voix) dans Hitman 2 est de 64, nous pourrions en théorie nous retrouver avec un maximum de 64 bus de réverbération actifs, si chaque son se trouve dans sa propre salle avec son propre bus unique. Bien qu'en pratique ce scénario catastrophe soit extrêmement improbable, le nombre de bus de réverbération actifs est néanmoins plus élevé qu'avec l'ancienne solution, avec une moyenne d'environ 8 à 10 bus actifs simultanément. Par exemple, regardez la capture d'écran de l’Advanced Profiler de Wwise de l'image 4, montrant les bus de réverbération actifs dans un niveau de jeu type ainsi que le nombre de sons mixés dans chaque bus (colonne Mix Count).

Image 4. Liste des bus de réverbération actifs. Notez que certains bus sont actifs même si leur Mix Count est à 0. Ils jouent l’extinction de la réverbération des sons qui ont déjà fini de jouer.

Les 8 à 10 instances de réverbération peuvent sembler ne pas être une énorme différence par rapport aux 2 à 3 de l'ancienne solution. Cependant, nous utilisons une réverbération à convolution, qui a un coût CPU élevé augmentant linéairement avec le nombre d'instances de réverbération. Le passage au nouveau système augmente donc le temps de rendu audio total de plus de 50 %, selon les paramètres de la réverbération. Cela peut entraîner des coupures si le rendu n'est pas terminé avant que le système hardware n’arrive à sa limite de données sonores à lire, ou du moins cela peut avoir un impact négatif sur la fréquence d’images par seconde (fps).

Parallélisation du rendu audio

La bonne nouvelle est que les bus de réverbération ne dépendent pas les uns des autres et que leurs effets sont imprimés dans la mémoire tampon (« buffer ») du sous-mixage propre à chaque bus. Ils sont donc de parfaits candidats pour une exécution en parallèle. C'est là que les CPU multicœurs modernes entrent en jeu, car le rendu des effets de réverbération en parallèle sur différents fils d’exécution matériels peut réduire ou même annuler complètement l'impact négatif du nombre accru d'instances de réverbération.

Parce que nous utilisons Wwise, nous pouvons effectuer cela sans aucun coût. Le rendu audio basé sur les tâches, implémenté par les ingénieurs d'Intel, est inclus dans le kit de développement logiciel (SDK) standard de Wwise depuis la version 2018.1. Il décompose le processus de rendu audio en plusieurs ensembles de tâches granulaires qui peuvent être effectuées en parallèle, et demande ensuite au jeu de les exécuter. Ces tâches sont assignées à notre propre planificateur de tâches, qui les traite sur les fils d’exécution de travail disponibles, comme le montre l'image 5. Les jeux qui utilisent Wwise mais ne disposent pas d'un planificateur de tâches peuvent bénéficier de l'exemple d'implémentation fourni dans le SDK (voir l'exemple de TaskScheduler). Il requiert peu de travail pour commencer à être utilisé, et l'amélioration du temps de rendu audio est clairement notable.

 Image 5. Cette capture d'écran du profiler de Glacier montre le rendu parallélisé d'une trame audio typique dans Hitman 2. Les lignes horizontales intitulées « JqWorker » sont des fils d’exécution de travail, tandis que les éléments rouges et jaunes représentent des tâches individuelles (« jobs » dans la terminologie de Glacier) exécutées par ces fils d’exécution. La vue est filtrée pour ne montrer que les tâches audio.

Comparaison des performances

Examinons les performances avec et sans rendu audio parallélisé. Pour cette comparaison, nous avons mesuré le temps moyen de rendu des trames audio lorsque le joueur est inactif à l'endroit visible dans l'image 6.

 Image 6. Emplacement du niveau de Miami dans Hitman 2 utilisé pour les mesures de performance.

Dans le premier cas, l'ancien système de réverbération est activé. L'emplacement test se trouve à proximité d'un portal, il y a donc deux réverbérations actives. Dans le deuxième cas, nous passons à la nouvelle solution, ce qui donne huit réverbérations actives. Enfin, nous mettons en avant ce qui se passe lorsque le nouveau système est combiné avec les préréglages de réverbération de la plus haute qualité et qui sonnent le mieux, mais qui sont aussi les plus lents à rendre.

Dans tous les cas, l'effet utilisé est Wwise Convolution Reverb. Pour ceux qui connaissent ce plugin, les préréglages utilisés dans les deux premiers tests ont des réponses impulsionnelles (IRs) mono et un seuil de volume de -50 dB, alors que le dernier test utilise des préréglages comprenant des réponses impulsionnelles stéréo avec un seuil de volume de -144 dB. La longueur des réponses impulsionnelles utilisées dans les préréglages ordinaires et de haute qualité est identique et varie de une à trois secondes selon les différents préréglages.

L'image 7 montre les résultats de ces tests sur un PC avec un processeur à six cœurs.

Comme vous pouvez le constater, l'utilisation du rendu audio parallélisé (courbe verte) entraîne une amélioration de 1,45x dans le premier test, de 2x dans le second et de 1,9x dans le troisième, par rapport à la version non parallélisée (courbe orange). Plus important encore, elle optimise l'usage croissant des réverbérations, considérant que le nombre d'instances de réverbération et le coût CPU de chaque instance augmentent.

Sur le PC de test, chaque tâche a pris en moyenne 60 microsecondes, ce qui constitue une granularité de tâche plutôt convaincante. Les tâches concernant la réverbération à convolution constituaient une exception notable, prenant jusqu'à 1 milliseconde (ms) pour rendre les effets avec les préréglages de la plus haute qualité. Cependant, même dans le cas du test le plus coûteux avec huit réverbérations de haute qualité, le temps total par fréquence d’image passé à exécuter les tâches audio sur tous les cœurs ne représentait en moyenne que 17 % du temps d'image d'un seul cœur. Cela signifie que les tâches audio occupent une quantité relativement faible du temps de calcul sur chaque cœur, laissant la plupart des ressources du CPU pour d'autres tâches de jeu.

Afin d’avoir une idée très approximative de la façon dont les mêmes tests se dérouleraient sur la Xbox One* et la PlayStation 4*, vous pouvez multiplier les temps montrés dans l’image 7 par quatre.

L’image 8 compare les gains de performance obtenus par la parallélisation sur des CPU avec différents nombres de cœurs. Elle montre clairement que l'exécution en simultané apporte une amélioration même sur les anciens CPU à quatre et six cœurs, les CPU modernes à huit cœurs bénéficiant des gains les plus importants.

Image 8. Gains de performance obtenus par parallélisation sur les processeurs Intel® Core™ avec différents nombres de cœurs. Pour chaque test et processeur, le facteur de gain est calculé en divisant le temps de rendu audio synchronisé par le temps de rendu parallélisé.

Détection des rooms

Pour déterminer vers quel bus de réverbération un son doit être acheminé, nous devons identifier la room où se trouve ce son. Pour arriver à cela, nous stockons les rooms dans une structure de données de subdivision spatiale qui permet une recherche rapide à partir d'un point (position de l'émetteur du son). Cet algorithme est décrit en détail dans la conférence Game Developers Conference Europe (GDCE) 2015, « Sound Propagation In Hitman ».

L'implémentation est simple ; le seul bémol à surveiller est de s'assurer que nous choisissons le bon environnement parmi plusieurs qui sont imbriqués ou se chevauchent. Nous pouvons faciliter cela en attribuant une priorité aux pièces. Les pièces les plus à l’extérieur doivent avoir la priorité la plus basse, tandis que les pièces les plus à l’intérieur doivent avoir la priorité la plus élevée. Cette priorité doit être calculée automatiquement, avec la possibilité de la modifier manuellement dans l'éditeur pour un réglage plus précis.

Il faut également penser à empêcher un changement abrupt de la réverbération lorsqu'un émetteur de son se déplace d'une pièce à l'autre. Pour ce faire, on utilisera des portals proches et on acheminera l'émetteur sonore vers les bus des rooms situées de l'autre côté de ces portals. Dans ce cas, la valeur d'envoi est déterminée selon un facteur de distance entre l'émetteur sonore et l'ouverture la plus proche menant à une autre room.

Pour implémenter cette méthode, nous avons besoin d'un moyen efficace d'obtenir une liste des portals situés à une certaine distance d'un point. Par conséquent, nous stockons la géométrie représentant les portals dans le même type de structure de subdivision spatiale que celle utilisée pour les rooms.

Il est nécessaire d’envoyer une requête pour identifier les rooms et les portals à proximité, et d’effectuer le routing vers les bus appropriés, à chaque image du jeu et pour chaque son. Nous pouvons éviter de le faire pour les sons qui n'ont pas changé de position, en supposant que la géométrie n'ait pas changé non plus. Mais il peut toujours rester une poignée de ces opérations à effectuer, et bien qu'elles soient relativement légères, elles peuvent s’additionner en une surcharge indésirable de travail sur le fil d’exécution principal. C'est donc une bonne idée de les décharger sur les fils d’exécution de travail parallèles.

Une approche possible consiste à subdiviser toutes les requêtes en sous-ensembles, chaque sous-ensemble étant traité dans sa propre tâche. Le nombre de tâches devrait correspondre au nombre fils d’exécution de travail disponibles ; choisissez donc la taille des sous-ensembles en tenant compte de ce facteur. Il est important de planifier les tâches juste après la mise à jour de la logique du jeu, afin qu'aucun nouvel émetteur ne soit créé pendant que nous exécutons les requêtes. Elles doivent se terminer avant de commencer le traitement des commandes audio, ou avant l'appel RenderAudio si vous utilisez Wwise.

Une approche encore plus efficace consiste à regrouper le processus complet de mise à jour des émetteurs sonores en une tâche individuelle, à exécuter en parallèle sur les fils d’exécution de travail. Le processus de mise à jour est ici un nom générique pour désigner tous les calculs que vous effectuez sur le fil d’exécution principal, à chaque image, pour chaque émetteur sonore. Il peut s'agir de calculs d'occlusion, de diffraction, de volumétrie, de Doppler et de réverbération.

Réverbérations en chaîne

Pour appliquer des réverbérations aux rooms que le son traverse avant d'atteindre le listener, il est nécessaire de mettre à la chaîne les bus des différentes rooms. Supposons que des sons se trouvent dans la room A et que le listener se trouve dans la room C. Les rooms A et C sont reliées par la room B. Nous commençons par acheminer les sons vers le bus de la room A. Ce bus est acheminé vers le bus de la room B, et ce dernier est acheminé vers le bus de la room C. Par conséquent, le son est affecté par la réverbération des trois rooms qu'il traverse.

Remarque concernant les performances : quel que soit le nombre de sons joués dans les trois rooms, le nombre de bus actifs sera toujours de trois. Mais si tous les sons joués se trouvent dans des rooms distinctes ou se propagent dans de nombreuses rooms différentes, vous vous retrouverez rapidement avec trop de bus actifs. Dans ce cas, vous devez implémenter une logique pour réduire leur nombre, par exemple en choisissant de ne pas acheminer le son vers un bus si cela ne devait pas avoir d'impact significatif sur le mix global.

Le système de propagation décrit dans l'exposé du GDCE mentionné plus haut peut être élargi afin d’identifier plusieurs chemins de propagation et plusieurs rooms au sein de chaque chemin de propagation. Une fois que vous avez cette information, l’implémentation d’un routing de bus est assez simple.

Configuration du routing des bus dans Wwise

Un article du blogue d'Audiokinetic intitulé Travailler avec la nouvelle architecture de bus 3D de Wwise 2017.1 : Simuler un système de surveillance audio explique la configuration en détail. Même si l’exemple type choisi dans l'article concerne l’implémentation d'un système de surveillance audio, les mêmes principes s'appliquent à l’implémentation de réverbérations en chaîne. Vous devez activer l’option Listener Relative Routing (connue sous le nom de Enable Positioning dans les versions antérieures à Wwise 2018.1) sur les bus de réverbération, enregistrer un émetteur de son pour chaque room, puis utiliser l'API SetListeners pour acheminer le son depuis un émetteur de room à un autre. Enfin, lorsque vous configurez le routing du bus de réverbération pour un émetteur de son générique à l'aide de l'API SetGameObjectAuxSendValues, définissez AkAuxSendValue::listenerID sur l'ID de l'émetteur de la room où se trouve cet émetteur générique.

Parallélisation du système de propagation

Le système de propagation original écrit pour Hitman (2016) n'a été utilisé que pour calculer l'occlusion et la diffraction ; il ne permet donc que de trouver le meilleur chemin de propagation depuis n'importe quelle room vers la room du listener. Par conséquent, la mise à jour des requêtes du système de propagation était peu coûteuse, prenant environ 0,1 ms par image, et nous avions l'habitude de l’effectuer sur le fil d’exécution principal. Cependant, le suivi des multiples chemins par lesquels le son peut atteindre le listener est plus coûteux, il était donc logique de le décharger sur les fils d’exécutions de travail parallèles.

La principale préoccupation lors de cette opération est d'éviter en toute circonstance d'attendre que la mise à jour soit terminée sur un autre fil d’exécution. Nous y parvenons grâce à deux astuces simples :

• Timing : La mise à jour du système de propagation est programmée au début de l'image, après avoir mis à jour la caméra et la position du personnage du jeu. C'est à ce moment-là que la position du listener est connue. Cela donne à la tâche de propagation suffisamment de temps pour se terminer avant que les données de propagation ne soient nécessaires à la mise à jour du système audio à la fin de l'image.
• Double tampon des données de propagation : Il est possible que les nouveaux sons générés par la boucle du jeu interrogent le système de propagation alors qu’il est en train d’être mis à jour. C'est pourquoi nous mettons en cache les données de propagation de la dernière image et les transmettons pendant l'image en cours. Les données de propagation sont changées à la fin de chaque image, avant la mise à jour du système audio.

Directionnalité de la réverbération

Un problème important présent dans l'ancienne solution à réverbération unique, mais encore plus dans la nouvelle, est que la plupart des effets de réverbération utilisés dans les jeux ne préservent pas la directionnalité des sons car ils sont à canal unique. Cela est fait pour des raisons de performance. Par conséquent, la réverbération est audible dans toutes les haut-parleurs, quelle que soit la direction d'où provient le son. Par exemple, supposons qu'un personnage non-joueur (NPC) tire un coup de feu à la gauche de votre personnage de jeu. Alors que le son direct sera clairement audible depuis la gauche, sa réverbération semblera émaner de tous les côtés. Cela fonctionne si le son et le listener se trouvent dans le même espace clos. Mais dans pratiquement tous les autres cas, nous voulons contrôler la directionnalité et la propagation de la réverbération. C'est particulièrement vrai lorsque plusieurs réverbérations peuvent être actives en même temps. Si le manque de directionnalité peut être toléré avec une ou deux réverbérations, le fait de disposer de nombreuses instances omnidirectionnelles peut donner lieu à un mix confus et de mauvaise qualité.

Panoramique des bus de réverbération

Une façon simple de résoudre ce problème de directionnalité est de traiter la sortie de la réverbération de chaque room comme un son 3D autonome et de lui donner une direction et un volume en utilisant les propriétés de panning et de Spread.

Les étapes pour implémenter ceci dans Wwise sont pratiquement les mêmes que celles décrites dans la section « Configuration du routing des bus dans Wwise ». Vous devez activer l’option Listener Relative Routing sur le bus de réverbération et associer ce bus à l'émetteur de la room en assignant l'ID de cet émetteur à AkAuxSendValue::listenerID lorsque vous configurez le routing de la réverbération pour les émetteurs génériques situés dans la room. Vous pouvez maintenant faire une panoramique sur la réverbération en positionnant l'émetteur de room au centre de la room ou sur les portals menant à la room du listener (ce qui est plus réaliste mais plus difficile à implémenter). Vous pouvez même implémenter un mix personnalisé en utilisant l'API RegisterBusVolumeCallback, ce qui est utile puisque c'est le seul moyen dans Wwise de contrôler la propriété de Spread en se basant sur autre chose que la distance entre l'émetteur et le listener.

L'inconvénient évident de cette méthode est que la réverbération de la room du listener ne peut pas être panoramisée de cette façon. Cela peut être un problème si la room représente un grand espace ouvert. Vous pouvez contourner ce problème en programmant des divisions de ces grands espaces en plusieurs parties, créant ainsi un émetteur de sons pour chaque partie et en acheminant les sons vers leurs parties respectives. Il peut être nécessaire de procéder de la même manière pour les grandes rooms sans listeners. Le découpage de la géométrie peut être effectué hors ligne dans un processus de génération de la géométrie.

L'autre inconvénient est lié aux performances. En activant le positionnement sur les bus de réverbération et en utilisant un émetteur de sons par room, vous créez effectivement une instance de bus active pour chaque room. Alors qu'auparavant, deux rooms utilisant le même bus de réverbération partageaient l'instance de bus active, ne générant qu'un seul effet de réverbération, elles auront désormais chacune leur propre instance de bus. Il en va de même pour la géométrie que vous divisez en petites parties comme décrit ci-dessus – chaque partie génère également une instance de bus. Cela peut être un problème ou non, selon votre géométrie.

Utilisation d'effets de réverbération en multicanal

Une autre façon de préserver la directionnalité de la réverbération est d'utiliser une réverbération en multicanal. Quatre canaux devraient suffire, à moins que la verticalité ne soit requise. Chaque son est mixé dans les canaux du bus de réverbération en fonction de son positionnement par rapport au listener. Une fois que tous les sons ont été sous-mixés, l'effet de réverbération est rendu séparément sur chaque canal, à l'exception des canaux qui n'ont pas de contenu audible pour cette image. Ensuite, les canaux du bus de réverbération sont mixés dans le bus audio de sortie final, dont la configuration de canaux correspond à la configuration réelle des haut-parleurs du joueur (stéréo, 5.1, 7.1, etc.).

Le coût de la réverbération est multiplié par le nombre de canaux lorsqu'on utilise cette approche. Par conséquent, il peut être dangereusement coûteux d'utiliser cet effet sur tous les bus de réverbération actifs. L'approche optimale consiste à utiliser une réverbération mono et une panoramique de bus de réverbération pour les rooms sans listener, et une réverbération en multicanal pour la room du listener. Lorsque le listener s'approche d'un portal menant à une room adjacente, la réverbération mono de cette pièce devrait se mélanger avec sa version en multicanal pour assurer une transition en douceur.

Wwise ne supporte pas les effets de réverbération en multicanal. La Wwise Convolution Reverb possède un mode Filtre qui fonctionne d'une manière proche de la logique décrite ci-dessus. Cependant, il n'est pas assez flexible en ce qui concerne les différentes configurations de canaux et, pour cette raison, ne peut être utilisé en production. Ce mode n'est pas non plus destiné à être utilisé pour simuler la réverbération. Par conséquent, l'utilisation de la réverbération en multicanal n'est une option que pour ceux qui souhaitent développer leur propre plugin de réverbération à convolution. Lors de l'implémentation d'un tel plugin, essayez de tirer parti de la parallélisation - le rendu de l'effet sur chaque canal doit être une tâche individuelle exécutée sur un fil d’exécution de travail parallèle. Ces tâches n'ont pas de dépendances mutuelles pendant l'exécution.

Adaptation à différents processeurs

Dans Hitman 2, nous avons conservé l'ancien système avec lequel nous avons livré les versions consoles. Pour la version PC cependant, le joueur peut choisir entre trois niveaux de qualité, globalement appelés qualité de la simulation :

• Basique : Aucune amélioration audio. Par défaut sur les processeurs à quatre cœurs physiques ou moins.
• Améliorée : Nouveau système de réverbération. Par défaut sur les processeurs ayant plus de quatre cœurs physiques.
• Optimale : Identique à Intermédiaire, mais avec des paramètres de réverbération de la plus haute qualité. Par défaut sur les processeurs ayant plus de six cœurs physiques.

Le joueur peut contrôler la qualité de la simulation audio dans les Options audio, comme le montre l’image 9.

 Image 9. Réglage de la qualité de la simulation audio.

Implémentation Wwise

La prise en charge de différents niveaux de qualité pour les effets de réverbération dans Wwise peut se faire en dupliquant la hiérarchie des bus de réverbération, comme le montre l’image 10, et en utilisant de meilleurs effets pour les bus de haute qualité. Le code choisit automatiquement le bon bus (standard ou HQ) en fonction de la valeur de qualité de la simulation.

Image 10. Les bus de haute qualité reflètent la hiérarchie des bus de réverbération standards.

Une autre approche, qui peut être plus facile à maintenir, consiste à conserver une seule hiérarchie et à ajouter les deux effets sur chaque bus de réverbération, et à contourner l'un des effets au moment de l'exécution du jeu à l'aide de RTPC depuis le code.

Quelle que soit la méthode choisie, vous devez stocker les médias des effets dans différentes Soundbanks et charger la bonne en fonction de la valeur de la qualité de la simulation choisie pour éviter une surcharge inutile de l'utilisation de la mémoire. Nous utilisons une Soundbank de réverbération à convolution différente pour chaque niveau, comme le montre l’image 11.

 Image 11. Structure des Soundbanks dans Hitman 2

Conclusion

Cet article montre comment l'utilisation de plusieurs cœurs sur les CPU modernes peut ouvrir des possibilités d'amélioration en audio de jeux vidéo qui étaient auparavant inaccessibles en raison du coût de calcul élevé. Les modifications du système de réverbération décrites ici ont été remarquées et appréciées par les joueurs de Hitman 2. Une meilleure parallélisation dans le système audio a libéré des ressources CPU qui ont été utilisées à bon escient par l'équipe audio et d'autres départements.

Pourtant, cet exemple est encore affecté par les limites des CPU multicœurs de moins bonne qualité. L'adoption généralisée de systèmes à plus de huit cœurs, l'effort conscient de parallélisation des calculs par les développeurs de jeux et l'utilisation de la vectorisation (par exemple, Intel® Advanced Vector Extensions 2 (Intel® AVX2) ou Intel® Advanced Vector Extensions 512 (Intel® AVX-512)) par les producteurs de middleware audio pourraient apporter encore plus de définition et d'immersion à l’audio de jeux vidéo.

 

Références

• Hitman 2

• IO Interactive

• Conférence de la Game Developers Conference Europe (GDCE) 2015, « Sound Propagation In Hitman » (Propagation du son dans Hitman).

• Travailler avec la nouvelle architecture de bus 3D de Wwise 2017.1 : Simulation d'un système de surveillance audio

 

Cet article a été initialement écrit pour Intel