L'introduction du workflow de gestion d’assets de type Event-Based Packaging (EBP) incluse dans Wwise 2019.2.1 a été accueillie par la communauté des développeurs Wwise-Unreal comme une solution subtile pour gérer les assets de Wwise dans Unreal. Cependant, certaines équipes ont rencontré des bugs pouvant bloquer la production lors de la transition depuis un workflow classique utilisant les SoundBanks. Alors que nous avons travaillé à la résolution des bugs signalés par les développeurs ayant fait le saut vers le workflow EBP, nous avons également planifié et implémenté les changements nécessaires pour retrouver la stabilité garantie lors du travail avec des SoundBanks. 


C’est très humblement que nous demandons aux équipes concernées d'accepter nos excuses pour les retards et les désagréments causés par les irrégularités de cette nouvelle fonctionnalité lors de son lancement. Nous aimerions vous partager les projets actuels de l'équipe Game Engine Integration pour vous donner un aperçu de ce à quoi vous pouvez vous attendre à l'avenir. Nous vous remercions de votre patience pendant que nous nous efforçons d'améliorer vos workflows de gestion des assets grâce à cette fonctionnalité.

Pourquoi avons-nous modifié notre intégration Unreal ?

L'une des fonctionnalités les plus demandées de notre intégration Unreal était de créer automatiquement les assets liés à Wwise dans la hiérarchie du projet Unreal. Il est vraiment fastidieux de devoir dupliquer manuellement les assets d’Event et de SoundBank dans Unreal. Pour que les noms d’Event dans Wwise soient synchronisés avec le nom de l’asset correspondant dans Unreal, il faut les renommer manuellement dans Unreal. De plus, les SoundBanks de Wwise ont toujours nécessité une attention particulière car elles ne sont pas des assets natifs d'Unreal.

Comment avons-nous modifié notre intégration Unreal ?

Pour résoudre les problèmes décrits ci-dessus, nous avons introduit la création automatique d’assets Unreal selon les Events présents dans le projet Wwise. Comme l'explique Fan Runpeng dans son article Event-Based Packaging Process Overview (Eng), chaque Event du projet Wwise est automatiquement conditionné dans un asset Unreal. L’asset de type Audiokinetic Bank existant dans Unreal peut toujours être utilisé pour regrouper les Events, mais le comportement par défaut est d'avoir un seul Event par SoundBank stocké dans les assets Unreal. Seules les parties Event et Structure d'un Event sont stockées dans les SoundBanks, car la partie Media des Events est traitée séparément. Le stockage des SoundBanks dans les ressources Unreal permet la mise à jour automatique des noms d'Event entre Wwise et Unreal. 

Quel a été le problème ?

Le workflow de gestion des assets de l'Event-Based Packaging peut être séparé en trois composantes principales :

• Création automatique de SoundBanks à Event unique
• Synchronisation des assets entre les projets Unreal et Wwise
• Gestion automatisée de la durée de vie des ressources (chargement, déchargement, préparation des ressources au moment de l'exécution)

Chacun de ces éléments est loin d'être une simple implémentation mineure et pourrait être considéré comme une fonctionnalité majeure. Comme les changements apportés affectent le pipeline de production des assets dans un projet Unreal, ce sont des fonctionnalités risquées à implémenter.

Si la création automatique de SoundBanks à Event unique n'a pas posé de problème, leur stockage dans des assets Unreal a augmenté le temps nécessaire à leur sauvegarde sur le disque. Nous ne l'avons pas remarqué lors de nos tests initiaux, mais après avoir entendu des équipes travaillant sur des projets plus importants peu après la sortie de cette mise à jour, nous avons réalisé que cela ralentissait leur pipeline. Cette situation est loin d’être optimale et nous prévoyons de l’améliorer, mais il s’agit plus d’un inconvénient que d’un problème.

C'est la partie du workflow concernant la synchronisation des assets qui a entraîné la plupart des problèmes signalés par les équipes concernées. Des bugs dans le code de synchronisation des assets ont également conduit à des builds déficients et à des problèmes de gestion de versions dont nous n'étions pas conscients. Le fait que nos SoundBank et nos médias soient stockés dans des assets Unreal a également rendu inutile le profiling des SoundBank Wwise. (Comme les SoundBank sont chargées dans la mémoire du moteur de jeu, elles ne sont pas visibles dans le Profiler de Wwise). De plus, l'utilisation au cœur du processus EBP des fonctions SetMedia/UnsetMedia, efficaces mais peu sécurisées, entraînait de nombreux crashs d'exécution. 

L'éditeur Unreal utilise l'outil Wwise Console pour effectuer l'opération de génération des SoundBanks à partir de la ligne de commande. Le fait que Wwise génère ces fichiers sur le disque, puis les lise et les stocke dans les assets d'Unreal implique plus d'E/S disque qu'auparavant. Pour améliorer la performance de cette opération, les données audio peuvent être générées via WAAPI lorsque l'outil de création de Wwise est connecté. Cependant, cela signifie également que nous devons désormais gérer deux façons différentes de générer les données audio. Bien que cela ne soit pas impossible, la complexité du système a été difficile à gérer et à supporter.

Comment envisageons-nous de résoudre le problème ?

Nous avons corrigé les bugs et les problèmes au fur et à mesure qu'ils ont été signalés depuis l'introduction de la méthode EBP. La correction la plus importante a consisté à renforcer les fonctions SetMedia/UnsetMedia du SDK afin d'avertir lorsqu'il est dangereux de libérer de la mémoire. Nous sommes également passés de l'utilisation de soft-references vers les médias dans les fichiers .uassets de Wwise Event à l'utilisation de hard-references, ce qui rend l'intégration plus fiable. Comme il reste des scénarios d'utilisation problématiques pour lesquels nous ne trouvons pas de solution dans l'architecture actuelle, nous avons commencé à remanier ces fonctionnalités pour Wwise 2022.1. 

Amélioration de Wwise

Pour éviter d'avoir deux façons de générer les données audio, nous avons ajouté une option « single-event banks » dans le SoundBank Manager de Wwise, afin que l’application Wwise Authoring les génère. La nouvelle option, appelée « Auto SoundBank Generation », sera disponible dans l'onglet SoundBanks des Project Settings. Elle sera désactivée par défaut et permettra de générer automatiquement des SoundBanks pour les Events qui ne sont pas actuellement dans une SoundBank.

Nous avons également amélioré le contenu des fichiers de métadonnées de SoundBank afin d'inclure toutes les informations requises par le moteur d'exécution pour reproduire le son tel que prévu par les concepteurs. Cela nous permet de renoncer à tout code de synchronisation des ressources dans notre intégration Unreal, car nous pouvons nous fier aux métadonnées comme unique point de référence (que nous appelons SSOT pour « Single Source Of Truth »). 

Simplification de l'intégration Unreal

Au lieu de remplir automatiquement le dossier Unreal Content avec tous les éléments présents dans le projet Wwise, les assets Unreal ne seront créés que lorsqu'ils seront nécessaires. À moins que vous ne choisissiez d'utiliser un Event spécifique dans votre projet Unreal, il n'y aura pas de création d'asset sur le disque. Ces assets ne contiendront qu'une référence aux ressources qu'ils utilisent jusqu'à ce que vous procédiez au package de votre projet. Ce n'est qu'à ce moment-là que les SoundBanks seront copiées dans la hiérarchie des dossiers de votre projet Unreal. Cela résoudra également le problème rencontré par les membres du projet qui ne travaillent pas sur l'audio, et qui devaient parfois installer Wwise pour avoir de l'audio dans leur projet. La nouvelle intégration ne requiert que la présence du dossier GeneratedSoundBanks pour avoir un support audio complet de Wwise dans le projet.

Migration depuis EBP vers SSOT

La migration d'un projet en EBP vers le nouveau workflow AutoBank/SSOT pourra prendre un certain temps. La durée de la migration est directement liée à la quantité d'assets Unreal présents dans le dossier Sound Data du projet Unreal. La migration devra être effectuée sur un système où Wwise est installé et le projet Wwise devra être ouvert pendant la migration. Nous nous attendons à ce que cette tâche prenne beaucoup de temps sur un gros projet. Mais heureusement, elle ne devra être effectuée qu'une seule fois.

Qu'est-ce qui va changer dans le workflow ?

L'objectif principal que nous nous sommes fixé est d'améliorer l'expérience d'utilisation de l'intégration Wwise dans Unreal. L'adaptation au nouveau workflow nécessitera probablement une période de transition, mais nous pensons que ces changements en valent la peine. Le résultat final sera une intégration Wwise - Unreal plus fiable et mieux adaptée aux équipes collaborant à l'aide d'un outil de gestion de versions.

Emplacement flexible des GeneratedSoundBanks

Un nouveau fichier de métadonnées (ProjectInfo.json) sera créé par Wwise lors de la génération des SoundBanks. Ce fichier contiendra les chemins où les SoundBanks seront générées pour chaque plateforme. Cela permettra aux équipes de choisir avec une plus grande flexibilité l'emplacement adapté où les SoundBanks devront être générées pour chaque plateforme, selon les besoins de leur workflow. Cela devrait également résoudre les problèmes de gestion de versions qui affectent de nombreuses équipes travaillant en EBP.

Modification des noms des assets Wwise

Le nouveau workflow n'exigera pas une correspondance directe entre le nom d'un Event dans Wwise et son asset Unreal correspondant. Cela signifie-t-il qu'il ne sera pas possible d'éditer les noms d'Event Wwise dans Unreal ? Absolument pas, nous permettons l'édition des noms d'éléments dans le WAAPI picker, ce qui vous permet de renommer les éléments de votre projet Wwise pendant qu'Unreal est ouvert au premier plan. 

Les assets Unreal sont comme des raccourcis vers le contenu des SoundBanks au lieu d'être des données sérialisées. Ils ne contiennent que des ID qui permettent au code d'intégration de trouver ce qui doit être chargé en mémoire pour que Wwise puisse jouer les sons.

Soutien minimal des External Sources (Sources Externes)

Une autre fonctionnalité de Wwise qui n'était pas gérée par notre intégration dans Unreal avant l'introduction de l’EBP est la fonctionnalité External Sources. Parce que de nombreux studios ont développé leur propre intégration de cette fonctionnalité Wwise dans Unreal, ils n'ont pas basculé depuis leur solution pour utiliser celle proposée par le code d'intégration. Certains ont même dû supprimer la prise en charge des External Sources du code d'intégration car elle interférait avec leur propre solution. 

Nous rendons la fonctionnalité External Sources de l'intégration Unreal complètement optionnelle.

En résumé

Les deux dernières années ont été un véritable voyage pour les développeurs de Wwise et Unreal qui ont adopté le workflow EBP. De nombreuses équipes nous ont dit qu'elles l'adoraient et qu'elles ne voudraient pas revenir au workflow manuel de gestion des SoundBanks. D'autres équipes veulent l'utiliser mais ses limitations ont eu trop d'impact sur leur workflow. Nous avons pris en compte tous les feedbbacks, les bons et les mauvais, afin de remanier le code d'intégration durant la dernière année.

Apporter la fonctionnalité EBP à Wwise Authoring et utiliser la stratégie SSOT dans le code d'intégration est, selon nous, la bonne direction. S'éloigner de l'utilisation des assets Unreal offre une meilleur clarté au pipeline des équipes audio. D'autres équipes utilisant leur propre moteur pourront implémenter le workflow AutoBank et SSOT. Cela crée également une voie claire pour améliorer notre intégration dans Unity pour les versions futures.

Si vous êtes intéressé(e) à essayer le nouveau workflow pour l'intégration Unreal de Wwise, gardez un œil sur la version Bêta de Wwise 2022.1 qui arrivera bientôt.