For our specialization course, I wanted to do something with audio and decided to integrate Wwise with our own engine and implement audio-portals for an enhanced 3D experience.
What is an Audio portal?
An audio portal is a point connecting two areas where sound comes through from one area to the other. For instance, if you are inside a room and can hear sound from another room through an open door. The open doorway would be the portal.
The end product
Note! Because of Covid-19, our FPS project was on hold, so I had to use an early alpha version of our fps game.
To find the position to place the portal for a sound, I used the navmesh for our AI and did a pathfind from the emitter to the listener to get the first node on the path that had a clear way to the listener. That gave me the corner of a wall or a doorway to place the portal on. I also got values from the path for how far the audio had traveled to the portal.
I didnt have an easy way to raytrace with the geometry in the game so I could check if the listener is behind a wall before doing the pathfinding. I used the navmesh to create walls with the node edges that wasn't connected to any other nodes.
Getting the effects to sound right
After getting the position and path between the portal and the listener, I could get values like distance, to set the effects values on the source. Every sound event inherited from a parent mixer that has a room reverb effect. I used Wwise RTPC game parameters to control reverb level, reverb dry level and lowpassfilter from code. If an emitter is close to the listener, the reverb level is low and dry is high and vice verse. When there is a wall between the emitter and listener I add a lowpass filter on the original source and register a new object to represent the portal.
The gameparameters goes from 0 to 100, so I had to convert the values to match with that scale. I had to tinker around with some magic numbers to get it to sound right, which I'm not proud of but I'm somewhat happy with the results.
After I got it to sound alright I had to start to think about performance since pathfinding every frame for each emitter isn't great. First I added a timer so that each emitter only updated every 0.4 seconds which made it better but the game started to stutter since everything that spawned at the same time wanted to update at the same frame. I solved this buy adding a limit of how many emitters could update each frame. Every time an emitter want to update, i'ts added to a queue and then asks each frame if it is their turn to update and do so if it is their turn. The framerate was about the same as when I only had one emitter in the game after that. The precision of the audio effects was a little worse and unfortunatly i didn't have time to alter it any further.
In general I'm quite happy with the end result but of course there is a lot of things I could have done differently and better. A lot of the time went into integrating Wwise with the engine and learning about how Wwise works.
To create the portal effect I registerd two seperate objects that played the same event with different effect levels, but I later found out that I could have used Wwise 3D buses to get the same results but with just one object. I couldn't use random container for the event since the source and the portal wouldnt necessarily play the same audio. I could have used a lot more of Wwise tools if I had 3D buses.
When I started the project I had to deside if I wanted to use Wwise own spacial audio system to load in level geometry and let Wwise handle the rest. I wasn't sure how long it would take me to do and also felt that I wouldn't have control over the outcome and performance. In the future i might look into it more to see if it is a better option.