REVERBS: Increasing the usability of sound environments

[Caligari87]

This isn't so much a "feature suggestion" as a general inquiry about the possibility of various tweaks to the sound environment feature.

I realized a big blocker (for me anyways) of using the sound environments is the harsh transition between environments and how it instantly affects every playing sound. It's very unpleasant. To that end, I wonder if any of the following could feasibly ever be implemented:

• Not changing the environment of a currently playing sound on a transition, only new sounds started after the transition.
• Sounds playing in different environments based on the position of the actor making the sound.
• Blending smoothly between environments when entering a new one (time? distance from transition point? Blended over the length of a looping sound?).

There may be other possibilities but those are the major variants I can think of at the moment. I think if nothing else, the first and/or second (ideally both) would solve a lot of problems with the harshness of environment transitions.

Of course all this hinges on a single issue, whether multiple sound environments could be active at once and applied to separate sounds, which is kind of the core of the question here. Is there any way to implement any of these with some adjustment to the current sound system? Or would it basically require rebuilding everything?

---

Of course the pie-in-the-sky option would be enabling control of the reverb environment parameters directly in ZScript but I imagine that has a less than zero chance of happening.

[Enjay]

All of those would be great to have. I really like the sound environments feature and find that it really adds to a map, but the problems that you list do detract from it. I'm going to guess that they are far from simple things to address.

One I would also like to add to the (impossible?) list is the ability to restrict them by height or below/above 3D floors. You have no idea of the scripted shenanigans I had to go through to get the reverbs working in a map where there was a sewer running under a street and a contained ducting gantry running over that - all three with different sound environments and all three with several access points. And, yes, a rethink of the map probably would have been a better option but I was being stubborn.

[Chris]

• Not changing the environment of a currently playing sound on a transition, only new sounds started after the transition.
• Sounds playing in different environments based on the position of the actor making the sound.
• Blending smoothly between environments when entering a new one (time? distance from transition point? Blended over the length of a looping sound?).

OpenAL Soft automatically blends between environments when the parameters change, although it does so very quickly (over a 10~20ms period, typically) to avoid much latency. Theoretically GZDoom can interpolate the environment changes more slowly over time, though who knows how much time would be appropriate. Or alternatively, interpolate environments depending on how close you are to the line between the two.

Honestly, what I'd love to see/hear is multi-environment modeling, something that's been available since EAX3 or 4 (EFX was designed with the capability in mind, and it's been possible with OpenAL Soft for a good while, even though no one seems to use it). Rather than just setting the reverb for the environment the player is currently in, it has that in addition to 1, 2, or 3 other closest environments near the player. So if you're standing in an outside area next to a warehouse's open door, and a cave or tunnel on the other side, you mainly hear the outside environment, with an echoing warehouse on the one side and an echoing cave/tunnel on the other. As the player moves around, the positioning of those environments changes, and as you get closer to one, it envelops around you more. When you move into it, it seamlessly shifts to being the main one, and the one you were just in pans off in its direction.

However, for that to work, there needs to be a way to define where two environments meet, so you know where the other nearby environments are, and the size of the opening to those environments (a small peephole, or a large open door). The engine doesn't currently track that kind of info, at least in a way that the sound backend can make use of, and I'm unfortunately not familiar enough with the engine internals to try and derive that information.

The environments could also be made more dynamic in general, by tracking the environment extents/"walls" and adjusting the general direction and timing of the primary and secondary reflections, so it sounds different when you're in the middle of a room compared to near a wall.

[Caligari87]

As much as I'd love to have proper environmental modelling based on wall shapes and such, I imagine that's not going to happen anytime soon! Hence why I want to try and brainstorm ideas that can work within the current implementation of sound environments.

It's good to know there's already some interpolation! That means the core assumption of my suggestion is valid (blended environments can be "understood" by the sound system). It's just too fast to really be perceptible.

However, for that to work, there needs to be a way to define where two environments meet, so you know where the other nearby environments are, and the size of the opening to those environments (a small peephole, or a large open door). The engine doesn't currently track that kind of info, at least in a way that the sound backend can make use of, and I'm unfortunately not familiar enough with the engine internals to try and derive that information.

If the wiki page is to be believed, the engine does seem able to define environment zones with the zoneboundary UDMF line flag. In fact it's required to make multiple environments work at all, so a mapper using environments would already be providing this information. Perhaps some additional UDMF property would be able to define the blend distance for a given boundary line or even estimate it based on the length of the line?

As far as the user experience goes, I still think that applying different environments to sounds based on position or whether a sound is already playing would be great to have though. This would help support situations where the environment is applied by scripting rather than map-placed things (such as shooting line traces to calculate the size of the room the player is in), which would make it possible for reverbs to be applied to maps that don't have zones defined.

For example, a mod could let the user decide to use the "Spacestation" reverb set, and then swap between "Spacestation Small Room" and "Spacestation Large Room" (or other presets) based on how tall the ceiling is and the player's average distance to any nearby walls. With the current ultra-fast interpolation and the fact that it affects already-playing sounds, this would be really jarring for the player (such as long gunshot tails getting instantly cut-off by the change). But if the environment change can be only applied to new sounds played after the change (or have sounds use the environment they started playing in), it wouldn't be nearly as bad.

[Chris]

If the wiki page is to be believed, the engine does seem able to define environment zones with the zoneboundary UDMF line flag. In fact it's required to make multiple environments work at all, so a mapper using environments would already be providing this information. Perhaps some additional UDMF property would be able to define the blend distance for a given boundary line or even estimate it based on the length of the line?

There's an issue when you have multiple lines as the border between the same two environments. Perhaps making weird shapes. Something like

Code: Select all

|            Env 1          |
|                           |
|___     ___     ___     ___|   
|   |   |   | . |   |   |   |
|   |___|   |___|   |___|   |
|                           |
|            Env 2          |

A listener at the location of the . should be roughly 50/50 balanced between the two environments, even though it's in Env 1 near three borders to Env 2. Regardless, even just traversing the linedefs that make up the edges of the current environment and finding which have a different environment on the other side (vs no environment, or no space at all), in an efficient way, is beyond my knowledge of the engine.

As far as the user experience goes, I still think that applying different environments to sounds based on position or whether a sound is already playing would be great to have though.

This is basically what you get with multiple environments and exclusion filtering. It would be too expensive for each sound to have its own unique reverb, so you instead just have the most important 2, 3, or 4 reverbs, and a sound defines how much it contributes to each at any given time. Normally this would be done based on physics (how much of a sound's energy reaches the given environment), but you can use whatever criteria you want. But whichever way it would work, there would need to be consideration for whether desirable future changes to the logic could break assumptions mods might come to rely on in the mean time.

For example, a mod could let the user decide to use the "Spacestation" reverb set, and then swap between "Spacestation Small Room" and "Spacestation Large Room" (or other presets) based on how tall the ceiling is and the player's average distance to any nearby walls.

Or it could modify the delay times and decay rates of the environment. But this gets into a pertinent issue... how much control should scripts be given, so as to avoid spilling too many implementation details, and how much should the engine manage itself, so modders don't have to be a scripting, math, and physics wizard (or copy verbatim someone else's undecipherable scripts to their own mod) to get good environmental reverb... and so updates to the engine's sound environment modeling can potentially improve preexisting mods.

With the current ultra-fast interpolation and the fact that it affects already-playing sounds, this would be really jarring for the player (such as long gunshot tails getting instantly cut-off by the change).

The opposite could also be an issue. A long gunshot tail (and/or looping sounds) start while you're in a large echoy hall, then you run (or get teleported) out into the outdoor fields, it would be disconcerting to hear sounds as if you were still in an echoy building rather than the much more echo-less outdoors. You do need to make sure sounds stay updated with whatever environments are in use, it's a question of how to manage the transitions.

[Caligari87]

Yeah, that's all true and I don't have much else to say for most of it I guess. The main reason I suggested "let a sound continue playing in the same reverb environment it started in", is because I figure that'll be the least invasive way to improve the existing reverb system (without all the complicated issue above) since most sounds in Doom are pretty short and the player is more likely to notice a sharp change in an existing reverb tail (as happens now). If there's a better way to implement this, great, but it sounds like most of the other options would require significant infrastructure work.

Or it could modify the delay times and decay rates of the environment. But this gets into a pertinent issue... how much control should scripts be given, so as to avoid spilling too many implementation details, and how much should the engine manage itself, so modders don't have to be a scripting, math, and physics wizard (or copy verbatim someone else's undecipherable scripts to their own mod) to get good environmental reverb... and so updates to the engine's sound environment modeling can potentially improve preexisting mods.

I mean, modders already have access to modifying every aspect of the reverb via the [wiki]REVERBS[/wiki] lump. It's just typically not worth it because A) there's already a zillion presets, and B) it's static and can't be changed to reflect shifting ingame conditions.

If nothing else, allowing script access to tune the existing reverb parameters on-the-fly would be a massive paradigm shift in terms of freedom and usability. Plus I feel it would be relatively future-proof as the existing parameters are extremely comprehensive, have existed for 15+ years unchanged already, and future engine improvements would likely lean on leveraging those same parameters in an automatic fashion instead of re-inventing the wheel. Modders can already adjust map gravity via scripting for example, and that doesn't change if GZDoom implements a more realistic default gravity calculation, or whatever.