Using sound_loss on visportals

[Springheel]

Does anyone have experience with using info_locationseparators to increase sound loss for a visportal? I followed the directions from the wiki:

 

1. Place a visportal in the window (you'll probably want to do this for performance reasons anyway). At this stage, soundprop will think it is a hole in the wall. It doesn't know about the window there blocking the sound.

2. Place an info_locationseparator entity so that it's touching the visportal.

3. Set the portal attenuation value (again in dB) on the info_locationseparator.

 

Soundprop can use info_locationseparator to make sound incur a certain loss when going through the portal it's touching. The key/value pair is the following:

 

* sound_loss "Soundprop: Loss in dB incurred when a sound travels through this portal. Cumulative with door loss if a door is present."

 

But as far as I can tell there is no impact on the sound coming through the opening.

[grayman]

Need details.

 

What's the sound?

 

Where's it located? How far from the visportal?

 

Where are you when you're listening to the sound?

 

Sound reduction changes the min and max radii for the sound. If you're inside the reduced min radius, you'll still hear the sound at max volume.

[stumpy]

are you also using the info_location entity one per visportaled area.

Edited March 21, 2011 by stumpy

[OrbWeaver]

Sound reduction changes the min and max radii for the sound. If you're inside the reduced min radius, you'll still hear the sound at max volume.

 

Interesting, so I guess that means that the spawnarg documentation is incorrect? It isn't a loss in dB, but an increase in distance.

[Springheel]

The sounds are footsteps, so there is no minimum distance.

 

Hmm. I just realized that maybe the method I was trying only works for sound propagated to AI, not sound going to the player. The wiki article isn't really clear:

 

http://wiki.thedarkmod.com/index.php?title=Sound_Propagation:_Part_1

 

Here's the situation I want to solve...I have a room with a hole in the floor, and a guard patrolling underneath in the basement. The hole has a visportal in it, but it still sounds like the basement guard is right in the same room with you when he walks around. I was hoping to increase the sound loss when it goes through the portal so the basement guard couldn't be heard so clearly.

[grayman]

All I can think of is to put multiple visportals inside the hole, with a single info_locationseparator touching all of them.

 

Hopefully the code will register the separator with each visportal and apply its sound reduction to each.

 

Since visportals are just a plane, I assume they can be as little as 0.125 apart.

[Springheel]

Will that reduce sound to the player, though? I'm now thinking that the wiki page is talking about reducing sound to AI only...the section on doors definitely does not apply to the player-heard sounds.

 

I think I got confused by the fact that he talked about EAX sound in the same section.

 

There's got to be some way to reduce the volume of sounds getting to the player though.

[demagogue]

Hmm. I just realized that maybe the method I was trying only works for sound propagated to AI, not sound going to the player.

 

This is right. It just affects to-AI propagation.

People keep suspecting to-player might get in there somewhere, but we keep re-confirming every time it's just for AI.

 

There was a thread around somewhere where we were brain-storming alternatives and maybe new spawnargs for players. It's something we need eventually I think (a new feature on visPortals), since the problem comes up in so many situations, windows, holes, odd-shaped rooms. I sympathize with your disbelief; but AFAIK there isn't any way to modulate volume to-player that we've found except through EAX (which of course muffles everything, and even then isn't universally applied).

 

Some ideas we tossed around -- Conditionally modulate the bark at its source? ... complicated. Creative use of a door when the player isn't in direct view of the hole? Also unsatisfying.

[grayman]

This is right. It just affects to-AI propagation.

People keep suspecting to-player might get in there somewhere, but we keep re-confirming every time it's just for AI.

 

 

I have a test map I made when we were talking about this. It's a long hall (1536) with visportals every 256. At one end of the hall I have a looping speaker playing "gregorian01a" and I set the min/max distances to 1888 and 1968. (The spawnargs are 48 & 50.)

 

Each vp has an info_locationseparator on it, each with "sound_loss" set to "100".

 

Each vp has a func_portal on it.

 

Cases:

 

A - set "portal_dist" to "2560" on each func_portal

 

This keeps each vp open as I walk down the hall. I get to the far end of the hall (away from the speaker) and I'm hearing full volume from the speaker, because my distance is less than the min distance (1536 < 1888).

 

B - set "portal_dist" to "256" on each func_portal

 

Now the visportals close behind me as I walk away from the speaker. When the third visportal shuts behind me, the sound cuts off. If I turn back toward the speaker and take a couple steps, visportal #3 opens and the sound comes back. Step back, vp closes, sound gone.

 

So open visportals with info_locationseparators have no effect on what the player hears.

 

But closed visportals with info_locationseparators do.

[demagogue]

I was talking specifically about the "sound_loss" spawnarg on info_locations not applying to to-player sounds, not visPortal sound-propagation generally.

 

But sound propagation to the player most definitely uses the visPortal system, as your experiment just indicated, and as we know from that wiki chart of VPs on corners with red-lines (of sound) going through them, and when you turn on show-sound-prop, you can literally see the sound-line going from the AI, to a VP, to the player. Propagation goes through the middle of visPortals, through in-leaf walls if it has to, and when a VP closes, light and sound to the player both cut off through the VP. So re: "closed visportals with info_locationseparators do [affect the player]": yes, that's right. (I also assumed this effect in my suggestion for creative use of doors or VP blocking as a hack fix.)

 

What isn't affected, though, is the sound_loss to player when it's open. And the only way to get it (I think) would be to get into the visPortal or info_location code itself and change the to-player sound-prop code directly to reduce the sound there, which I think is still closed source isn't it? (I actually wrote a paragraph on that in my post above, but then I deleted it because it was long.)

[Springheel]

So open visportals with info_locationseparators have no effect on what the player hears.

 

But closed visportals with info_locationseparators do.

 

Ok, then I'm using it wrong, because the visportal was closed in some cases, yet I could still hear the AI fully.

 

I'll try it with the two visportals, like you mentioned, and see what happens.

[Springheel]

No, that doesn't work either. I tried creating two visportals close together and having a single info_locationseparator touching them both. I set the sound loss to an extreme level (500) but it had no effect. I'm not sure I'm doing it right though. Maybe the visportal isn't closing.

 

Each vp has a func_portal on it.

 

What is this for, btw? I don't have one of those.

[grayman]

What is this for, btw? I don't have one of those.

 

You use func_portals to turn visportals on and off based on their distance from the player.

 

It's useful if you have a vp in the distance (i.e. a window) when there's no point in showing what's behind it because it's so far away.

 

Mostly used in outside areas.

 

Check the tower windows in the training map's arrow-shooting range.

[OrbWeaver]

What isn't affected, though, is the sound_loss to player when it's open. And the only way to get it (I think) would be to get into the visPortal or info_location code itself and change the to-player sound-prop code directly to reduce the sound there, which I think is still closed source isn't it? (I actually wrote a paragraph on that in my post above, but then I deleted it because it was long.)

 

It sounds like the main problem is that merely tracing distance through chains of portals is too naïve, because it assumes portals are generally the same size. In real life a small hole between two rooms would attenuate sound considerably, which I think is the situation Sprinheel is describing; but the Doom 3 sound-propagation code is not taking portal area into account.

 

And I think you are right that this cannot easily be fixed without the Doom 3 source.

[Springheel]

You use func_portals to turn visportals on and off based on their distance from the player

 

Ah, ok, I'll use that to force the visportal closed and see if that works. The player can't look down the hole until they're nearly on top of it anyway.

[Springheel]

Yes, I can confirm that this works. As long as the portal is closed, the sound is cut off. Given the setup, I'm able to close the visportal until the player is fairly close, at which point the sound isn't such a problem, so that should be enough for me in this case.

 

It would still be nice if would could get sound_loss to work regardless of whether the portal was open or closed.

[New Horizon]

It would still be nice if would could get sound_loss to work regardless of whether the portal was open or closed.

 

Being able to set an 'open' and 'closed' sound_loss setting for doors and windows would also be beneficial.

 

Not using any real numbers here, but just for an example...a portal placed within a door frame might have a loss of say...10...and when the door is closed, that loss is bumped to 40.

 

It would be helpful if the visportal creation in Darkradiant has some default 'size based' setting. If a mapper created a brush, and textured it with visportal, depending on the size...DR could automatically assign an open snd_loss and closed snd_loss...up to a certain size...once you get so big, it really wouldn't matter.

 

For a visportal brush with no door, both of those settings would the same number, but the addition of a door could then override the default sound_loss by adding an extra amount to what is already there.

 

No idea if any of that is possible, but if the sound_loss can be made to work...it probably wouldn't be too far of a stretch to achieve the rest.

[demagogue]

So to be clear on this, all sound is cutting off *entirely* when you force the VP closed, right?

 

This is opposed to the sound_loss working (for to-player sound propagation) when the VP is closed but not when it's open (so it attenuates sound when the VP is closed, but doesn't stop sound entirely)*, which might be one way to interpret what you said, but I don't think so -- you wouldn't have said "cut off" in that case, and I understood that sound_loss wasn't working for to-player sound prop ever, open or closed.

 

* I thought about this because don't closed-doors close VPs but also allow some sound through, through the loss_closed spawnarg? But this may be a custom-built situation so the analogy to VP'd holes & transparent windows might not apply.

 

Edit: BTW I thought it'd be a good idea to update the wiki on these issues too, and then thought I may as well take the initiative (since sometimes it doesn't get done if not right away), but now I look at it and think it could explain things better, like how the alternative to cut off the func_portal with distance works in a sentence.

 

Anyway, here it is if anyone wants to do that: http://wiki.thedarkmod.com/index.php?title=Sound_Propagation:_Part_1#Solid.2C_unbreakable_windows_.28and_portal_attenuation_in_general.29

[Springheel]

So to be clear on this, all sound is cutting off *entirely* when you force the VP closed, right?

 

It is, but I had the sound_loss up to a ridiculous level, like 500. Worth testing to see what happens when it's a reasonable level.

[Springheel]

Nuts. Looks like it is all or nothing. If you force the visportal closed, then no sound gets through at all, regardless of what the sound_loss value is.

 

That's far less useful, but I guess it will have to do.

[Ishtvan]

sound_loss only affects AI sound, not player sound you can hear.

 

Forcing a portal open or closed presumably uses D3's "door loss" to affect audible sound, which is a value we can change, but it's the same for all portals across the map (until the sound engine source is released and we can change it).

[New Horizon]

sound_loss only affects AI sound, not player sound you can hear.

 

Forcing a portal open or closed presumably uses D3's "door loss" to affect audible sound, which is a value we can change, but it's the same for all portals across the map (until the sound engine source is released and we can change it).

 

From what spring is describing though, it sounds like forcing it closed it cancelling all sound.

[ungoliant]

From what spring is describing though, it sounds like forcing it closed it cancelling all sound.

 

sounds like natural tdm behavior to me. recall coming up to a closed door where you want to know whats on the other side. theres some loud stuff going on the other side. you won't hear anything unless you lean against the door. most other times you don't really get close enough to a closed portal (unless your walking backwards) to really notice this effect. Perhaps this is a potential source of player aggravation with not being able to hear AI footsteps?

 

But, then again, if i am working though a corridor, and i pass through a visportal and stop, the portal is now behind me, i'm facing away from it, it is closed. An AI walks up behind me "HEY WHOS THAT THAR?!" will this really be impossible to hear? I doubt it. If that is the case, apparently i pay a lot less attention to sound than i thought i did.

[New Horizon]

sounds like natural tdm behavior to me. recall coming up to a closed door where you want to know whats on the other side. theres some loud stuff going on the other side. you won't hear anything unless you lean against the door.

 

I know doors will reduce the sound heard by the player, but it's not supposed to completely cancel. It's only when portals are forced shut that the sound_loss setting seems to be getting ignored.

 

If we can find a way to force the sound_loss on mapper defined portals, it would be a huge help.

[ungoliant]

as portals are worldspawn it seems the most intuitive solution would be to modify the behavior based on entities that intersect them. an entire redesign of the portal system even if d3 goes opensource seems too much like reinventing the wheel. *

 

edit: *and would break maps to boot

Edited March 23, 2011 by ungoliant