Sound

[rich_is_bored]

That's cool and all but I'm simply talking about sound volume. Let's try this again.

 

We know the game currently traces a path from the source of a sound to the player like this...

 

 

Point A would be the source. C would be the player. B is the closest visportal along the path and where the sound would actually be played.

 

The sound playing at B has it's volume reduced because it is closer to the player and must sound as if it is originating from A.

 

Coincidentally, the path is direct and the sound it is pretty accurate.

 

 

Now, here the sound is originating on the other side of a wall. Again the path goes through the "closest" visportal and B is reduced because it must sound as if it's originating at A. There are two problems.

 

Does the game account for a change in direction? Assuming the length of path ABC is constant in both illustrations, wouldn't the indirect path result in a quieter sound? The sound had to bounce off a wall to reach the player. We must assume that some energy was lost in the process. The more acute the angle, the more severe the volume reduction.

 

Additionally, there's a second hole in the wall. Is the game accounting for this path or mearly stopping short at the closest path? Every visportal in the same node as the player should be evaluated to see if there is a valid path leading through to the source. If so, the same process should play out for each.

 

You don't need to cast a hundred rays to work this out. All you need is the path from the source to the player the game already calculates. Then you repeat this process, but looking for the next "shortest" path until every visportal connected to the player's current location has been accounted for. If you have a room with 4 visportals, there would be potentially 4 valid paths.

[grayman]

Wrt sound ...

 

IIRC, the shortest path is taken. I don't remember how much of the alternate path info is kept, or when it's thrown away. Everything might already be there to create multiple speakers with varying sound volumes. I'd have to walk through the code again.

 

As for change in angle, that's not taken into account. It's easy enough to do, but I'd have to determine the amount of angular occlusion empirically, unless i can find some math on the web that describes how much energy you lose when bouncing (which seems mainly tied to materials encountered, not angles, but since we don't bounce sound rays off materials, we're not going to know what materials are encountered, and will have to assume some energy loss at direction changes).

 

I filed an issue to remind me to look at this.

[SteveL]

Does the game account for a change in direction? Assuming the length of path ABC is constant in both illustrations, wouldn't the indirect path result in a quieter sound? The sound had to bounce off a wall to reach the player. We must assume that some energy was lost in the process. The more acute the angle, the more severe the volume reduction.

 

Additionally, there's a second hole in the wall. Is the game accounting for this path or mearly stopping short at the closest path? Every visportal in the same node as the player should be evaluated to see if there is a valid path leading through to the source. If so, the same process should play out for each.

 

You don't need to cast a hundred rays to work this out. All you need is the path from the source to the player the game already calculates. Then you repeat this process, but looking for the next "shortest" path until every visportal connected to the player's current location has been accounted for. If you have a room with 4 visportals, there would be potentially 4 valid paths.

The game already sums adjusted contributions from all possible paths, and adjust both the volume and apparent source of the sound. I fixed a bug in the calculation a few months ago, that was causing sound cards to pop when multiple paths happened to align.

 

As for change of direction, I think we fake it through sound loss on the portal.

[stumpy]

sound propagation works in tdm if you poke the info_locationseparator entities through the visportals you want/don't want the sound to propergate through. and changing the settings on them.

Edited September 18, 2015 by stumpy

[HMart]

sound propagation works in tdm if you poke the info_locationseparator entities through the visportals you want/don't want the sound to propergate through. and changing the settings on them.

 

Isn't that based on the removed EAX code tho?

[grayman]

IIRC, the shortest path is taken. I don't remember how much of the alternate path info is kept, or when it's thrown away. Everything might already be there to create multiple speakers with varying sound volumes. I'd have to walk through the code again.

 

 

As SteveL said, when there are multiple sound paths to the player, the virtual speaker origins on the visportals and their virtual volumes are averaged into a single speaker and volume. The only adjustment to try, then, is whether this sounds different than having each of the virtual speakers play the sound simultaneously at their virtual volumes.

[grayman]

 

Isn't that based on the removed EAX code tho?

 

No.

[Bikerdude]

sound propagation works in tdm if you poke the info_locationseparator entities through the visportals you want/don't want the sound to propergate through. and changing the settings on them.

Yup, "sound_loss" "-10" I also recomend appying the "s_maxdistance" "10" to all Ai as all to frequently I can hear Ai footsteps and idle chatter where Ishoundnt be able to, the same thing could be done and said of doors.

[Springheel]

Yup, "sound_loss" "-10" I also recomend appying the "s_maxdistance" "10" to all Ai as all to frequently I can hear Ai footsteps and idle chatter where Ishoundnt be able to,

 

 

If you can hear AI where you shouldn't, that's likely the fault of sloppy visportals or internal leaks. Setting a max distance to 10 would be way too short--you'd be unable to hear AI that are in the same room you are.

 

Putting sound_loss -10 on regular visportals is also quite extreme--don't doors default to -10?

[grayman]

Yup, "sound_loss" "-10" I also recomend appying the "s_maxdistance" "10" to all Ai as all to frequently I can hear Ai footsteps and idle chatter where Ishoundnt be able to, the same thing could be done and said of doors.

 

... applying the "s_maxdistance" "10" to all AI?

 

AI don't have an s_maxdistance spawnarg.

 

Did you mean something else?

[grayman]

Putting sound_loss -10 on regular visportals is also quite extreme--don't doors default to -10?

 

Yes, closed doors default to a loss of 10.

[Springheel]

 

... applying the "s_maxdistance" "10" to all AI?

 

AI don't have an s_maxdistance spawnarg.

 

Did you mean something else?

 

 

I assume he meant to the footstep and bark soundshaders, which currently have a maxdistance of 30.

[Bikerdude]

I assume he meant to the footstep and bark soundshaders, which currently have a maxdistance of 30.

Yes, maxdistance of 30 is far to big IMHO.

[Bikerdude]

1. If you can hear AI where you shouldn't, that's likely the fault of sloppy visportals or internal leaks.
2. Setting a max distance to 10 would be way too short--you'd be unable to hear AI that are in the same room you are.
3. Putting sound_loss -10 on regular visportals is also quite extreme--don't doors default to -10?

1. not true, lots of maps Ive played with 2.02 and above and sounds propagate too far IMHO.
2. True, so base that figure on the largest room in the mission. That said in RL, surely when a room is big enough and the Ai far enough distance you wont hear them?
3. Dont know, I have had to put 10 on all the doors in chalice because I was able to hear AI upstairs when clearly I shouldnt have been able too.

Anyway, I think we are getting a bit of topic - feel free to move this part of the thread etc.

[Springheel]

• not true, lots of maps Ive played with 2.02 and above and sounds propagate too far IMHO.
• True, so base that figure on the largest room in the mission. That said in RL, surely when a room is big enough and the Ai far enough distance you wont hear them?
• Dont know, I have had to put 10 on all the doors in chalice because I was able to hear AI upstairs when clearly I shouldnt have been able too.

Anyway, I think we are getting a bit of topic - feel free to move this part of the thread etc.

 

2. You can't change maxdistance on a mission by mission basis...that value has to say consistent. We did do quite a lot of testing to decide on the 30 value. If you lower that value, then AI will be able to hear you before you can hear them, which would have a significant gameplay impact.

 

There certainly are places in maps where sound goes where it shouldn't, but this is mostly because we don't have anything to simulate sound bouncing and being absorbed by surfaces, other than manually adding sound_loss to visportals. In my experience mappers aren't using this very often.

[Bikerdude]

other than manually adding sound_loss to visportals. In my experience mappers aren't using this very often.

What the best way to do this? place an 'info_locationseporator' on the VP and add the sound_loss arg to the 'info_locationseporator'..?

[grayman]

What the best way to do this? place an 'info_locationseporator' on the VP and add the sound_loss arg to the 'info_locationseporator'..?

 

You can do that to the existing info_locationseparators, but if you don't want to mark a new location boundary, use info _portalSettings.

[Springheel]

The most important place to use this, IMO, is on small visportals that should only let through a bit of sound, and horizontal visportals to block off sound between floors. But values higher than -3 will cause a noticable drop when the player walks through it, so it's better to have two portals with -2 each than one with -4.

[grayman]

So if I experiment with sound loss due to direction changes through portals, isn't that going to screw up the current distance values which we've put a lot of work into?

[Springheel]

I can't really say...I'm not completely clear on the direction change concept.

[grayman]

As for change of direction, I think we fake it through sound loss on the portal.

 

Only if the mapper has placed an info_locationSeparator or info_portalSettings entity on the portal and set sound loss values. Otherwise there's no sound loss through (non-door) portals.

[grayman]

I can't really say...I'm not completely clear on the direction change concept.

 

I think the idea is that if a sound wave changes direction, it only does so because it has bounced off a wall or ceiling. Since we use portals to control the flow of the sound wave, if a direction change occurs at a portal, there's an opportunity to soften the sound at that point, to simulate this bounce. This is independent of any occlusion settings on info_portalSettings or info_locationSeparator entities sitting on the portal.

[Springheel]

That makes sense. We'd have to test it obviously, but I don't think that would likely mess things up...it's likely to help in the cases Biker is talking about.

[Bikerdude]

but if you don't want to mark a new location boundary, use info _portalSettings.

Ah yes I forgot about those.

[grayman]

On the topic of replacing a single virtual spatialized sound emitter with multiple spatialized emitters at each opening in a room where a listener is standing ...

 

... this isn't something that will be done in the near future (at least by me).

 

The player sound design is based on an emitter being told where to spatially place its origin and set its volume to simulate what the player would hear. The code is set up to provide a single spatial origin and volume.

 

In order to provide multiple dynamic spatial emitters, a lot of information that's currently discarded will need to be kept to finally determine where to place the extra emitters and what volumes they should play their sounds. Since the player is moving around the environment, these emitters will need to be created and destroyed per frame, and where they are in the sound wave synced with the original emitter.

 

I'm not sure it's worth the effort to do this, even to find out whether--in the end--it sounds any different than what we have now.