Jump to content
The Dark Mod Forums
Sign in to follow this  
RPGista

Visportals that can decrease sound

Recommended Posts

While a solution for a physically accurate way of decreasing sound propagation based on distance from source is not available, would it be possible to code a way to manually set how much you want a certain visportal to muffle sound that crosses it (through spawnarg). This already happens, I believe, when a visportal is closed by a door, which decreases how much sound passes through it. The request is to make this feature manual. You could then set a visportal on a very narrow hole to allow only 15% of sound through, etc.

Share this post


Link to post
Share on other sites

i think you can already do this with a info location separator, you can set the sound volume propertiy on it for something like -15. A Visportal isn't a object brush and cant have a spawnarg as an individual visportal surface it would be on all worldspawn surfaces. Its part of brush 0 worldspawn so if you put a arg on it then everything in the world that isn't a object will get the arg.

Share this post


Link to post
Share on other sites

This topic has been discussed a lot before, so it's an old issue for us. Short answer, there is a spawnarg on the location_separators for sound muffling, but it's for the volume propagating to the AI and it doesn't affect volume to the player (or something like that). And AFAIK The function muffling for the door can't be rigged to this purpose (the doors are not allowing less sound through an open portal; they're closing the portal then may allow a little sound through. So it's useless for anything like a window where you need the portal open). So to do this task, you'd need source code support.

 

Since we do have the source code for portals now, it's possible. I even pinned down where in the code sound propagation is handled by the portals, where presumably you'd add the new code to do this job, but I wasn't sure exactly what to do at the time.


What do you see when you turn out the light? I can't tell you but I know that it's mine.

Share this post


Link to post
Share on other sites

It really is one of the last mapping issues imo.

 

Even if the propogation to ai works properly (which is a good thing) the sound to the player breaks their perception that it works properly. (If I can hear them they can hear me, and where is that guard actually at?)


Dark is the sway that mows like a harvest

Share this post


Link to post
Share on other sites
Even if the propogation to ai works properly (which is a good thing) the sound to the player breaks their perception that it works properly. (If I can hear them they can hear me, and where is that guard actually at?)

The only way I have managed to mitigate this issue is to try and have enough VP's between the player and AI.

Share this post


Link to post
Share on other sites

Yes, the way sound propagation works for portals, it reduces the volume for each portal the sound travels through. So ideally, you'd add a simple line of code there that gets a spawnarg off the location_separator of the portal at hand ("volume_modifier") and just tack that onto that volume reduction that's already there. But in the meantime, if you wanted to hack it you'd throw in multiple layers of portals to do the job.

 

Edit: Here's a test someone might try. For a window, rather than 1 portal over it, stick like 3 or 4 thin layers of portal over the window, and see what that does to the volume (and performance).


What do you see when you turn out the light? I can't tell you but I know that it's mine.

Share this post


Link to post
Share on other sites

Well, is it that sound is loss across portals (I don't think it does - that could make sound traveling straight down a hallway diminish just due to portals) or that having more of them routes the sound better. Which can in a lot of cases minimize heard sounds because it has to go around corners instead of straight through walls.

 

So if you have a hallway with a hole in the wall to the outside it you get more sound loss if the sound travels down the hall, around a corner and out the window. If you removed the portal from the window the sound would go straight through the wall to the player. In many cases the sound going through the window could be 10-50 feet further away then if it went straight through a 2 foot wall. So naturally the sound diminishes over that distance.

 

The real problem we have is the player being directly on the other side of a pane of glass. While the guard may not hear you as well through the sound location portal, the player still hears the guard as if the glass wasn't there. Making it harder to distinguish how well the guard actually can hear you. While you might be able to walk and not be heard it makes you feel you need to crouch or even creep.

 

Placing two portals in a window (one aligned with each side of wall) might gain you a couple inches of sound travelling distance and it won't chop up the terrain into more tris it still seems like a bit of over kill for very little gain. adding a couple more portals won't redirect the sound anymore, but it'll give you quite a few more tris.


Dark is the sway that mows like a harvest

Share this post


Link to post
Share on other sites

What Baddcog wrote is right - adding more portals only helps if it increases the distance the sound has to travel. And if it does this, then you should have added these portals in the first place, otherwise the sound is traveling straight trough walls etc.

 

Anyway, the real solution need someone with free time and coding experience.


"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Share this post


Link to post
Share on other sites

The reason I said that is because that's what the portal code seemed to be doing in my superficial reading, because a sound is ultimately emitted from the last portal, and it looked like it was simply counting up how many other portals it traveled through to attenuate it. Anyway, that's why I proposed it as an experiment, to see just how much does it attenuate it. I wasn't giving a definitive answer, but asking the question and a way to answer it.

 

It'd be a very messy solution anyway, and of course it's better if a spawnarg for sound-attenuation on portals is just coded outright.


What do you see when you turn out the light? I can't tell you but I know that it's mine.

Share this post


Link to post
Share on other sites

Actually the portals are counted for the sound-propagation to AI as there is a limit on how many portals a sound can cross before it becomes unable to reach an AI. This is to help performance I think.

 

Regarding the sound loss. As there is already such a mechanism for the sound to AI propagation, couldn't we just take the code and put it in the specific lines handling the sound propagation for the player. Another mechanism to implement (as we are just talking about) would be some kind of auto-decrease-sound, thus meaning if the mapper does not specify the spawnarg handling the sound_loss an value is automatically choosen depending on the size of the visportal. This would save some work for the mapper.

 

Just an idea. :smile:


FM's: Builder Roads, Old Habits, Old Habits Rebuild

WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Share this post


Link to post
Share on other sites

It would be interesting to be able to plug the AI sound system into the player so we can hear things as they hear them...or at least be able to tweak what the player 'should' be hearing more accurately.

 

This is definitely been on the requests list for quite some time too. I seem to remember Spring had an AI several floors down in one of his maps and an open hole in the floor. Since the size of the open vis-portal had no effect on what the player heard, it sounded like the AI was practically in the room with him.

Share this post


Link to post
Share on other sites

This discussion has been going on for a long time (years), and doesn't appear to be headed anywhere soon, so It sounds ( :o ) like we need someone to study and understand sound occlusion and propagation to the player, then present the problem and possibly a solution. IMHO, this problem has the greatest impact on the gameplay experience than any other problem we're currently discussing.

 

I've reached the inevitable "scratching my head" place with my WIP, and need some time away from it, so I'd be willing to go off and do this study, if folks are agreeable to that. Since this is acknowledged to be a difficult problem to solve in games, I'm not guaranteeing anything.

 

So if there are no other volunteers, I'm willing to take a shot at it.

 

If anyone has actually read the sound code and can offer some "start here" suggestions, please send me a PM.

  • Like 2

Share this post


Link to post
Share on other sites

I find this endeavour important, too! As always, many people can talk the talk, but it needs someone with special dedication and necessary skills to actually walk the walk.

 

Thanks for having a look at it! Greatly appreciated!


Clipper

-The mapper's best friend.

Share this post


Link to post
Share on other sites
IMHO, this problem has the greatest impact on the gameplay experience than any other problem we're currently discussing.

 

+1

 

 

I'm willing to take a shot at it.

 

That's fantastic! :)

Share this post


Link to post
Share on other sites

Is sound propagation to AI working reasonably well, or are there issues with that?

 

My reading of what folks are discussing is that the problem is "what the player hears".

 

Right?

Share this post


Link to post
Share on other sites

Yup. Sound propagation to ai works fine. Additionaly the mapper has the possibility to control the sound spreading via spawnargs on the info_locationseperator entities (something like "loss_open" or so). It's "sound_loss".


FM's: Builder Roads, Old Habits, Old Habits Rebuild

WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Share this post


Link to post
Share on other sites

Great Grayman, this has been on the back burner for years. But it needs someone who can understand it :D

 

I don't think size of visportal should have any effect at all. If the sound_loss prop is working properly (to and from ai) then the author can use that to adjust for the size of a hole.


Dark is the sway that mows like a harvest

Share this post


Link to post
Share on other sites

First, this bug was unfixable before we had the source code. So, yeah, it's on the wishlist for years, but we couldn't do anything since maybe a year. And since our workforce has dropped considerable the last years, well, you know how it is.

 

 

Anyway, here is a description of what the system needs to achive along with comments:

 

* both sound propagation (what the AI perceives) and sound volume (what the player hears) must be modified by the portals. Technically, both should be in sync, but I'm not sure it is easy or even possible to compute one set of values from the others. The AI sounds are modified with volume values, while the player sound is in DB, and I'm not sure these are compatible. Also, for some reasons, mappers might want a sound to be appear louder to the AI then to the player and vice versa. So each portal needs two sets of modifiers.

 

 

* the values must be mapper adjustable. Since portals itself cannot carry spawnargs, there is essentially only one way: specify them via an extra entity. Technically, the location entity is a good place to place modified default value, however, all portals in one location would then share the same values. This is not good for big locations (think "large cellar") and also it would mean you'd need to split up some locations arbitrarily just to modify one portal. In addition, each portal can be part of two locations (if it is a boundary), so which default values it would use would be undefined.

 

So this means the modification itself must be on an entity that is placed on the portal (like the other "info_locationseparator"). However, it cannot be the "info_locationseparator" because this would also split the location while you might only want to modify the sound traversal.

 

A new "info_portalsettings" would be needed to be created. Mappers would stick them into a portal, then adjust the values on these. When the map is loaded, these entities are parsed, and then modify the portal values. The entities probably need to stay around so scripts can use them to access the portal they are located at. Scripting events to modify the values on the portals on the fly can be added later, I guess. (There are already two, one for sound loss, which is AI propagated sound loss when portal is closed, and one for light loss, which is unimplemented.)

 

In implementation terms one could also just "clone" the info_locationseparator entities and give them a spawnarg like "split_location". If true, it splits the location, if not, it skips that step. In addition to that, it parses the sound values and sets them on the portal. The two entities "info_locationseparator" and "info_portalsettings" would then have the same base class and id C++ class, just a different value for "split_location", and one could just enhance the class idLocationSeparatorEntity. While that sounds easiest to me, the actual implementation details are not that important.

 

 

* The two sets of values must contain each more than one value. Right now, sound is either traversing a portal when it is open, or not (or very dampened), when it is closed. This, however, does not account for the difference of a portal closed by a door and a portal closed because it is outside the PVS (player visible space). If you go around a bend, a portal closes, but that should actually not modify the sound passing through the portal. So, portals need one value for "closed by a door", one for "open portal" and one for "closed because not rendered" (or maybe a flag that distinguishes between these two states and just uses the "open portal" value when the portal is closed due to being not rendered). This distinction is also important for portals that are closed by distance - the sound should still travel as if the portal was open. But we probably need a mapper override - f.i. in heavy fog to close every portal more than 50m away to skip rendering - but the sound could also be cut off (it might sound odd, tho, and maybe we can just hardcode it into "if portal is closed for rendering only, then still let sound flow as if open").

 

Anyway, we need all these 2 times, for player and AI.

 

The "open portal" value (a modifier like 0.9 as factor) is commonly what people refer here to when they say that he sound must be modified due to portal size, but the other factor (closed by a door) is also important, because some doors should dampen the sound very well, while others not so (glas window vs heavy metal door).

 

 

 

 

As for the actual implementation, idLocationSeparatorEntity is a good start as it already modifies area portals. Looking at it, though, the sep. entities are kept around, because they contain the handle of the portal they are connected to, and there is a script even that is used to fetch that.That sounds quite wasteful, if you start to have more than a few dozend entities just to keep one value (the portal handle) around. OTOH, it is a convienent way for scripts to refer to a portal - the portal itself is not accessible in the map, and the portal number is assigned during map load (I think).

 

 

If there are more questions, don't hesitate to send me a PM. Hope that helps!


"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Share this post


Link to post
Share on other sites

Whoops, maybe we only need two values (player sound dampen factor and AI prop sound dampen factor) because the dampen of the door is of course stored on the door.

 

So if you have a small window (factor 0.5 for both player and AI) and a large door (factor 0.8 for both player and AI) then putting in a glass window (factor 0.5) and a metal door (factor 0.1) means you arrive at:

 

* open window (0.5), closed window (0.5 * 0.5 => 0.25)

* open door (0.8), closed door (0.8 * 0.1 => 0.08)

 

which preserves the properties like "the window lets less sounds trough than the door when open", "a closed door lets less sounds through than an open window" etc.


"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Share this post


Link to post
Share on other sites

I don't see a big problem with having some areas more. I mean we are mainly talking about windows (seperating in- and outside normally) and little holes (which often also should two different locations, like groundfloor and cellar or so). So I think you will have the areas seperated anyways and don't really need an extra entity for that.

 

But even if another entity is used for that I think it would make sense to have these spawnargs available for info_locationseperators, too. Why should I place a second entity in my visportal just for sound purposes, this just gets confusing and can cause the mapper to set the wrong spawnargs on the wrong entity.


FM's: Builder Roads, Old Habits, Old Habits Rebuild

WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Share this post


Link to post
Share on other sites

If you are splitting up locations, you need to double the info_location entities, so both "halves" of say the kitchen have the same ambient, the same ambient music etc etc. This all canget complicated if you have instead of 5 loctions per floor suddenly 20. So not having to have dummy locations is a definite plus esp. because Swift Mazes uses locations in the sense of locations, but I'd still be able to modify the sound loss on a trap door even if it is in the same location.

 

The second point is what I agree with, having the same entity class used for both entities means you can either put one, the other, or simply one one of both with both sets of spawnargs just by setting one spawnarg more. Basically like this:

 

entityDef info_portal_base
{
 .. define everything common here default values etc
 "spawnclass" "idLocationSeperator"
 "sound_loss" "etc"
 "editor_usage" "Base class do not use."
}

entityDef info_locationSeperator
{
 "inherit" "info_portal_base"
 "split_location" "1"
 "sound_loss" "etc"
}

entityDef info_portalSettings
{
 "inherit" "info_portal_base"
 "split_location" "0"
 "sound_loss" "etc"
}

 

That way mappers can use whatever they find easier


"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Share this post


Link to post
Share on other sites

Anyway, we need all these 2 times, for player and AI.

 

If there are no current issues with sound propagation to AI, why this statement?

Share this post


Link to post
Share on other sites

If there are no current issues with sound propagation to AI, why this statement?

 

Because someone might think that changing the "factor for AI" into "factor for both AI and player" is enough, while I think "factor for AI, and another factor for player" is what we need, with modification possible for both.

 

Edit: There might well be issues with sound prop to AI that we don't even realize now. For instance the "close portal due to not being rendered", does that affect sound propagation (that would be bad), or not? AI should hear you, regardless if there are around a bend, or not.


"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Share this post


Link to post
Share on other sites

The current portal design is such that if you can't see through a portal (it's closed) then sound (to the player) is occluded (less volume) as it passes through that portal. If the portal is open, then there is no occlusion. It's probably this way to account for open and closed doors.

 

However, this design causes two problems:

 

1 - A closed window that has an open portal (you can see through it) doesn't occlude the sound.

 

2 - A portal closed by a func_portal occludes sound, even though there's no closed door.

 

3 - A non-door portal closed by the renderer for view culling may or may not occlude sound. I haven't found that code yet, so I'm not sure about this one.

 

I'm testing a fix now that separates view blocking and sound blocking. This should solve these problems.

 

Other problems:

 

4 - Upthread talks about the "sound_loss" on location separators. This loss is only used for sounds propagated to AI. Sound to the player ignores this value. Based on the discussion, I assume folks are expecting "sound_loss" to also apply to what the player hears. Is that correct? If so, then this needs to be fixed.

 

5 - A window w/o a portal. Imagine a room with a glass divider. The mapper doesn't put a portal across the glass. A player should expect to hear some of a sound on the other side of the glass. This is the general case of "sound occlusion through walls", which could use material and thickness considerations to simulate expectations, but currently doesn't. I don't know if this is easily fixed. (This is different from the case where there are no visportals between the player and a sound source he can't see, and he experiences the sound "through the wall" when he shouldn't.)

 

6 - The code doesn't take visportal size into account. Small openings should allow less sound to pass than large openings. (Springheel's "tiny opening" problem comes to mind.) This should be easy to add, but the amount of occlusion will need to be determined experimentally.

 

---------------------------

 

Are there any other problems I should be looking at?

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...