[Fixed] GZDoom 3.7.2. Reverb issue

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom Developers

Re: GZDoom 3.7.2. Reverb issue

Postby cortlong50 » Mon Feb 04, 2019 3:28 am

let me know if there is anything else i can do to help.
User avatar
cortlong50
editing my comments ad nauseam
 
Joined: 24 Jun 2013
Location: UT-WA

Re: GZDoom 3.7.2. Reverb issue

Postby Chris » Mon Feb 04, 2019 10:01 am

_mental_ wrote:With the mentioned commit the version of OpenAL-Soft seems to have no effect and the issue still persists.

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).

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.
User avatar
Chris
 
Joined: 17 Jul 2003

Re: GZDoom 3.7.2. Reverb issue

Postby Xaser » Mon Feb 04, 2019 10:20 am

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.

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.

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.

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.
User avatar
Xaser
anarchivist
 
 
 
Joined: 20 Jul 2003

Re: GZDoom 3.7.2. Reverb issue

Postby _mental_ » Mon Feb 04, 2019 10:33 am

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.

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.

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.
_mental_
 
 
 
Joined: 07 Aug 2011

Re: GZDoom 3.7.2. Reverb issue

Postby Martha Sickleworth » Mon Feb 04, 2019 11:04 am

@ 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
Martha Sickleworth
 

Re: GZDoom 3.7.2. Reverb issue

Postby Chris » Mon Feb 04, 2019 11:10 am

_mental_ wrote:The problem is not only in that particular change. OpenAL 1.19.0 and newer causes this issue regardless of its presence.

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.

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.

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.
User avatar
Chris
 
Joined: 17 Jul 2003

Re: GZDoom 3.7.2. Reverb issue

Postby Rachael » Mon Feb 04, 2019 11:53 am

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.

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.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle

Re: GZDoom 3.7.2. Reverb issue

Postby Xaser » Mon Feb 04, 2019 12:35 pm

_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.

The beginning of E2A3 is the most obvious spot. Grab a fishtank and head outside, and your subwoofer will wake the neighbors. :P
User avatar
Xaser
anarchivist
 
 
 
Joined: 20 Jul 2003

Re: GZDoom 3.7.2. Reverb issue

Postby _mental_ » Mon Feb 04, 2019 3:28 pm

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.

OK, I'll give it a try.

Xaser wrote:The beginning of E2A3 is the most obvious spot. Grab a fishtank and head outside, and your subwoofer will wake the neighbors. :P

Thanks, it's quite noticeable indeed.
_mental_
 
 
 
Joined: 07 Aug 2011

Re: GZDoom 3.7.2. Reverb issue

Postby Chris » Mon Feb 04, 2019 11:33 pm

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

I think the best option would be to make it moddable, to be quite honest.

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.
User avatar
Chris
 
Joined: 17 Jul 2003

Re: GZDoom 3.7.2. Reverb issue

Postby Rachael » Tue Feb 05, 2019 12:01 am

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.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle

Re: GZDoom 3.7.2. Reverb issue

Postby Enjay » Tue Feb 05, 2019 4:01 am

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...
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Re: GZDoom 3.7.2. Reverb issue

Postby _mental_ » Tue Feb 05, 2019 4:12 am

The sample is in this topic and it seems to be your map ;)
_mental_
 
 
 
Joined: 07 Aug 2011

Re: GZDoom 3.7.2. Reverb issue

Postby Chris » Tue Feb 05, 2019 4:55 am

Enjay wrote:I'm getting a little lost as to how/under what circumstances this problem manifests.

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.

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.
User avatar
Chris
 
Joined: 17 Jul 2003

Re: GZDoom 3.7.2. Reverb issue

Postby _mental_ » Tue Feb 05, 2019 6:17 am

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.
_mental_
 
 
 
Joined: 07 Aug 2011

PreviousNext

Return to Closed Bugs

Who is online

Users browsing this forum: No registered users and 1 guest