Jump to content
The Dark Mod Forums

Visportals that can decrease sound


RPGista

Recommended Posts

When talking about what AI and the player can hear, keep in mind that there are actually two sounds. One is the sound the player hears, and one is the sound propagated to the AI, which doesn't have a sound file (*.ogg, *.wav) associated with it, but does have a volume.

 

If we wanted to make player hearing appear equivalent to AI hearing, then we'd have to either increase the volume of the propagated sound or decrease the volume of what the player hears.

 

Neither case seems acceptable. In the first case, we'd be increasing the chance that an AI will hear a suspicious sound, and in the second case we'd be making sounds softer for the player. Both changes would affect the player's experience in existing missions. We'd need to decide if this constitutes breaking missions.

 

So unless we think this is a problem that really needs to be fixed, and that doing so will provide better gameplay in existing and future missions, we probably shouldn't tinker with real and propagated sound volumes.

 

That's why I said we need two variables, one that applies to the AI as it is, and one where we can tweak the sound the player is hearing (without affecting the hearing the AI has). Consider Springheels example which is actually the problem we want to fix:

 

* AI is a floor below, a tiny trapdoor leads up.

* player stands near trapdoor, but hears AI like it is next to him

 

We WANT to modify the sound the player hears, but is is unlikely we want to modify the volume that reaches the AI (as the original reports never reported that this doesn't work as wanted).

 

The easiest (and probably the only way) to achive that is to have two independent variables.

 

But I'm repeating myself here.

 

 

@grayman: good work in finding this out, the current sound code is inherited from D3 and was sometimes modified, so don't assume it is actualy correct in all ways. Especially when portals come into play, because there are a lot of simplifications there to make it "fast" (even tho it isn't actually clear if the performance is actually affected).

 

For instance, sound alway travels through the portal center. If you have a large or huge portal, the sound can take a much longer path to through the portal than it would actually. There is a forest testmap somewhere which used 100m portals to shut off parts of the forest for rendering, if you stand on the corner of the portal, net to an AI of the other side, the sound travels 50m to the center, then back 50 m to the AI.

 

Another case is the "cut-off"; it was designed so the propagation code can stop worrying about sounds that are not to be heard by the AI, anyway. But it might have been broken later.

"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

Link to comment
Share on other sites

How hard would it be to fix the player sound not using distances, but volumes instead like the AI? The "Min/max" radius of speakers has always caught us where something was cut-off just because you where 1 unit too far away.

"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

Link to comment
Share on other sites

I know.

 

That was what I was trying to say. Sorry if it was a bit unclear.

 

If and only if some sounds seem not to alert AI in cases where they should, like it was mentioned with the broadhead arrow, then I think the easiest way to fix that would be to increase the propagated volume for the AI a bit. But it has to be discussed for every single case if it really is a problem.

 

I thought about such cases earlier in for myself. For example if you shoot a torch with a water arrow where the guard is only two meters far away. I think the AI should hear the water arrow impact (maybe it does, unsure). But that's only my view. As said, such changes should be discussed.

 

Regarding sound propagation to the player: I didn't think about the dependency of the volume estimation on speaker radius. This is a little problem, because if mappers don't set a minimum sound distance in a proper way (so there is a noticeable falloff) this might cause some problems. Using the sound_loss spawnarg for players, too would than mean that we have to take the falloff into consideration when transforming the actual spawnarg value (for example 10dB) into a proper distance to achieve the right effect.

 

Regarding the code it just calculates the sound reduction depending on the distance. So an alternative would be to use a spawnarg "sound_loss_player" "X", where X is the amont of noise that should slip trough the visportal. So if one choose X=0.8 for example the sound volume would be reduced by 20%. I guess this is easier to handle then an actual volume based spawnarg, as the distance required for such an reduction would depend on the already achieved reduction on the on side and the falloff type (linear, quadratic) on the other side. Or we just choose a distance based spawnarg.

 

I'm firmly on the "factor" spawnarg. Based on distance is just ugly to compute for mappers.

 

The only problem is, do we use a factor "0.8", this is easy for humans to compute. Or do we use DB? (Most people probably don't even know DB aren't linear)

"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

Link to comment
Share on other sites

Actually the factor-approach would be much easier to implement. We just have to tell the mappers that 10dB is equal 0.5 and 20dB is equal 0.25 and so one. Using a dB-based approach is probably easier for the mappers, but ths would mean that the code has to translate the dB value given by the mapper into an actual distance to apply into the routine. This means more implementation affort and in addition is also a bit slower than the factor-approach.

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

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

How hard would it be to fix the player sound not using distances, but volumes instead like the AI? The "Min/max" radius of speakers has always caught us where something was cut-off just because you where 1 unit too far away.

 

I've been doing RL things this weekend, and that will continue today, but while away I've been thinking that the next thing I should test is slashing dB from sound volume at portals rather than slashing distance. I need to make sure that the speaker volume is readily available when crossing a portal (I think it is). If so, we can use the existing loss spawnargs for the player, but we'll still need a new entity for portals that's like the location separator but doesn't split locations.

 

This should make occlusion more realistic for the player, at least the ones that have larger min radii that tend to act weird around doors using the distance-only occlusion.

  • Like 1
Link to comment
Share on other sites

For instance, sound alway travels through the portal center. If you have a large or huge portal, the sound can take a much longer path to through the portal than it would actually. There is a forest testmap somewhere which used 100m portals to shut off parts of the forest for rendering, if you stand on the corner of the portal, net to an AI of the other side, the sound travels 50m to the center, then back 50 m to the AI.

 

Using the portal center depends on certain conditions (away from code, can't remember what), but most often it comes through at a point along the edge of a portal, at a spot nearest the player.

 

If you can remember which map is the "forest testmap", I'll see what conditions exist in that map to make the sound travel through the portal centers.

Link to comment
Share on other sites

A doors only occluding sound if they are touching a visportal? I'm asking this because you can't place visportals in a glass door (one you can look through).

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

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

A doors only occluding sound if they are touching a visportal? I'm asking this because you can't place visportals in a glass door (one you can look through).

 

yes, only if associated with a portal.

 

you can use a portal with a glass door. same as using it with a cell door (vault door prefab). there's an example of using a see-through door in the A-Z guide.

Link to comment
Share on other sites

OK. Will take a look at that. Thanks :smile:

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

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

This should make occlusion more realistic for the player, at least the ones that have larger min radii that tend to act weird around doors using the distance-only occlusion.

 

Will it be campatible with eavesdropping on closed doors? Will the DB-cut be vislble when using s_drawsounds 1 ?

 

edit: that's s_drawSpeakers -- sorry.

 

edit edit: NOOOOOO! It is in fact s_drawSounds! There is no and has never been a s_drawSpeakers in existence. This is not the cvar you are looking for. -- "This is not the cvar I am looking for." -- So it shall not be spoken or thought of henceforth.

Edited by plasticman
Link to comment
Share on other sites

you can use a portal with a glass door. same as using it with a cell door (vault door prefab). there's an example of using a see-through door in the A-Z guide.

I looked and didn't find it there. After some searching I ended up in the visportal tutorial. There is written

Openable doors that let you see through them such as windows, doors with windows, barred gates, etc. should not be in contact with a visportal.

I will make some tests myself to see if there is a workaround and post the results.

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

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

You're right. My assumption the past three years (!) has been, based on visportal use in the A-Z missions, that it somehow magically worked. The truth is that a portal near a door is just like any other portal, and is not controlled by the door being open or closed.

 

So, the answer to your original question is: Only doors associated with a portal can occlude sound. This means:

 

1 - View-blocking doors should have a visportal embedded in them for proper sound occlusion.

2 - A door that has an opening in it w/no glass (i.e. the cell vault prefab) can never occlude sound (which is fine).

3 - A door that includes a glass texture that you can see through can never occlude sound, because you can't put a portal through it.

 

For #3, since the door and portal aren't aware of each other, we'd need to create a new entity that knows about the door, and attach it to the portal. Then, the code could be changed to provide occlusion across a portal with a "nearby" door. Since a new entity is already on the table to provide occlusion across portals not associated with doors, this function could simply be added to that.

Link to comment
Share on other sites

Sounds good. :smie:

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

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

You're right. My assumption the past three years (!) has been, based on visportal use in the A-Z missions, that it somehow magically worked. The truth is that a portal near a door is just like any other portal, and is not controlled by the door being open or closed.

 

So, the answer to your original question is: Only doors associated with a portal can occlude sound. This means:

 

1 - View-blocking doors should have a visportal embedded in them for proper sound occlusion.

2 - A door that has an opening in it w/no glass (i.e. the cell vault prefab) can never occlude sound (which is fine).

3 - A door that includes a glass texture that you can see through can never occlude sound, because you can't put a portal through it.

 

For #3, since the door and portal aren't aware of each other, we'd need to create a new entity that knows about the door, and attach it to the portal. Then, the code could be changed to provide occlusion across a portal with a "nearby" door. Since a new entity is already on the table to provide occlusion across portals not associated with doors, this function could simply be added to that.

 

That sounds like a plan.

 

I think that doors need to have their own two factors for open/closed, because:

 

* if we put these on the door entities, they will work for every door+visportal near it (the portal doesn't need strictly to be embedded in the door, I think there is a small fudge factor so 1 unit away still works) also, whereas if you'd always need to put in an "info_soundloss" entity (whatever its name), then old maps would not gain this. And even new maps would always need an extra entity that isn't really needed as the two values as spawnargs on the door entity are enough.

 

* this opens up the possibility that you can modify this in real-time by interpolating between open/closed states on the door, e.g. a half-way open door occludes sound by 10%, while a 90% closed door occludes it by 80% etc. Even if you don't implement it right now, one can retrofit this via scripting. I'd be very interested in that concept. (Swift mazes already manipulates door speed from the scripting side).

 

* and I think the "partially see through door" needs this, anayway, because the visportal for these doors will have to be always open (e.g. the portal is 5 or so units away). If you have only "open/close" values on the visportal (set via an entity), then you'd always need something extra that tells the visportal to also use the "closed" value when the door is closed, which the code isn't even prepared to do. If the calculation for a visportal takes into account 1 value of the portal and 2 the value from the closest door and 3 the state of the door, then this could work for all combinations (portal open, portal closed, door open, door closed etc.)

 

Edit: In other words, it makes sense to put the info how much sound a door occludes when open/closed/halfway open on the door itself, not the visportal (think glass door vs. wood door - this has nothing to do with the visportal). The info how much a portal occludes sound needs to be put on the portal, tho (think small window vs. big archway - this has actually nothing to do with the door on the portal, nor the state of the portal). The final value is then a function of door occlusion (depending on door state) + visportal occlusion. The visportal state doesn't seem to come into play, because non-rendered visportals don't affect sound occlusion, and wether a door closed a visportal or not is already taken into account by the door state itself. That might already solve the "closed for rendering changes sound propagation" bug at the same time.

"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

Link to comment
Share on other sites

* if we put these on the door entities, they will work for every door+visportal near it (the portal doesn't need strictly to be embedded in the door, I think there is a small fudge factor so 1 unit away still works) also, whereas if you'd always need to put in an "info_soundloss" entity (whatever its name), then old maps would not gain this. And even new maps would always need an extra entity that isn't really needed as the two values as spawnargs on the door entity are enough.

 

It sounds like you want the door to behave as if the portal is touching it.

 

If that's correct, then we have to add code to let a door that isn't touching portals find the nearest portal at spawn time. But if the portal isn't touching the door, there's no guarantee they belong together. A portal found this way might even belong to a different door.

 

I'm not sure how this could be made to work correctly.

Link to comment
Share on other sites

Another point is that when you apply this to "classical" doors, too, thus meaning doors that can actually close visportals as you cannot see through them, would cause graphic errors when standing on the side were the visportal is closer to the player then the door. (This is quite obvious so maybe I misunderstood you).

 

My suggestion for the glass door thingy would be to use a new entity, that completely behaves like a door, with the only difference that it does not cause a visportal to be closed if the door is closed itself. The mapper would still have to place the visportal "inside" the door, what is, as grayman noted, much more failsafe.

 

Anyways, I second the argument that the sound occlussion caused by doors is something that, in a logical way, should be caused by spawnargs on the door. I also like the idea of partial sound occlusion caused by partially opened door. The question is if this would be worth the effort (both in terms of implementation as in terms of runtime calculation) as I'm not sure that players would really notice the difference. (sound occlusion caused by doors isn't that terrible high).

 

As we are just talking about what may be possible to implement: (beware :o ) Currently doors (and windows if implemented soon hopefully) does only apply an occlussion in terms of volume. Normally (in real life) such occlussion does also have an effect on the actual sound, or in other words the frequencies that pass through (I'm not sure this is understandable, so please tell me if not). Beside the obvious implementation effort the question would be if it is even possible to implement such a behaviour. Personally I think it would be a quite big push regarding the sound of TDM (that is quite good yet). Don't know how you think about it. Possible? Worth the effort? :rolleyes:

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

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

The DR editor comment for "sound_loss" says:

 

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

 

I read this as: add the dB loss from "sound_loss" to the dB loss from the "loss_open", "loss_closed", and "loss_doubleopen" values.

 

However, the code doesn't do this.

 

A portal only keeps one loss value.

 

When a location separator spawns, it sets that value to "sound_loss".

 

When a door opens, it sets that value to "loss_open", overwriting what was there before. No "cumulative" going on.

 

When a door closes, it sets that value to "loss_closed", overwriting what was there before. No "cumulative" going on.

 

So a location separator on a door's portal doesn't really contribute any sound loss at all, because its contribution gets lost as the door opens/closes.

 

A couple instances of this situation can be found in Alberic's Curse and Patently Dangerous, so we have a few spots where it's not working as the authors intended.

 

It looks like this is yet another sound bug that has to be fixed.

Link to comment
Share on other sites

My suggestion for the glass door thingy would be to use a new entity, that completely behaves like a door, with the only difference that it does not cause a visportal to be closed if the door is closed itself. The mapper would still have to place the visportal "inside" the door, what is, as grayman noted, much more failsafe.

 

Not sure what you mean. Example?

 

Anyways, I second the argument that the sound occlussion caused by doors is something that, in a logical way, should be caused by spawnargs on the door. I also like the idea of partial sound occlusion caused by partially opened door. The question is if this would be worth the effort (both in terms of implementation as in terms of runtime calculation) as I'm not sure that players would really notice the difference. (sound occlusion caused by doors isn't that terrible high).

 

I'm not planning to address that. It could be addressed later, though.

 

As we are just talking about what may be possible to implement: (beware :o ) Currently doors (and windows if implemented soon hopefully) does only apply an occlussion in terms of volume. Normally (in real life) such occlussion does also have an effect on the actual sound, or in other words the frequencies that pass through (I'm not sure this is understandable, so please tell me if not). Beside the obvious implementation effort the question would be if it is even possible to implement such a behaviour. Personally I think it would be a quite big push regarding the sound of TDM (that is quite good yet). Don't know how you think about it. Possible? Worth the effort? :rolleyes:

 

Also something I'm not planning to address. Existing EAX support might provide the frequency alteration you're talking about. Anything beyond that is prolly not worth the mathematical effort.

Link to comment
Share on other sites

That sounds like a plan.

 

 

 

* if we put these on the door entities, they will work for every door+visportal near it (the portal doesn't need strictly to be embedded in the door, I think there is a small fudge factor so 1 unit away still works) also, whereas if you'd always need to put in an "info_soundloss" entity (whatever its name), then old maps would not gain this. And even new maps would always need an extra entity that isn't really needed as the two values as spawnargs on the door entity are enough.

 

* this opens up the possibility that you can modify this in real-time by interpolating between open/closed states on the door, e.g. a half-way open door occludes sound by 10%, while a 90% closed door occludes it by 80% etc. Even if you don't implement it right now, one can retrofit this via scripting. I'd be very interested in that concept. (Swift mazes already manipulates door speed from the scripting side).

 

Seems old maps might be hard to account for. Whether or not they used portals on areas with glass doors and whatnot..

 

The sound interpolation based on open state sounds cool, it could possibly be tied into the texture fade based on open state we had discussed? :D

Dark is the sway that mows like a harvest

Link to comment
Share on other sites

Not sure what you mean. Example?

In the current state you cannot place a door that contains translucent parts (such as a glass window) in a visportal. Therefore the door cannot control the sound loss on that portal. My suggestion here is, that we could use a door entity, that behaves completely like a normal door, it opens/closes and set the sound loss on that portal, but it does not close it. The latter would be the only difference to the door entities we have now.

 

This way we could bypass the possible problems that may be caused by doors addressing the nearest portal.

 

Example: You have the door with glass. You close it. It sets the sound_loss to loss_closed but does not close the portal. So it effects sound but not rendering.

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

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

@Springheel,

 

Could you please review your use of "sound_loss" on location separators 1, 2, & 4 in A Score to Settle?

 

These guys aren't on doors.

 

What were you expecting to happen at those points? Sound loss whether they were open or closed? Only when closed?

 

How might it affect gameplay if sound is never occluded at those locations, since there are no doors?

Link to comment
Share on other sites

I'll have to look. That might have been part of an experiment to get a small portal to occlude more sound.

Link to comment
Share on other sites

That sounds more complicated than what I was proposing, which was to tie the door to the portal via a small entity you place on the portal.

Yes, maybe. But wouldn't it be possible to add a spawnarg on the door entities to tell them not to close portals. I actually don't know how the "door closes visportal" code works.

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

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
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.


  • Recent Status Updates

    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
×
×
  • Create New...