Caligari87 wrote: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.
Caligari87 wrote: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.
Caligari87 wrote: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.
Caligari87 wrote: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.