Hey Everyone!
I just found the FMOD Engine Documentation about 3D Reverbs - an awesome feature, which to me sounds way more convenient than snapshots, as those reverbs then actually exist in the world and aren’t a mix-overlay (like snapshots just have to behave in their own logic).
So I was wondering if there is any way to set up something similar in FMOD Studio directly to make use of the GUI interface for further mixing decision etc. and not only create a 3D Reverb in Code.
Looking forward to your answers and all the best!
Joshnt
It is, indeed, possible to design the kind of complex 3D reverbs you describe in FMOD Studio!
In fact, the Reverb DSP mentioned in the FMOD Engine documentation is the very same DSP that powers FMOD Studio’s reverb effect. Thus, you can use a reverb effect on a bus in FMOD Studio to produce the exact kinds of reverbs that you’re hoping for.
You’ll also need is a method of controlling the properties of that reverb effect. I assume you want to create the same kind of reverb volumes described in the 3D Reverbs whitepaper that you linked: Points in space, each with its own min and max distance that defines a spherical area around that point where the reverb is applied, which the FMOD Engine can interpolate between as the listener moves between them. Fortunately, it is trivially easy to build this kind of behavior with snapshots.
Snapshots can be assigned positions in 3D space and given 3D behavior in the same manner as events, which means it’s easy to make a snapshot that affects a spherical area and ramps up or down as the listener approaches or retreats from its center: All you have to do is automate the intensity property of the snapshot on a “distance” or “distance (normalized)” parameter such that the snapshot’s intensity is 0% at maximum distance and 100% at whatever distance you want to be the minimum distance.
To allow the FMOD engine to interpolate between different snapshots, you’ll have to ensure they’re the same priority. To do this, assign all your reverb snapshots to the same snapshot group.
Thus, if you create snapshots that represent your reverb zones, you can create instances of those snapshots and position them in the exact same positions that you would reverb zones created using the FMOD Engine’s 3D reverbs, and you’ll get the same behavior.
Oh, and because snapshots can be instanced, you’ll be able to reuse the same reverb snapshot for multiple reverb zones if those zones happen to have the same properties.
Awesome! Thank you a lot for your detailed answer, Joseph!
I was as well wondering: do the 3DReverbs created by code work on a per Event basis or (as the Reverb returns + snapshots in FMOD Studio) only for the listener? I’m thinking of a (made up) scenario, where you as a player might be standing in a small corridor leading to a large cave/ hall/ … and are hearing some enemy screaming from that large space. As the listener/ player triggers the snapshots/ determines the distance to them, that enemy scream would have the corridor reverb.
On the other hand, calculating the distance between each event and any snapshot (possibly even calculating which 2 snapshots are the closest) every update/ event tick to set e.g. the send amout to a specific reverb return on a per event basis sounds way to heavy on CPU. Is there a common “best practice” for that problem?
I think the main problem for me to wrap my head around, is that “reverb zones” aren’t actual reverb zones which any entity could enter and have their sounds placed in that reverb but are in fact listener dependend.
Thank you in advance for your answer!
All the best,
Joshn’t
They work only for the listener. As you’ve correctly intuited, this is for performance reasons: All event instances being subject to the exact same reverb means that you only need a single instance of the reverb DSP; whereas if each event instance could have different reverb, every event instance would need its own instance of the reverb DSP.
The common best practice is to not do it. As I said above, it’s expensive; while running a handful of reverb effect instances at once won’t break the bank, one instance for each and every event instance in your project would chew through your resource budget painfully fast.
Realistically, a sound should be affected by both the reverb characteristics of the space it originates in, and the reverb characteristics of the space surrounding the listener - the sound travels through both spaces to reach the listener, after all. Its being affected only by the reverb characteristics of the listener 's location is therefore “half-right”: It’s not as realistic as reality, but it’s close enough for most games.
All that being said, a rare few games do require reverb that depends on the event instance’s position rather than the listener’s. If your game is one of those rare few, there is a way to minimize the number of additional reverb effects you’ll need - though it does have downsides: It takes a lot of effort to set up and maintain, and still consumes more resources than the default solution.
Create multiple return buses, one for each unique set of reverb characteristics in your game.
Add a reverb effect to each of those return buses.
To each of your events, add multiple sends, one to each return bus.
Automate the levels of the sends such that you can control them by setting a parameter.
This method allows you to get away with only one reverb effect instance for each unique set of reverb characteristics in your game - which may still be more than your resource budget allows, so be sure to test thoroughly.