Sound Propagation: Part 1: Difference between revisions
Springheel (talk | contribs) No edit summary |
|||
Line 24: | Line 24: | ||
* '''loss_closed''' "Soundprop: Acoustical loss applied to sounds going thru the door when it is completely closed (default 15 dB)" | * '''loss_closed''' "Soundprop: Acoustical loss applied to sounds going thru the door when it is completely closed (default 15 dB)" | ||
* '''loss_double_open''' "Soundprop: Acoustical loss applied to sounds going thru a set of double doors when one is open and the other is closed (defaults to 1 dB)" | * '''loss_double_open''' "Soundprop: Acoustical loss applied to sounds going thru a set of double doors when one is open and the other is closed (defaults to 1 dB)" | ||
Note that these values affect the sound propagation to AI '''only'''. Sound propagation to the player is different. | |||
== Breakable Windows (func_fracture) == | == Breakable Windows (func_fracture) == | ||
Line 35: | Line 37: | ||
* '''editor_var loss_broken''' "soundprop: Acoustical loss experienced by sounds going through the surface after it's shattered. Must have visportal present to work." | * '''editor_var loss_broken''' "soundprop: Acoustical loss experienced by sounds going through the surface after it's shattered. Must have visportal present to work." | ||
Note that these values affect the sound propagation to AI '''only'''. Sound propagation to the player is different. | |||
== Solid, unbreakable windows (and portal attenuation in general) == | == Solid, unbreakable windows (and portal attenuation in general) == | ||
Line 48: | Line 52: | ||
The loss must be a positive number, and negative numbers will automatically be converted to positive. | The loss must be a positive number, and negative numbers will automatically be converted to positive. | ||
Note that these values affect the sound propagation to AI '''only'''. Sound propagation to the player is different. | |||
The location separator you place to set sound loss at a portal doesn't have to be simultaneosly used to "properly" define a location, but it can be. In practice, you will probably be setting up some locations to take advantage of the ambient sounds and D3 EAX soundengine, and naturally you would have a different EAX environment for inside/outside areas, which requires different locations for these two places, so you would already want to put a visportal and location separator on transparent windows. | The location separator you place to set sound loss at a portal doesn't have to be simultaneosly used to "properly" define a location, but it can be. In practice, you will probably be setting up some locations to take advantage of the ambient sounds and D3 EAX soundengine, and naturally you would have a different EAX environment for inside/outside areas, which requires different locations for these two places, so you would already want to put a visportal and location separator on transparent windows. | ||
Line 53: | Line 59: | ||
NOTE: Opaque windows don't need a visportal or any of this. They should already separate the inside and outside areas. | NOTE: Opaque windows don't need a visportal or any of this. They should already separate the inside and outside areas. | ||
EDIT: It appears that sound_loss only applies to sounds propagating to the AI, but not sounds propagating to the player. This is a known issue and we hope to fix it someday (possibly after Doom3 goes open source). In the meantime, one alternative is to use a func_portal to turn the visportal on and off based on its distance from the player. This will cut off sound (and vision) through the portal until the player is within range, which can at least stop outside sounds leaking well enough in for certain situations if the blacked-out portal isn't a problem. If anyone knows other alternatives, or if the above information isn't entirely accurate, feel free to edit this paragraph. | EDIT: It appears that sound_loss only applies to sounds propagating to the AI, but not sounds propagating to the player. This is a known issue and we hope to fix it someday (possibly after Doom3 goes open source). In the meantime, one alternative is to use a func_portal to turn the visportal on and off based on its distance from the player (create a func_portal and move it so it touches the visportal in question. Add the spawnarg "portal_dist" "x" where x is the distance to turn the portal off). This will cut off sound (and vision) completely through the portal until the player is within range, which can at least stop outside sounds leaking in well enough in for certain situations if the blacked-out portal isn't a problem. If anyone knows other alternatives, or if the above information isn't entirely accurate, feel free to edit this paragraph. | ||
== Setting Portal Attenuation Directly with Scripting == | == Setting Portal Attenuation Directly with Scripting == |
Revision as of 00:30, 23 March 2011
Originally written by Ishtvan on http://forums.thedarkmod.com/topic/3271
Mapping and Sound Propagation: Part 1
Assumed knowledge: How to place Visportals, doors and breakable windows.
Portals and Caulking
First of all, all sound propagation (both TDM soundprop and the D3 sound engine) depends on visportals to define the apertures between rooms. It is therefore essential that your map be portalized and caulked correctly. Ideally, all concave rooms should be broken up into convex sections by visportals. This is a good rule for getting performane out of your maps in general (as long as you can't see too many separate portals from any given portal). Occasionally, you may have a concave room where breaking it up into two convex areas with a visportal isn't necessary for improving renderer performance, but is necessary for believable sound propagation.
Caulking is important, because the renderer uses it to distinguish separate portal areas. If you have any caulking leaks between areas that you intend to be separated, this will cause serious errors in soundprop, not to mention a decrease in performance from the D3 renderer.
Anything that can change the attenuation of sound going inbetween two rooms needs to interface with soundprop.
Note
The sound propagation code works ideally for rectangles now. In case anyone's curious, this is the part of the code that finds the minimum path length for paths that are constrained to go thru certain portals. I.e., it calculates what points on the portal surfaces the sound path should pass through to get the least distance path.
If the visportal does not have four sides then sound is just passed through the centre. This will be okay for smaller visportals, but the error (path difference from the minimal path) will get more noticeable the larger the visportal. The code also still assumes that when you do have four sides, they are perpendicular. If you have some non-90 degree angles between the sides, some weirdness may ensue.
Doors & Openable Windows (func_darkmod_door)
A visportal must be placed within the door if you want the door to have any effect on sound propagation when it opens/closes.
Doors and Windows are the same as seen by the code. They are both covered by func_darkmod_door. It's probably easiset to list the relevant key/value pairs from the def file:
- loss_open "Soundprop: Acoustical loss applied to sounds going thru the door when it is open (default 1 dB)"
- loss_closed "Soundprop: Acoustical loss applied to sounds going thru the door when it is completely closed (default 15 dB)"
- loss_double_open "Soundprop: Acoustical loss applied to sounds going thru a set of double doors when one is open and the other is closed (defaults to 1 dB)"
Note that these values affect the sound propagation to AI only. Sound propagation to the player is different.
Breakable Windows (func_fracture)
Again, a visportal must be placed within a breakable window if you want its breaking to have any effect on sound propagation. (Actually, the sound of it breaking will still be propagated regardless of whether a visportal is inside. What I mean is, if you want it to block sound from going through at first, and then let sound through when it's broken, it must have a visportal placed within its bounds)
Relevant values in the def file:
- editor_var loss_unbroken "soundprop: Acoustical loss experienced by sounds going through the unbroken fracture surface. Must have visportal present to work."
NOTE: This number should probably be a bit higher than a loss for an ordinary door, because windows are usually more airtight than doors, which have spaces underneath and above.
- editor_var loss_broken "soundprop: Acoustical loss experienced by sounds going through the surface after it's shattered. Must have visportal present to work."
Note that these values affect the sound propagation to AI only. Sound propagation to the player is different.
Solid, unbreakable windows (and portal attenuation in general)
Suppose you have a transparent window looking outside from a room, that for whatever reason is not a breakable, func_fracture window. Because it's transparent, the renderer and consequently soundprop will view it as connected with the outside area. You'll have to do two things to get soundprop to attenuate souns when going through that unbreakable window.
- 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.
- Place an info_locationseparator entity so that it's touching the visportal.
- 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."
The loss must be a positive number, and negative numbers will automatically be converted to positive.
Note that these values affect the sound propagation to AI only. Sound propagation to the player is different.
The location separator you place to set sound loss at a portal doesn't have to be simultaneosly used to "properly" define a location, but it can be. In practice, you will probably be setting up some locations to take advantage of the ambient sounds and D3 EAX soundengine, and naturally you would have a different EAX environment for inside/outside areas, which requires different locations for these two places, so you would already want to put a visportal and location separator on transparent windows.
NOTE: Opaque windows don't need a visportal or any of this. They should already separate the inside and outside areas.
EDIT: It appears that sound_loss only applies to sounds propagating to the AI, but not sounds propagating to the player. This is a known issue and we hope to fix it someday (possibly after Doom3 goes open source). In the meantime, one alternative is to use a func_portal to turn the visportal on and off based on its distance from the player (create a func_portal and move it so it touches the visportal in question. Add the spawnarg "portal_dist" "x" where x is the distance to turn the portal off). This will cut off sound (and vision) completely through the portal until the player is within range, which can at least stop outside sounds leaking in well enough in for certain situations if the blacked-out portal isn't a problem. If anyone knows other alternatives, or if the above information isn't entirely accurate, feel free to edit this paragraph.
Setting Portal Attenuation Directly with Scripting
If you know the handle of the portal (which you will need to use some D3 debug settings to find out), you can also set the portal attenuation directly, and get it, with these two scriptfunctions called on the sys object.
void setPortSoundLoss( float handle, float value ) float getPortSoundLoss( float handle )
This can be used ingame to dynamically alter the flow of sound in the map in cases where the door/window code is not sufficient (for example, pushing aside a large crate that was covering a sound-conducting passage to another room).