Sound

[grayman]

Looking at the code, it seems the current formula uses a linear intepolation between 0 and s_diffractionMax. Shouldn't that be some sin() or cos()? It probably does not make much of a difference in praxis, tho.

If you can find me an equation for average diffraction through openings, I'll use it. I couldn't find one, and there are so many variables (angle, frequency, material, air density, etc.) that I opted for something simple.

 

One more question: Does the code take into account the direction the speaker/AI is facing? E.g. is an AI facing away from the player less loud than one facing the player? Or does the code simple take the full volume for the first leg in all cases?

Full volume on the first leg. Low frequencies are prolly going to maintain their volume, and high frequencies are only disturbed if they go through the head. The waves bounce off the surfaces in front of the AI also, and reflect back to the player, but we don't take reflection into account anywhere. I don't think there's any benefit in trying to tweak this.

[grayman]

Note that a 6dB reduction is around a 50% change in amplitude, but decreases the power (which is what we perceive) by a factor of four. So I suggest starting with a very conservative value (2 or 3 dB) and increasing only if necessary.

So instead of 10, I should be using 2 or 3?

 

I'd like to hear if people can perceive any difference with the current setting of 10. (That's a loss of 10 in 180 degrees, or 5 around the typical corner of 90 degrees.)

[Springheel]

I have a 5.1 speaker setup. When I run TDS, I can tell exactly what direction a guard is with my eyes closed. In TDM, I cannot. For whatever reason, it is harder to tell which speaker the sound is coming from. I don't think that has anything to do with how much sound is lost during bounces. It's not a volume issue, it's a direction issue, at least in that circumstance.

[grayman]

I have a 5.1 speaker setup. When I run TDS, I can tell exactly what direction a guard is with my eyes closed. In TDM, I cannot. For whatever reason, it is harder to tell which speaker the sound is coming from. I don't think that has anything to do with how much sound is lost during bounces. It's not a volume issue, it's a direction issue, at least in that circumstance.

That might be a bug in how TDM handles 5.1 sound. It should be adjusting the sound on all 5 speakers accordingly. I know it's fine for me with just 3 speakers or headphones.

[Springheel]

I'd like to hear if people can perceive any difference with the current setting of 10. (That's a loss of 10 in 180 degrees, or 5 around the typical corner of 90 degrees.)

 

 

I tested it in Chalice this morning on the default value. Sometimes it appeared to have no affect at all (though it's hard to know exactly where the visportals are while playing), but in other places it was definitely too strong. I took two steps through an open door, and the footsteps in the hall I just came from were suddenly cut off.

 

I turned the ambient sound off to test, but this could also have a negative impact on ambient sounds that aren't using the location system, couldn't it?

[Springheel]

That might be a bug in how TDM handles 5.1 sound.

 

 

That may be what the latest video was complaining about. In Thief it's easy to pinpoint the direction a guard is coming from with 5.1, and TDM it isn't.

[grayman]

I turned the ambient sound off to test, but this could also have a negative impact on ambient sounds that aren't using the location system, couldn't it?

Sure. Ambients coming from speakers are subject to the same rules as other sounds. The only difference is that stereo sounds might lose volume, but you can't pinpoint a direction. Mono sounds will lose volume and you can tell where they're coming from.

[OrbWeaver]

10dB does seem rather excessive to me (it's a 90% reduction in power), although obviously actual in-game testing has to take precedence over speculations from my armchair.

 

We should remember though that there is already going to be noticeable attenuation just from the existing distance calculations, which (I presume) the additional per-portal reduction is going to stack with. This might give rise to the behaviour Springheel reports whereby moving through a door results in a massive sound cut-off. This is why I suggest being cautious with the flat per-portal attenuation, especially if mappers may already have carefully optimised the sound propagation in their maps.

[Bikerdude]

I have a 5.1 speaker setup. When I run TDS, I can tell exactly what direction a guard is with my eyes closed. In TDM, I cannot.

T1/T2 mission suffer from this also, but I don't know if its because authors aren't implementing EAX that the darkengine supports or something else. Either way it would be a very good first step for use if TDM could atleast have this function.

Mono sounds will lose volume and you can tell where they're coming from.

Its why on a buncgh of my mission I have had to change sounds coming from objects to mono so I can pinpoint directly as I spin the player around etc.

[Springheel]

Its why on a buncgh of my mission I have had to change sounds coming from objects to mono so I can pinpoint directly as I spin the player around etc.

 

 

All sounds should be mono by default (though not all of them are). You can add the "omni" spawnarg if you don't want the direction determined. Or pump up the mindistance.

[grayman]

We should remember though that there is already going to be noticeable attenuation just from the existing distance calculations, which (I presume) the additional per-portal reduction is going to stack with. This might give rise to the behaviour Springheel reports whereby moving through a door results in a massive sound cut-off. This is why I suggest being cautious with the flat per-portal attenuation, especially if mappers may already have carefully optimised the sound propagation in their maps.

Sound occlusion only occurs across portals if:

 

1 - the portal goes through a door and the door has sound loss settings

 

2 - the portal has an info_locationSeparator or info_locationSettings entity on it that defines sound loss settings

 

Apart from those mapper-controlled settings, there is no sound loss simply for walking through a portal.

 

That having been said, the experiment here is to add this:

 

3 - the sound wave travels around a corner at a portal and suffers some occlusion based on the angle of diffraction

[OrbWeaver]

That having been said, the experiment here is to add this:

 

3 - the sound wave travels around a corner at a portal and suffers some occlusion based on the angle of diffraction

 

Right, that's what I'm referring to (perhaps "per-portal reduction" wasn't the best choice of description).

 

My point is that if the new diffraction-based reduction is stacking with the existing reduction from the increased distance (which should be quadratic, if the engine is simulating it anywhere near realistically) we need to be careful about overdoing it and ending up with unrealistic-sounding cutoffs as players move around geometry.

 

Perhaps it is the size of the opening (rather than the angle) that needs to be taken into account. Is it possible that the current implementation is optimised around normal-sized corridors and doorways, and therefore players are experiencing unexpectedly loud sounds from rooms which are only accessible through a small window or grating? Rather than just moving the "virtual speaker" along the propagation path and reducing for distance, perhaps the volume needs to be reduced by an amount proportional to the surface area of each portal it passes through.

[grayman]

Perhaps it is the size of the opening (rather than the angle) that needs to be taken into account. Is it possible that the current implementation is optimised around normal-sized corridors and doorways, and therefore players are experiencing unexpectedly loud sounds from rooms which are only accessible through a small window or grating? Rather than just moving the "virtual speaker" along the propagation path and reducing for distance, perhaps the volume needs to be reduced by an amount proportional to the surface area of each portal it passes through.

 

The code doesn't use portal size. While door/window portals are pretty close to the opening size, they can also be way out of proportion to the geometry they're embedded in. Especially outside, where we extend portals up to a sky ceiling or have heavy use of func_static geometry layered on top of basic worldspawn geometry.

 

And size is more of a factor when trying to determine which frequencies are going to be affected as the wave passes through the opening. And we have no frequency information available to us.

[Springheel]

I tried a value of 3, and it seemed pleasing on a small test. When I stepped back and forth through a door into a hallway of searching AI, the voices became slightly muffled, which sounded believable.

[demagogue]

I have to say I'm impressed with us as always. Here's a critic that didn't bother to hide his ambivalence with the game, threw out some criticisms that even if they were fixed probably wouldn't make him like it any better, but we work on the issue anyway ... not even to make him happy, but because it makes the game better. (Granted sound is more important for our genre than others.)

 

No one can ever say we don't listen to our audience. I'm in a jaded mood about so many things these days (re: corporate-consumer relationship), but doesn't this give you a little faith in humanity? Maybe I'm reading too much into this, but I think it's kind of cool we're like this.

[Springheel]

No one can ever say we don't listen to our audience.

 

 

Someone was saying exactly that not long ago.

[Springheel]

These changes only apply to what the player hears.

 

Should I also apply them to what the AI hear?

 

 

After thinking about this further, I think this should apply to the AI hearing as well.

 

1. In terms of realism, the player's sound wouldn't bounce any differently than the AI's sound.

2. In terms of gameplay, the player uses what they hear as a rough estimate for how much the AI can hear. If the player is two corners away from an AI, the AI will sound further away, so the player will rightly assume the AI can't hear him as well. If the changes don't apply to the AI, the player is getting false information.

[grayman]

Okay, I'll go back to that after I'm done fiddling with the searching algorithm.

[Tels]

If you can find me an equation for average diffraction through openings, I'll use it. I couldn't find one, and there are so many variables (angle, frequency, material, air density, etc.) that I opted for something simple.

 

Full volume on the first leg. Low frequencies are prolly going to maintain their volume, and high frequencies are only disturbed if they go through the head. The waves bounce off the surfaces in front of the AI also, and reflect back to the player, but we don't take reflection into account anywhere. I don't think there's any benefit in trying to tweak this.

 

First point: This wasn't a request, a sin() looks very close to a linear equation, and both are only approximations, anyway. I was just noting it and wondering if you couldn't simplify the equation in the function somehow.

 

Second point: My RL practical experience seems to disagree with you (and your formula used for damping the sound when the angle is bent, too

 

People are (sometimes a lot) harder to understand if they talk away from you - especially in loud environments. Also, not always is there a wall rightin front of the speaker. It's a bit like light - sure, it eventually bounces back to you, but a spot light shining away from you has a lot less power compared to shining in your face (unless you stand in front of a mirror, of course

 

Sure, we can't simluate the full frequency, but making things a bit less loud would already improve the impression IMHO.

 

Plus, you formula penalizes sound that goes through a, say, 90° angle. But if the AI speaks aways from a door, it is as loud as if it speeks directly through the same door. Compare this to the AI speaking at 90° to the door and it is suddenly less loud than the two other cases. Ideally, it would be dampened at 90° and even more at 180°, regardless on wether it is behind a visportal, or not. Otherwise, the player would also hear a difference between being right in front and right behind the visportal in the 90° case. (if player & AI in the same leaf => no sound reduction, if player steps through portal, suddenly the 90° are taken into account).

 

So I'd say it would only be consistent if the first leg takes the angle into account, too. And that might improve localisation of AI a step.

 

(I can do some drawings to illustrate my point, in case the descriptions above are not clear enough).

[Paralytik]

Being an audio nerd, I really enjoy the things discussed in this thread and how they are discussed. If you ask me, anything that can improve how audio is handled ingame is a big step forward for the project. In my head, this whole genre is very dependent on audio and how it is processed by the engine and presented to the player.

 

I understand your concern about the risk of breaking old maps, but if you make changes that makes them easier, I'd say that's better than making them unplayable. Of course it is unfortunate if that ruins some maps in terms of difficulty, but they would still be playable in the sense that your progress is not halted by over-attentive AI.

And about the fear of mappers not using newer audio functions, I don't see how that could be a big concern. Mappers might choose or not choose to use any of the features, always. It's up to the mappers. Though if you make the audio handling more interesting and add proper documentation and perhaps a few tutorial examples, my guess is that more mappers will feel invited to use the new tools provided.

I'm mostly lurking these forums and read a lot, so these are just thoughts and some addition to the discussion. I look forward to follow the future progress of this.