GZDoom 3.7.2. Reverb issue
Moderator: GZDoom Developers
Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
- cortlong50
- Posts: 753
- Joined: Mon Jun 24, 2013 7:12 pm
- Location: UT-WA
Re: GZDoom 3.7.2. Reverb issue
let me know if there is anything else i can do to help.
- Chris
- Posts: 2940
- Joined: Thu Jul 17, 2003 12:07 am
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
Re: GZDoom 3.7.2. Reverb issue
Hmm, I think I made a mistake in my thinking, then. In either case, what it's doing now is logically correct with the presumption that there's 32 units per meter (which is roughly the case given Doomguy being around average height)._mental_ wrote:With the mentioned commit the version of OpenAL-Soft seems to have no effect and the issue still persists.
If you want to restore the old behavior, you can set the defaults (343.3 for speed of sound, 1.0 for meters per unit). If you want to make the unit scale configurable/moddable, though, it would be a bit odd to have the default be 1 meter per unit. So I'm not sure what you'd want to do about that.
Re: GZDoom 3.7.2. Reverb issue
Square suffers from this pretty badly. We built all of E2 with the old values, then an update hit that made the lavafalls in all the moon levels sound like an earthquake.
An alternative route, I suppose, would be to compat-option a default of 1.0 and apply it to maps that suffer from this, but only if there's also a quick and easy upgrade path for those of us that are already using the old values -- e.g. make the aforementioned values customizable.
Making these values configurable is a good idea, that way folks can opt in to a sensible default going forward, but this really ought to be changed back. As it stands, the change has broken pretty much any map that uses reverb, I'd wager.Chris wrote:If you want to restore the old behavior, you can set the defaults (343.3 for speed of sound, 1.0 for meters per unit). If you want to make the unit scale configurable/moddable, though, it would be a bit odd to have the default be 1 meter per unit. So I'm not sure what you'd want to do about that.
An alternative route, I suppose, would be to compat-option a default of 1.0 and apply it to maps that suffer from this, but only if there's also a quick and easy upgrade path for those of us that are already using the old values -- e.g. make the aforementioned values customizable.
Re: GZDoom 3.7.2. Reverb issue
The problem is not only in that particular change. OpenAL 1.19.0 and newer causes this issue regardless of its presence.
In other words, to restore old behavior the commit should be reverted AND OpenAL downgraded to 1.18.2 or older.
In other words, to restore old behavior the commit should be reverted AND OpenAL downgraded to 1.18.2 or older.
Could you please tell me the exact location where this is clearly noticeable? I would like to check that if it's the same problem or not.Xaser wrote:Square suffers from this pretty badly. We built all of E2 with the old values, then an update hit that made the lavafalls in all the moon levels sound like an earthquake.
Re: GZDoom 3.7.2. Reverb issue
@ cortlong50
I don't want to interfere with the others. Just because you asked:
https://zdoom.org/wiki/REVERBS
It says:
" RoomRolloffFactor float
Logarithmic distance attenuation rolloff scale factor for reverb room size effect.
"
A value of 1 means no rolloff.
Just try out values between 0.1 and 1.
It can be used for any reverb you create.
Kind regards
zhd
I don't want to interfere with the others. Just because you asked:
https://zdoom.org/wiki/REVERBS
It says:
" RoomRolloffFactor float
Logarithmic distance attenuation rolloff scale factor for reverb room size effect.
"
A value of 1 means no rolloff.
Just try out values between 0.1 and 1.
It can be used for any reverb you create.
Kind regards
zhd
- Chris
- Posts: 2940
- Joined: Thu Jul 17, 2003 12:07 am
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
Re: GZDoom 3.7.2. Reverb issue
I don't mean reverting the commit, I mean changing what's there now to set speed of sound to 343.3 and meters per unit to 1 (the defaults). If you wholly revert that commit the speed of sound will be reverted to 32956.8 (343.3*96.0), which will cause 1.19 to think sound travels much faster when calculating the initial decay._mental_ wrote:The problem is not only in that particular change. OpenAL 1.19.0 and newer causes this issue regardless of its presence.
Actually, 0 is no rolloff. And by default the room rolloff factor is 0 since an initial decay is calculated automatically given the reverb's decay parameters (and the listener's meters per unit and speed of sound parameters) and the source distance. If you set a room rolloff factor, it's applied on top of the initial decay if it's not disabled.Martha Sickleworth wrote:@ cortlong50
I don't want to interfere with the others. Just because you asked:
https://zdoom.org/wiki/REVERBS
It says:
" RoomRolloffFactor float
Logarithmic distance attenuation rolloff scale factor for reverb room size effect.
"
A value of 1 means no rolloff.
Re: GZDoom 3.7.2. Reverb issue
I think the best option would be to make it moddable, to be quite honest. Some maps are not built to Doom's scale, so it may be desirable, in the long run, to allow modders to have even longer falloffs at their discretion.Chris wrote:If you want to make the unit scale configurable/moddable, though, it would be a bit odd to have the default be 1 meter per unit. So I'm not sure what you'd want to do about that.
Re: GZDoom 3.7.2. Reverb issue
The beginning of E2A3 is the most obvious spot. Grab a fishtank and head outside, and your subwoofer will wake the neighbors._mental_ wrote:Could you please tell me the exact location where this is clearly noticeable? I would like to check that if it's the same problem or not.
Re: GZDoom 3.7.2. Reverb issue
OK, I'll give it a try.Chris wrote:I don't mean reverting the commit, I mean changing what's there now to set speed of sound to 343.3 and meters per unit to 1 (the defaults). If you wholly revert that commit the speed of sound will be reverted to 32956.8 (343.3*96.0), which will cause 1.19 to think sound travels much faster when calculating the initial decay.
Thanks, it's quite noticeable indeed.Xaser wrote:The beginning of E2A3 is the most obvious spot. Grab a fishtank and head outside, and your subwoofer will wake the neighbors.
- Chris
- Posts: 2940
- Joined: Thu Jul 17, 2003 12:07 am
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
Re: GZDoom 3.7.2. Reverb issue
In that case, the question is what should be the default. As previously mentioned, Doom uses roughly 32 units per meter given the player size. However, with that as the default, reverb has this issue of being heard farther away than it used to (although it is more accurate behavior, the lack of occlusion/exclusion not withstanding). Using 1 unit per meter restores the old behavior, but it's not representative of the actual unit scale.Rachael wrote:I think the best option would be to make it moddable, to be quite honest.Chris wrote:If you want to make the unit scale configurable/moddable, though, it would be a bit odd to have the default be 1 meter per unit. So I'm not sure what you'd want to do about that.
Re: GZDoom 3.7.2. Reverb issue
I think 32 units per meter is probably best, with the ability to add a compatibility option for older maps. We want people to develop toward an intended standard, not broken ones.
Re: GZDoom 3.7.2. Reverb issue
I'm getting a little lost as to how/under what circumstances this problem manifests. i.e. if I specifically wanted to trigger this problem by creating a map designed to do it, what would I need to do?
Does it occur with any ambient sound that has been placed in an area with a reverb environment or does it only occur for sounds/environments that have had their parameters altered in some way?
If it is the former, I would suggest that a lot of maps will already be "in the wild" and will have been set up to expect the 1 unit = 1 metre value. Defaulting to the more accurate 32 units = 1 metre could therefore potentially break a lot of maps.
However, if it is the latter, fewer maps will be affected. There will probably be some though. Would there be enough to justify making the old formula the default and make the newer, more correct, formula something that is set by a modder?
I realise that defaulting to the inaccurate behaviour is less desirable (as Rachael said), and that defaulting to the old formula would make it less likely that people would specify the new one - but if there are enough maps out there that are going to be broken by this...
Does it occur with any ambient sound that has been placed in an area with a reverb environment or does it only occur for sounds/environments that have had their parameters altered in some way?
If it is the former, I would suggest that a lot of maps will already be "in the wild" and will have been set up to expect the 1 unit = 1 metre value. Defaulting to the more accurate 32 units = 1 metre could therefore potentially break a lot of maps.
However, if it is the latter, fewer maps will be affected. There will probably be some though. Would there be enough to justify making the old formula the default and make the newer, more correct, formula something that is set by a modder?
I realise that defaulting to the inaccurate behaviour is less desirable (as Rachael said), and that defaulting to the old formula would make it less likely that people would specify the new one - but if there are enough maps out there that are going to be broken by this...
Re: GZDoom 3.7.2. Reverb issue
The sample is in this topic and it seems to be your map
- Chris
- Posts: 2940
- Joined: Thu Jul 17, 2003 12:07 am
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
Re: GZDoom 3.7.2. Reverb issue
The problem is most apparent in maps that use a reverb with a long decay, and have sounds left playing in the far distance that aren't supposed to be heard in the current area.Enjay wrote:I'm getting a little lost as to how/under what circumstances this problem manifests.
The more fundamental issue is that sound is treated as if there's no walls. The sound scene is essentially a wide open area using a reverb preset for the player's current position (a sound 2 meter to your left will always sound like it's unobstructed 2 meter to your left, even if the map itself has a thick wall in between you and the sound). It's a similar issue to the way large dynamic lights can "bleed" through walls when they're not shadowmapped. Implementing occlusion/exclusion would go a long way to really fix this issue, but would require a fair amount of work since it needs to do continuous real-time "visibility" checks for sounds to neighboring reverb zones. It's certainly possible, but it's math-heavy stuff that I've not really looked into.
Re: GZDoom 3.7.2. Reverb issue
The issue with reverb fixed in 69492b1 according to Chris' suggestion.
I would like to let someone else to make a feature and/or pull request with moddable speed of sound and unit scale.
I would like to let someone else to make a feature and/or pull request with moddable speed of sound and unit scale.