Month: June 2021

In meinem letzten Blogeintrag habe ich das grundlegende Prinzip der Soundengine von Unity, die auf der Verwendung von Audio Listenern und Audio Sources basiert, vorgestellt. Die Wwise-Soundengine arbeitet auf dem selben Prinzip und hat standardmäßig bereits vorhandene Skripte mit welchen die selben System realsiert werden können. Diese Skripte heißen AkAudioListener und AkGameObj. AkAudioListener ist der Wwise-Ersatz für den Audio Listener von Unity.

Ist die Position und Blickrichtung eines GameObjects notwendig, was bei den meisten diegetischen Klänge einer dreidimensionalen Spielwelt der Fall ist, muss dieses GameObject auch als ein solches in Wwise registriert werden. Dafür gibt es das AkGameObj-Skript, das auf alle GameObjects gelegt wird.

Das GameObject, das als Main Camera dient und auf welchem das AkAudioListener-Skript liegt, muss ebenfalls mit einem AkGameObj-Skript versehen werden, weil auch dessen Position und Blickrichtung notwendig ist, um den Abstand und die Richtung zu anderen GameObjects berechnen zu können. In Wwise kann das Verhalten des Richtungshörens und auch des Pegelabfalls bei steigernder Distanz von Audio Listener zu klangerzeugenden GameObject (wie der Rolloff in Unity) konfiguriert werden.

Das AkGameObj-Skript kann zusätzlich auch noch andere Parameter aus dem Spiel übermitteln, wie Switches, RTPCs oder Umgebungsinformationen.

Reverb Zones werden Wwise mithilfe von Aux-Bussen realisiert, mit welchen innerhalb von Wwise ein Hall-Effekt zum Direktsignal hinzugemischt wird. Tatsächlich können auch andere Effekte statt Hall-Effekte verwendet werden. Das hierfür benötigte Skript ist das AkEnvironment-Skript, welches auf einen Collider gelegt wird. Im Inspector des Collider-GameObjects kann ausgewählt werden, welcher Aux-Bus aktiviert werden soll, sobald der Collider betreten wird.

Dabei ist wichtig, dass das GameObject, wie z.B. der Audio Listener (also die Main Camera) im AkGameObj so konfiguriert wird, dass diese auf AkEnvironment-Skripte reagieren und damit ein Signal an den jeweiligen Aux-Bus senden.

Quellen:

[1] https://www.audiokinetic.com/courses/wwise301/?source=wwise301&id=Audio_Listener

[2] https://www.audiokinetic.com/library/edge/?source=Unity&id=class_ak_audio_listener.html

[3] https://www.audiokinetic.com/library/edge/?source=Unity&id=pg__wwise_components.html

[4] https://www.audiokinetic.com/library/edge/?source=Unity&id=class_ak_game_obj.html

[5] https://www.audiokinetic.com/library/edge/?source=Unity&id=unity_use__ak_environment__ak_environment_portal.html

Eines der grundlegenden Prinzipien der Soundwiedergabe in der Gameengine Unity ist das Zusammenspiel aus sogenannten Audio Listenern und Audio Sources. Auf diesem Prinzip basieren alle mit Unity entwickelten Spiele und Klangrealisierungen. Man muss sich ein Spiel ein wenig, wie einen Film vorstellen, bei welchem der Regisseur (oder aber der Spieleentwickler) genau festlegt, was der Spieler sehen kann und was nicht. Zwar hat der Spieler viel mehr Freiheiten als im Film, aber im Grunde ist es ein ähnliches Prinzip. Auf visueller Ebene wird eine Kamera genutzt, die der Spieler lenken kann. Diese wird oft Main Camera genannt und ist oft an die eigene Spielfigur in der ersten oder dritten Person gebunden. Gesehen werden können alle GameObjects die im Blickwinkel der Kamera sind und mit sichtbaren Texturen belegt sind.

Ähnlich verhält es sich auch auf klanglicher Ebene. Analog zum Visuellen kann man Audio Listener als die Main Camera sehen und Audio Sources wie visuelle GameObjects. Tatsächlich ist der Audio Listener in den meisten Fällen mit der Main Camera verknüpft und Audio Sources mit den GameObjects, die Sound erzeugen. Der Audio Listener ist quasi ein Mikrofon, der Signale von Audio Sources erhält und weiter an die Audioausgänge schickt. In Unity kann es standardmäßig nur einen Audio Listener geben.

Audio Listener empfangen also Signale von Audio Sources, welche aber noch durch Effekte, wie z.B. einen Hall, geschickt werden können, wenn der Audio Listener sich in einer sogenannten Reverb Zone befindet. Reverb Zones sind kugelförmige GameObjects, die ein bestimmtes Gebiet umfassen und nach Eintreten des Audio Listeners den Anteil des Halls hinzumischen, je nachdem, wie nah sich der Audio Listener am Zentrum der Reverb Zone befindet.

Audio Sources können auf zwei Arten implementiert sein: 2D und 3D, diese können mit dem Spatial Blend-Regler reguliert werden.

2D bedeutet, dass sowohl Abstand als auch Richtung zum Audio Listener nicht relevant sind und der Sound unabhängig davon abgespielt wird. Der Sound, außer er wird im Unity-Mixer oder im Inspector des selben GameObjects noch weiter bearbeitet, wird so wie er ist abgespielt. Das wird vor allem für Soundtracks oder klangliche Hintergrundkulissen, wie Atmo-Aufnahmen, verwendet.

3D hingegen setzt einen Sound Source in die dreidimensionale Spielwelt und erlaubt Richtungshören und zugleich variable Pegel, je nach Abstand des Audio Sources zum Audio Listener. Das Richtungshören wird ermöglicht, indem das ausgehende Audiosignal in ein Monosignal gewandelt wird und durch Pegelunterschiede ein Panning erhält. Es gibt zwar auch Lösungen für komplexere Surround-Sound-Verfahren, aber standardmäßig arbeitet Unity nur mit dieser vereinfachten Form, welches das Richtungshören ermöglicht. Von den verschiedenen 3D-Konfigurationsmöglichkeiten ist vor allem der Rolloff von großer Bedeutung. Damit lässt sich bestimmen, wie der Pegel, je nach Abstand zum Audio Listener, abfällt. Standardmäßig verwendet man entweder einen logarithmischen oder einen linearen Rolloff. Alternativ kann auch ein eigener, händisch eingezeichneter, Rolloff erstellt werden. Zusätzlich bestimmt man noch die Parameter Min Distance und Max Distance. Diese markieren einen Bereichen, in dem der Audio Listener sich befinden muss, um den Audio Source hören zu können und in welchem der Rolloff sich abspielt. Ist der Audio Listener außerhalb dieses Bereichs, wird das Signal nicht an diesen weitergegeben und folglich wird das Signal auch nicht abgespielt.

Quellen:

[1] https://docs.unity3d.com/Manual/class-AudioListener.html

[2] https://docs.unity3d.com/Manual/class-AudioReverbZone.html

[3] https://docs.unity3d.com/Manual/class-AudioSource.html

[4] https://docs.unity3d.com/Manual/AudioSpatializerSDK.html

[5] https://docs.unity3d.com/Manual/AmbisonicAudio.html

Neben der Nutzung vorgefertigter Skripte, die für die Implementierung von Wwise in Unity mitliefert sind, gibt es auch die Möglichkeit eigene Skripte bzw. eigenen Code zu schreiben, um Befehle an Wwise zu senden. Der Vorteil davon ist, dass man ganz genau bestimmen kann, an welcher Stelle Befehle an Wwise übermittelt werden sollen. Viele Funktionen werden außerdem von den mitgelieferten Skripten nicht abgedeckt und müssen deshalb selbst erstellt werden. Häufig muss z.B. ein Sound abgespielt werden, wenn ein Spieler eine Taste betätigt oder etwas im Spiel geschieht, was nicht mit Triggercollidern zu tun hat.

Für das Implementieren von Wwise in Unity mittels Skripte gibt es grundsätzlich zwei Möglichkeiten: Die direkte Hardkodierung eines Befehls oder die Kodierung mithilfe von Wwise-Types, die im Unity-Inspector einen Property Drawer anzeigen, mit welchem man Wwise-Objekte (Event, State, Switch usw.) auswählen kann.

Jeder hardkodierte Befehl beginnt mit dem Begriff AkSoundEngine, der quasi eine Information für Unity darstellt, dass ein Wwise-Objekt aufgerufen werden soll. Daraufhin wird bestimmt, welche Wwise-Funktion ausgeführt werden soll. Eine der grundlegendsten Funktionen ist “PostEvent” für das Aufrufen eines Wwise-Events. Desweiteren gibt es noch die Funktionen “setState” bzw. “setSwitch” zum Bestimmen eines States bzw. Switches, “setPosition“, damit Wwise die Position eines GameObjects bekommt, was für die korrekte dreidimensionale Wiedergabe von diegetischen Sounds benötigt wird, “setRTPC“, mit welchem Parameter aus dem Spiel an Wwise übermittelt werden und viele weitere Funktionen, die in der Wwise-Dokumentation nachgeschlagen werden können.
In den runden Klammern wird immer der Name des Wwise-Objekts als String mit angegeben. Manchmal werden noch andere Argumente benötigt, wie das GameObject, von dem der Befehl ausgeht.

Alternativ dazu kann man auch mithilfe von Wwise-Types Implementierungen realisieren. Dazu wird zunächst eine Variable mit einer Wwise-Type-Klasse initialisiert. Wwise-Type-Klassen sind die verschiedenen Arten von Wwise-Objekten. Das ist z.B. AK.Wwise.Event für Wwise-Events, AK.Wwise.State für Wwise-States und viele andere. Auch alle Wwise-Type-Klassen können in der Wwise-Dokumentation nachgeschlagen werden.

Daraufhin kann im Unity-Inspector im Property Drawer des Skripts das jeweilige Wwise-Objekt, welches im Wwise-Editor angelegt ist, ausgewählt werden.

Nach der Initialisierung wird die Variable in einer Funktion im Skript aufgerufen. Dabei wird die Variable mit der jeweiligen Wwise-Funktion aufgerufen, wie z.B. “Post()” bei Wwise-Events oder “SetValue()” bei RTPCs, States oder Switches.

Quellen:

[1] https://www.audiokinetic.com/courses/wwise301/?source=wwise301&id=Posting_Events_using_WwiseTypes#read

[2] https://www.audiokinetic.com/courses/wwise301/?source=wwise301&id=Creating_a_WwiseType_Event_property#read

[3] https://www.audiokinetic.com/library/edge/?source=SDK&id=waapi_functions_index.html

[4] https://www.audiokinetic.com/library/edge/?source=Unity&id=annotated.html

Bei meinem letzten Blogeintrag habe ich die Wwise-Implementierungsskripte AkInitializer und AkBank, die eine grundlegende Voraussetzung für die Nutzung der Wwise Audio-Engine bilden und das Laden von Soundbanks ermöglichen, beschrieben.

Ein Grundbaustein eines adaptiven Sounddesigns ist das adaptive Verhalten von Sounds, das auf unterschiedliche Gegebenheiten im Spiel reagiert. Dafür gibt es Switches und States, die quasi Zustände repräsentieren und wie Schalter aktiviert werden können. Der Hauptunterschied zwischen Switches und States ist, dass ein Switch jeweils einem einzigen GameObject zugeordnet wird, während States von unterschiedlichen GameObjects aktiviert werden können. Die Nutzung und Konfiguration beider Parameter ist hingegen identisch.

Für das Verändern eines Switches oder eines States gibt es extra dafür vorgefertigte Skripte namens AkSwitch und AkState. In Wwise müssen dafür bereits die unterschiedlichen States bzw. Switches und die State bzw. Switch-Container mit den Audiofiles vorhanden sein, damit man sie in Unity implementieren kann. Ist das gegeben legt man ein AkSwitch- bzw. AkState-Skript auf ein GameObject. In diesen kann man nun über den Unity-Inspector den Switch bzw. State wählen, der aktiviert werden soll.

Des Weiteren muss noch bestimmt werden, was den Switch bzw. State triggert. Klassischerweise ist es das Betreten oder Verlassen eines Colliders.

Hierbei sollte noch ein AkTriggerEnter– bzw. AkTriggerExit-Skript hinzugefügt werden, der spezifiziert, welches GameObject den Trigger auslöst, ansonsten löst jede Kollision mit irgendeinem anderen GameObject den Trigger aus, was in den meisten Fällen nicht gewünscht ist.

Quellen:

[1] https://www.audiokinetic.com/library/edge/?source=SDK&id=soundengine_switch.html

[2] https://www.audiokinetic.com/courses/wwise301/?source=wwise301&id=Setting_States_using_the_AkState_Component

Im letzten Blogpost habe ich die für Unity vorgefertigten Skripte AkEvent und AkTriggerEnter beschrieben, die in Kombination für das Auslösen von Wwise-Events genutzt werden. Dieses Mal möchte ich einige grundlegende Skripte zur Nutzung von Wwise vorstellen.

Damit die Unity-Engine allerdings überhaupt erkennt, dass es Wwise als Audio-Engine nutzen soll, muss zunächst Wwise beim Spielstart initialisiert werden. Das wird mit dem Skript AkInitializer realisiert. Hierfür wird ein leeres GameObject benötigt, das beim Starten des Spiels bereits vorhanden ist. Das GameObject wird im Inspector von Unity mit dem AkInitializer-Skript versehen, das automatisch beim Starten des Spiels geladen wird. Während des Spiels sorgt das Skript zusätzlich dafür, dass Frame für Frame Daten an die Wwise-Engine übetragen werden und somit die Kommunikation unter den beiden Engines gewährleistet wird. Das ist eine der Grundvoraussetzungen für die Nutzung von Wwise.

Eine mit AkInitializer nah verwandte Funktion von Wwise ist das Laden von sogenannten Soundbanks. Soundbanks sind Audiodaten und Befehle, die während des Spiels in den Arbeitsspeicher geladen werden und somit unmittelbar ohne längeren Wartezeiten abgerufen werden können. Große Spiele arbeiten mit vielen Soundbanks, die abhängig von der Position des Spielers oder anderen Bedingungen einzeln geladen und wieder entladen werden. Das ermöglicht die Realisierung von großen und komplexen Spielwelten auf einem PC oder einer Konsole. Häufig wird vom Entwicklerteam ein Datenmengenlimit vorgegeben, welches das Audio-Team nicht überschreiten darf.

Das Skript für das Laden von Soundbanks heißt AkBank und kann an unterschiedlichen Stellen ausgeführt werden. In der Regel hat man immer eine Soundbank, die beim Starten des Spiels geladen wird. Weitere Soundbanks werden unter anderem geladen, wenn ein neues Gebiet betreten wird. Das Laden einer Soundbank dauert eine Weile, weshalb einige Spiele währenddessen eine Ladesequenz anzeigen. Bei der praktischen Anwendung erfordert das Skript im Unity-Inspector eine Information, wann die Soundbank geladen, wann sie entladen werden soll. Dabei muss auch bestimmt werden, welche Soundbank geladen werden soll. Es gibt noch weitere Optionen, mit welchen sich einstellen lassen, wie dekodiert und wie genau mit den Daten verfahren werden soll. Das hilft beim Datenmanagement und ist vor allem für umfangreiche Spiele mit großen Datenmengen praktisch.

Quellen:

[1] https://www.audiokinetic.com/library/edge/?source=Unity&id=class_ak_initializer.html

[2] https://www.audiokinetic.com/library/edge/?source=WwiseFundamentalApproach&id=understanding_soundbanks_understanding_soundbanks