GZDoom 3.7.2. Reverb issue

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.

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is OFF
Smilies are ON

Topic review
   

Expand view Topic review: GZDoom 3.7.2. Reverb issue

Re: GZDoom 3.7.2. Reverb issue

by cortlong50 » Wed Feb 06, 2019 3:01 am

Chris wrote:
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.
Hey Chris, as someone who spends a shitload of time dialing in all my ambient sounds (too much time...i spend entirely too much time making sure theyre good) the bleeding actually isnt that big of an issue. in fact the computing power (and dev time) it would take to calculate all of that would probably not be worth it. as it sat back in the older versions the reverbs were quite kick ass. i never had an issue with hearing a noise through walls or felt like it was odd. it worked perfectly.
Enjay wrote:

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...
im kinda with enjay on this one (if it matters what i say...also his english spelling is melting my brain...mericuh). I think getting things to a more precise standard is important, but i dont know if its worth breaking previous maps that use reverbs which would basically be all of them ever created besides the most recent ones. a togglable (how the hell do you spell that?) option (when placing the reverbs) would be pretty cool, but i think a default to the original standard would be ideal, for backwards compatibility sake. if it were something to toggle in the options menu...well....to be honest opening the options from 2.7 vs 3.7 i was like "holy hell". quite honestly the menu is getting pretty dense...theres a lot of stuff in there.

a standard is important to keep, but a difference between 1 and 32 would be quite jolting. if it were a smaller difference id say do it...but thats pretty substantial and could cause decay far faster and sound weird.

just my two cents.

i was reading over the code...was it set to 32 or 1? (sorry the
// units per meter scale (32?), and set the meters per unit to the scale's
// units per meter scale (1), and set the meters per unit to the scale's -- section had me confused).

and when will be see it implemented? no rush, just wondering.

Re: GZDoom 3.7.2. Reverb issue

by Enjay » Tue Feb 05, 2019 3:58 pm

_mental_ wrote:The sample is in this topic and it seems to be your map ;)
Thanks. I'm pretty sure that's actually a modified version of my file. All the talk of "heard distance" was confusing me because I didn't even know that "heard distance" was a modifiable thing property (I don't often edit in UDMF). Which is why I was confused as to what needed to be done to get the effect. However, even resetting the heard distance in that file back to default in GZDB, the sound can still be heard on the reverby side until it suddenly cuts off when you reach the vine texture versus the slow fadeout on the standard reverb side. Of course, that's precisely what the map was set up to display but the altered heard distance makes it even more obvious.


I guess the question now is how will this file behave with the fix? For me the problem was less that the sound was loud everywhere (although that very much is a problem), but that it would suddenly cut in/out when reaching the boundary of the sound if the sound was heard in a reverby environment. Will it now fade with distance like it does in less reverby environments? Will the distance that it takes to fade be altered by the new calculation?

Re: GZDoom 3.7.2. Reverb issue

by _mental_ » Tue Feb 05, 2019 5: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.

Re: GZDoom 3.7.2. Reverb issue

by Chris » Tue Feb 05, 2019 3: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.

Re: GZDoom 3.7.2. Reverb issue

by _mental_ » Tue Feb 05, 2019 3:12 am

The sample is in this topic and it seems to be your map ;)

Re: GZDoom 3.7.2. Reverb issue

by Enjay » Tue Feb 05, 2019 3: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...

Re: GZDoom 3.7.2. Reverb issue

by Rachael » Mon Feb 04, 2019 11:01 pm

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

by Chris » Mon Feb 04, 2019 10: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.

Re: GZDoom 3.7.2. Reverb issue

by _mental_ » Mon Feb 04, 2019 2: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.

Re: GZDoom 3.7.2. Reverb issue

by Xaser » Mon Feb 04, 2019 11:35 am

_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

Re: GZDoom 3.7.2. Reverb issue

by Rachael » Mon Feb 04, 2019 10: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.

Re: GZDoom 3.7.2. Reverb issue

by Chris » Mon Feb 04, 2019 10: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.

Re: GZDoom 3.7.2. Reverb issue

by Guest » Mon Feb 04, 2019 10: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

Re: GZDoom 3.7.2. Reverb issue

by _mental_ » Mon Feb 04, 2019 9: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.

Re: GZDoom 3.7.2. Reverb issue

by Xaser » Mon Feb 04, 2019 9: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.

Top