Visportal sound propagation limit?

[Octavian]

Hey guys,

 

TL;DR can a sound travel more than 10 visportals?

 

I'm working on a map and visportals aren't working how I would like them to.

 

To illustrate my problem I've made a test map. A speaker with s_maxdistance set to 100, and 11 visportals; embedded in each of those an info_portalsettings with sound_loss set to 0. My problem is that the player, at map start, doesn't hear anything; the visportal closest to him completely blocks sounds.

 

 

So my only possible assumption given the little that I know about DM/DR is that there's a limit to the number of visportals a sound can travel, and that limit is 10.

So then my question is, am I missing something, or doing something wrong, or is this a limitation? And if so, could someone give me an idea for a workaround?

 

To put this problem in a bit of context, think about the "Down In The Bonehoard" mission where you could hear the Horn more or less across the map. I want to make maps where audio plays a key role, in particular for navigation of especially winding, maze-like level geometry.

 

So for example, given a choice of n corridors, walking down some the sound would get louder as those paths are ultimately connected to the source of the sound, while walking down others the sound would get quieter as those paths are ultimately not connected to the source of the sound, which is only coming from "behind", as it were.

 

Of course, new problems and questions would arise. Like how do I carry one particular sound across the map through twists and turns, ups and downs, while having all other sounds behave, i.e. not travel across the map, i.e. get attenuated more by visportals. But, before all this, I have to know, what's with this unexpected 10 visportal sound propagation limit? Help, please.

 

Thanks.

[Springheel]

I'm not aware of there being a 10 visportal limit, although I also can't think of many places where sounds would have to travel through more than 10 portals.

 

The horn in Bonehoard would have been an ambient noise, which is something that can be accomplished in a few different ways in TDM.

[Octavian]

Thanks for the quick reply.

 

Indeed, the Horn would have been done with ambient noise. The problem with ambient however is that, for example in this small example I concocted,

 

 

the sound would be louder at the west corridor relative to the north corridor simply because of proximity. What I want is to have the sound louder at the north corridor since that's directly connected to where the sound comes from. Even in this tiny example the sound has to be bent around through 6 visportals so the 10 limit is, well, extreme when it comes to me wanting to carry a sound across a level.

 

[SteveL]

Yes, apparently, there is a hard limit of 10 portals. I'd not noticed it before either, but it's there in idSoundWorldLocal: MAX_PORTAL_TRACE_DEPTH = 10;

 

It's there to save computational complexity, because the engine traces sounds through every possible branching portal path to the player and adds the various contributions and works out where the sound would appear to be coming from if it arrives at the player at different intensities through different paths.

 

I expect that number was chosen because "that's as many as we'll ever need" rather than through testing.

 

So yes it's a limitation. Do you really need that many portals? In a maze-like map you probably don't need one at every corner because there won't be that much geometry on display. The easiest workaround would be a nice puzzle: place your portals so the the player can't be more than 10 away from the sound If you had to you could link two rooms by a high (inaccessible) tube over the rooms, a bit like an air duct to provide a "bridge" over several portals (best portal the ends of the duct too). But mappers will probably have better ideas.

[Destined]

If I remember correctly, ambient sound can be set for seperate regions in your map (separated by visportals), so it should also be possible to set the volume of your ambient sound for each region seperately. As long as the regions are seperated by visportals (which they are, or you wouldn't have the problem you described), this should work for you.

[demagogue]

This is not like a typical location ambient though.

I think the way to do this is by a script.

 

At the start of the script, you either compute the distance to the horn directly (by doing Pythagorean's formula on the player's & horn's xyz coordinates) or you just get the name of the current location, then the script sets the volume by that value and plays the ambient sound with startSound(...); itself.

 

Note that changing volume works best by decreasing from a baseline (increasing from a baseline is wonky). So it's best to have the native volume be the max volume, and have the script decrease volume from there for the other stages.

 

Edit: The only catch is the sound won't be directional like it would be with a speaker. You can set a speaker to "s_global 1", so it's heard everywhere, but I think then the volume doesn't fall off.

[Octavian]

Thank you all for the quick and comprehensive answers.

TL;DR

Goal : I need to make a sound reach the player by taking the literal route the player would walk to reach it.

Problem : A sound cannot be carried further than 10 visportals.

Most likely solution, and my questions:

1. Is there any possible way for me to override this limit for certain sounds ( this one right here, but none else ).

2. Is there any possible way for me to change that variable, globally. So it affects all sounds.

3. Can I make a visportal attenuate sound based on the distance to the previous visportal ( or sound origin ) so volume depends on overall distance and not on visportal loss?

End TL;DR

And thanks for the ideas. Unfortunately, I don't think any of the proposed solutions would work for my problem.

Wanting to experiment with the concept of audio "beacons" as navigation aids ( or hinderances ) I made this,

into a map, a 3D maze. "/" is a hole to the upper floor, "\" one to the lower floor and "X", both. A sound is playing at the exit in the top left square ( top floor ) and the player starts at the entrance in the bottom square ( first floor ). 3D mazes are great at "compressing space", and there's a lot of it in that cube, 125 cells or "rooms".

My basic thought process and intention was, make this thing, visportal each "hole" leading into every of the 125 rooms, find the furthest room from the source of the sound ( not in a straight line but the longest path you would literally have to "walk" ) and tweak sound_loss across all portals until the sound in that room is barely a whisper.

The effect would then be, if you want to reach the sound, wherever you may be at any particular moment in time, walk in the direction it gets louder. Simple. Crucial however, it works even in a maze so it does take global geometry into account ( as an abstract proof of concept and springboard for designing gameplay around this mechanic, as an added layer of complexity or simply as world detailing ).

Visportals solve, kind of ( not really* ), a problem and that is sound attenuation as a function of distance. An ambient on the top floor can attenuate to the third floor due to distance in a straight line. Say it travels 300 units in a straight line. But with visportals, the path is 3000 units. It twists and turns, loops, because, well, the sound "walks" to you on the same path you'd walk to the sound.

This means, on the top floor for example, in each of the rooms ( except the exit room where the sound source is located ) the sound has a different volume. Because the "walking" distances from each of those rooms to the exit room are ( wildly ) different. All this in a very confined place ( why I figured out this would be the best test ). However, where the player and the sound are in space at any point in time is just part of the issue and I'm afraid the proposed solutions won't do much to solve this particular problem.

Let's look at an example.

This maze has one solution, marked by the black line; the player starts at the top and the exit is at the bottom. Also at the bottom exit I choose to place one of these special sounds. Now, at map start, the black line, the solution to the maze, is also the path the sound must necessarily take to reach the player. At map start there is no other physical path the sound can take to reach the player if it can't go through walls.

The blue player facing north and taking the left corridor will experience a gradual loss in the volume of the sound. Even if he may at times walk towards the sound ( "down" ), with every step he increases the physical distance the sound has to travel to reach him, since it can't travel through walls. So it must get quieter.

Sound pipes is an awesome idea if the paranoid lord has in his mansion a room into which sound pipes route all the sounds from all the other rooms so he can effortlessly eavesdrop on everybody at once. But it would not work for a maze.

Just for argument's sake, you can make this 2D maze into a map ( just the geometry ) in an afternoon, visportals and all. Say there is no portal sound travel limit. Then you're done, it just works. More importantly, if you decide, I'll move this wall here, delete whis wall here, and make another there, you're also done too. If you were to manually zone or script this, not only it would take a ridiculous amount a time, even a small change as removing a wall section would mean you would have to redo all your manual work. This would not happen with visportals as they do the job for you.

And what about doing this with moving sound sources? What if my source moves through the maze, and I move too.

*The problem however is deeper. Even if this limit is to be removed or circumvented visportals don't really solve the problem of sound attenuation. Correct me if I'm wrong but from what I can tell, having two sounds, both as loud, one 10 meters to your left, the other 20 meters to your right, both sound just as loud if each passes through just one visportal to reach you, both with the same sound loss.

This is a problem and I have to tweak the sound loss on one of the portals. But that won't solve anything. If I set the portal that routes the further sound to cut more, I affect all sounds coming from that direction.

But what does s_drawsounds do? It makes a sound source point to a portal. Not its path trough all the portals, just the last one it "walked through". It knows the path through all the portals, i.e. all the "arrows". Sound to first portal, first arrow, first portal to second portal, second arrow, and so on. But instead of showing you all those arrows, the engine tells you I've "walked" "this" sound to the portal I'm pointing at and each time I had to cross a visportal I had to pay a volume toll ( taking into account zero too ).

So, then, is there any possible way to tell the editor to tell the engine, right, this particular sound is a special sound. Its volume isn't tolled when crossing visportals. Instead, add up the length of all the arrows, multiply it with this number, and that's your volume toll. Since it presumably "knows" what those arrows are.

Because sometimes it makes all the sense in the world to cut volume at visportals. Like if they're bound to a door or a window. But, sometimes, it makes the least sense in the world to cut volume at a visportal by X regardless if the previous visportal on its path is 10 meters away or 50 meters away.

Edited February 24, 2016 by Octavian

[grayman]

1. Given your 2D maze example, w/o a limit on the number of visportals through which the sound travels, if the sound is loud enough to travel the entire 'success' path shown, then the sound is loud enough to travel every path through the maze. The sound's propagation is calculated every frame, which may very well bring your map to a grinding halt. The limit of 10 was probably chosen early on using the assumption that in normal maps, a sound wouldn't need to travel farther than 10 portals, and allowing it to do so would reduce performance.

 

2. Portals know nothing about their distance from neighboring portals. If two sounds with the same volume are 10m to the left and 20m to the right and they both sound the same after going through portals with no occlusion control (or the same occlusion control), it's probably because of the way sounds attenuate. When you define a sound, you have two choices to define how far the sound will travel: either in the sound shader or on the speaker emitting the sound. In either case, sound has a min and a max distance. The sound's volume is multiplied by 1.0 while the distance traveled is less than min, and by a fraction from 1.0 to 0.0 based on the distance between min and max. If you want a sound to start losing volume as soon as it leaves the emission point, you need to set the min value to 0. If a sound has the same volume at 10m as it does at 20m, then the min for that sound is >=20m.

[Octavian]

1. Given your 2D maze example, w/o a limit on the number of visportals through which the sound travels, if the sound is loud enough to travel the entire 'success' path shown, then the sound is loud enough to travel every path through the maze. The sound's propagation is calculated every frame, which may very well bring your map to a grinding halt.

 

You are totally right. It's obvious but I couldn't see it. Thank you so much for pointing out this fatal flaw of my reasoning. Now I can move on knowing that, if there is way to do what I want to do, this is definitely not it.

 

Thanks for the explanation about the portals and sound attenuation. I'll put it to good use.

[demagogue]

Now my intuition for this would be to just use a bunch of local speakers with only one at a time directing you in the right direction down any path, with a simple location script activating the right speaker at any given place. Annoying, but easier to micromanage at each stage.

[Destined]

1. Given your 2D maze example, w/o a limit on the number of visportals through which the sound travels, if the sound is loud enough to travel the entire 'success' path shown, then the sound is loud enough to travel every path through the maze.

 

But this is only true if the success path is the longest distance from the speaker. If there is a way (into a dead end), that puts more distance (or visportals) between you and the goal, the sound would die. So you should not use the number of portals needed for the success path, but the maximum number of portals between you and the source as a fraction to reduce the original sound.

 

Your problem with the same sound reduction from a sound with the same volume but 20 or 10 meters away could be circumvented by introducing visportals in a regular fashion. If you have a visportal every 10 meters, for example, the sound would be reduced every 10 meters and would automatically pass 2 visportals for the 20 meters distance, but only one for the 10 meters distance. In your 3D plan, it would be quite easy to introduce, if all your rooms have a regular size: You put a visportal or a wall on the border of each unit block. That way in corridors, the sound will get louder as you move along the right corridor.

 

Thinking about your setup, I just noticed: If the increase in sound is noticeable with every transition, it might be too easy to follow the right path. With every transition the player would just have to listen, if the sound gets louder, or not. As soon as it gets weaker, he knows, that he is on the wrong path. That way the player notices a stray path as soon as he makes a transition and will not have to follow through into a dead end.

[grayman]

But this is only true if the success path is the longest distance from the speaker. If there is a way (into a dead end), that puts more distance (or visportals) between you and the goal, the sound would die. So you should not use the number of portals needed for the success path, but the maximum number of portals between you and the source as a fraction to reduce the original sound.

A portal doesn't occlude sound, unless it's told to. A portal at a door will use the occlusion settings on the door. A portal touching a location separator or portal settings entity that define occlusion, will use that.

 

If every room in the maze can be reached by the player, then the sound will propagate to every room. Each propagation path will end when:

 

1 - It's reached its maximum distance.

 

2 - It enters a room with no exit portals.

 

3 - It has circled back on itself (entered a room it has previously entered)

 

4 - Accrued occlusion along the path has driven the sound volume to zero.

 

5 - It finds the player.

 

After ALL propagation paths have ended, then those reaching the player provide the basis for a final averaging of volume and perceived location.

 

For reference, see Controlling Sound Loss Across Portals in the wiki.

 

Your problem with the same sound reduction from a sound with the same volume but 20 or 10 meters away could be circumvented by introducing visportals in a regular fashion. If you have a visportal every 10 meters, for example, the sound would be reduced every 10 meters ...

Again, visportals by themselves don't occlude sound.

[Destined]

A portal doesn't occlude sound, unless it's told to. A portal at a door will use the occlusion settings on the door. A portal touching a location separator or portal settings entity that define occlusion, will use that.

 

Ok, did not know that. Anyway, my statement stands, if the occlusion is set for the respective portals.

[SteveL]

But what does s_drawsounds do? It makes a sound source point to a portal. Not its path trough all the portals, just the last one it "walked through". It knows the path through all the portals, i.e. all the "arrows". Sound to first portal, first arrow, first portal to second portal, second arrow, and so on. But instead of showing you all those arrows, the engine tells you I've "walked" "this" sound to the portal I'm pointing at and each time I had to cross a visportal I had to pay a volume toll ( taking into account zero too ).

Not quite. I just took a look in the code, and it turns out s_drawsounds draws an arrow from the sound origin to the perceived location of the sound, after different portal paths have all added their contributions:

 

After ALL propagation paths have ended, then those reaching the player provide the basis for a final averaging of volume and perceived location.

If you have a dominant portal path for the sound (or just one path), then it'll look like the arrow is pointing to that final portal on that path.

 

It doesn't have access to the route that was used. There's no record of any paths kept in fact: it's done by a recursive search of all paths (up to 10 portals deep).

 

That said, there's an AI debug cvar that lets you see when AI hear sounds made by the player, and I'm sure it shows a path taken by the sound. I'll try to track it down and see how it works too.

 

EDIT: I was forgetting, AI have their own sound propagation system for noises made by the player or alarms etc, completely separate from what the player hears. Sounds heard by the player are handled by the engine, but it doesn't provide any facilities to let AI hear sounds, so TDM has its own system for that.

Edited February 24, 2016 by SteveL

[Octavian]

Now my intuition for this would be to just use a bunch of local speakers with only one at a time directing you in the right direction down any path, with a simple location script activating the right speaker at any given place. Annoying, but easier to micromanage at each stage.

 

 

Yes. The problem now is how the switch between one speaker to the next is handled so the transition is as smooth as possible. For example one speaker has been playing for X amount of time but, when the switch happens, the other speaker plays the same loop but from the start. So the switch is jarring. One idea at the moment is to have all but the "first" speaker that handle this turned on at map start but muted. So when a switch happens and volume is "handed over" to the next speaker they are in sync in terms of "time into the sound loop". And that's a start. But still, only ambients within 11 portals will start playing at map start. Within 11 portals, matching volume should be easy enough. After 11; well, we'll see.

 

 

Thinking about your setup, I just noticed: If the increase in sound is noticeable with every transition, it might be too easy to follow the right path. With every transition the player would just have to listen, if the sound gets louder, or not. As soon as it gets weaker, he knows, that he is on the wrong path. That way the player notices a stray path as soon as he makes a transition and will not have to follow through into a dead end.

 

 

This is not about actual mazes, and these transitions would be, at least ideally, seamless. Seamless and over time rather than instant. And the maze is an abstraction to test the limits of this idea, and find solutions. But since I tend to talk a lot and be confusing, mostly due to language barrier, I tried to abstract it. If you are curious about the design reasoning for having this long sound travel distance and how I'd like to use it in an actual mission to tell a story, feel free to PM me and we can talk about it

It doesn't have access to the route that was used. There's no record of any paths kept in fact: it's done by a recursive search of all paths (up to 10 portals deep).

 

Yes, I think I understand how it works now. I took a quick look at the code too. It makes sense why they did it this way.

[demagogue]

It's worth testing what happens if you teleport a playing speaker too. Then you're just messing with one speaker playing.

[Obsttorte]

It may be easier to use a speaker attached to the player in a reasonable distance, which you could than move around the player so it points into the right direction. The distance should be as short as possible to avoid the speaker clipping into walls, but high enough to allow the player to guess the direction. This way you don't have to bother with transitions.

 

An alternative approach would be to use several speakers with no fade off (min distance equals max distance), which all use your sound but at different volumes. This way the player can't directly here from which direction the sound comes, but would get a directional feedback via the volume. If he gets closer, the sound gets louder, otherwise it gets less louder. Actually this could be done by using the location system with different ambient volumes for the different areas. I think this is also the way it was done in the Thief 1 mission. This way you wouldn't need any scripting or such, but may get the desired effect.

 

Best is to setup an example map and check out how it feels like, Maybe it's better then it sounds and your intentional approach isn't needed to reach the desired effect.

 

EDIT:

 

Some words as a mathematician regarding the 10 portal cap. It is definetely due to performance. The reason is simple due to the fact that such an search algorithm (it's basically a shortest path algorithm) has an exponential complexity. This means, for every portal allowed to pass the time needed to compute the result gets multiplied with a constant factor. If you for example consider that this factor is two, raising the portal cap to 15 would mean that it takes 32 times longer (two to the power of 5) to compute the result.

 

And to be honest, in this specific setup I could even guess that the complexety is proportional to the portal caps factorial, which would be even worse.

 

On a side note. If some of you manage to write a code that calculates the shortest path to the player from the sounds origin in less then exponential time, he should send that code to the Gray institute, as he would gain one million dollar for that (it's a millenium problem).

[demagogue]

Going back to one of my earlier ideas, the easiest way is to make the end speaker s_global 1 so it's heard everywhere but s_omni 0 so it's still directional. Then have a simple persistant script that setkeys the s_volume directly as a function of distance every .2 second or so. Sound appears to go through walls, but the mechanic works on the whole.

[SteveL]

If you for example consider that this factor is two, raising the portal cap to 15 would mean that it takes 32 times longer (two to the power of 5) to compute the result.

 

Yep that's it, although it's not actually a shortest-path algorithm. It's a depth-first search of all paths. All routes that reach the player within 10 portals get their sound contributions summed and the perceived direction of the sound gets averaged across the paths.

 

So it's probably O(b^d) complexity like you described above. d is the 10 portal depth, and b is your factor = the number of exit portals from each visleaf. Probably something like 4 or 5 in real maps, but only 1.1 or 1.2 (on average) in the maze example. So raising the number of portals crossed would probably be ok in the specific case of a maze map but it'd be disastrous for most maps.

[teh_saccade]

//

Edited July 17, 2016 by teh_saccade

[teh_saccade]

//

Edited July 17, 2016 by teh_saccade

[teh_saccade]

//

Edited July 17, 2016 by teh_saccade