Problems with The Dark Mod 1.04

[eigenface]

Visual and audio are both controlled by visportals. There should be separate visportals and audportals. This is a problem with the editor, but it affects the player experience as well.

 

Often, sound propagation is odd. Sounds come directly from solid walls. Actually, it comes from the sound source on the other side, but the sound is not routed around the wall because the mapper did not place visportals. The mapper did not place visportals because there was no need to, from a graphical performance standpoint (the original point of visportals.)

 

Consider a short passage with a bend or two, and doors at each end. While you're in the passage, sounds from AI also in the passage will not follow the passage - the sounds will travel through the walls directly to the player. Unless the mapper adds several extra visportals inside the passage. But excessive visportal use can actually decrease performance (right?) - there is no need to place several visportals in the passage, from a graphical performance standpoint. The mapper should be able to place audportals in the passage instead.

 

Also, visportals should not automatically be audportals as well. Consider a large, dark open area, with visportals in "artificial" locations. By "artificial" I mean visportals are not on doors or small openings between larger areas; for example, distance-based visportals could be placed between trees in a forest or between pillars in a large temple, purely to break up the space for graphical performance reasons. This would unintentionally create strange sound directions because sounds would propagate from one visportal to the next, instead of straight from the source to the player as one would expect in a large open area. The mapper should be free to place visportals without worrying about sound propagation.

 

Does this makes sense? Is it plausible from a coding standpoint to have separate visportals and audportals?

 

Perhaps unifying visportals and audportals was meant to simplify the process of map creation, for those not interested in the differences. That's fair enough. Would it be possible to use this solution:

 

Keep the existing visportals exactly the same, that is, affecting both visuals and audio. And then also add 2 new objects to dark radiant (say "simplevisportal" and "simpleaudportal") which affect only visual or audio respectively, for those that want to use them separately.

Edited March 22, 2011 by eigenface

[nbohr1more]

That is a similar request as:

 

http://bugs.angua.at/view.php?id=1188

[eigenface]

Hmm, not sure I like the direction of the forum thread linked in that bug. They seem to be talking about adding a special-case solution for glass doors, instead of a general-purpose solution that also works in the examples I mention. Separate visportals and audportals would fix all the cases, including glass doors (audportal only.)

[Sotha]

I'm not thrilled by audportals, as visportalling takes care of the majority of the sound propagation. My mapping experience makes me feel visportals are perfectly enough. However if an addition suggestion is needed, I'd like doors to have spawnargs which could control the associated visportal behavior.

 

For example, a door could have a spawnarg never_close_visportal, which could be used to keep the VP open even if the door is closed. Might work for glass doors and doors with windows and the sound blocking could still work.

 

Edit:

Heh.. thats exactly the thing the bugrep considers. Sounds perfectly reasonable to me.

[Tels]

I'm not thrilled by audportals, as visportalling takes care of the majority of the sound propagation. My mapping experience makes me feel visportals are perfectly enough. However if an addition suggestion is needed, I'd like doors to have spawnargs which could control the associated visportal behavior.

 

For example, a door could have a spawnarg never_close_visportal, which could be used to keep the VP open even if the door is closed. Might work for glass doors and doors with windows and the sound blocking could still work.

 

Edit:

Heh.. thats exactly the thing the bugrep considers. Sounds perfectly reasonable to me.

 

I think eigenface has a point. The spawnarg might be easily added, but it still does not solve the two other problems: you might have a need to place excessive visportals just to get audio right (bend tunnel!), and you might have visportals which affect audio but shouldn't (open forest).

 

The first case is not so about performance (a visportal or two more won't kill the map, an additional AI does use much more performance), but about errors in maps due to mapper error/not enough knowledge.

 

Edit:

 

Might work for glass doors and doors with windows and the sound blocking could still work.

 

I thinkt that was exactly the point, if the visportal is open, it won't reduce/block/muffle the sound?

[New Horizon]

It would definitely be useful to have an audio portal only solution. Would it be possible to create a new 'audio-only' setting for vis-portals that would force them to only do the audio work...or if it's more straight forward for mappers, an additional audio-portal option? The first suggestion might be less confusing overall since vis-portals would have to keep their existing functionality in order to not break existing maps. So if a mapper needed additional vis-portals to properly propagate the audio, they could place some vis-portals and place a setting on them to make audio only, no vis calculations.

[grayman]

So if a mapper needed additional vis-portals to properly propagate the audio, they could place some vis-portals and place a setting on them to make audio only, no vis calculations.

 

We would need to use a different texture than 'visportal' on the new audio-only portals, otherwise dmap will treat them as normal visportals and cut up the map anyway.

[New Horizon]

Ahhh, ok. So that's how it's handled.

 

So I guess the only way to do it would be to allow vis-portals to still function the way they do, but to allow mappers to place additional audio-portals when needed. I had brought up the idea maybe a year or two ago myself...if it's possible, I still think it would be a very useful function for mappers.

 

Basically, vis-portals block out the basics of sound prop, and audio-portals would then be used to fine tune the rest.

[Springheel]

I don't see any obvious problems with using visportals to control sound. I would like to see a "sound_loss" property on visportals that worked for player sounds, however.

 

If mappers had control over the sound_loss of visportals, I can't see why there would be a need for special "aud-portals".

 

Granted, good sound control requires mappers to know what they're doing (and check for internal leaks) but that's par for the course.

[New Horizon]

I don't see any obvious problems with using visportals to control sound. I would like to see a "sound_loss" property on visportals that worked for player sounds, however.

 

That would be helpful too, yes, but I think an audio portal could also be helpful in allowing mappers to place vis-portals only where absolutely necessary, and then be able to flesh out the sound design.

[Springheel]

but I think an audio portal could also be helpful in allowing mappers to place vis-portals only where absolutely necessary

 

What would be an example of a case where mappers might want to use an "audportal" and couldn't use a visportal to accomplish the same thing? I can't think of one right now.

[New Horizon]

Eigenface and Tels had some examples further back, but from my point of view it would simply allow better mapper control and sound design. Sound was handled separately from vis in all the Thief games, if I recall correctly, so by allowing for separate placement you wouldn't need to place a visportal where there was no need for one. The current system is good, but I think an extra layer of control could certainly make it that much better...and it wouldn't break existing maps.

 

I noticed that eigenface actually took it a step further by suggesting a 'simple-vis' and 'simple-aud'.

 

I might whip out my C++ book and take a little walk through the source code to see if it's something within my abilities to experiment with.

[Baddcog]

Well, TF2 automatically leafed and culled the visual stuff. Much like Hammer does. (Hammer has an addition of being able to add portals to further optimize culling - Radiant requires it and is the only culling method)

 

TF2's sound was controlled by adding rooms around all player areas. Quite a task in a large mission. and not without issues (try adding square sound areas to round rooms, the sound easily leaks to outside the round room)

 

The propogation was handled through multiple rooms. So if you have a very large room, you put several small sound brushes in so the sound was quieter at the far side of the room.

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

 

Anyway.

 

I really don't see how sound portals would make it any better. What we DO need is what Spring suggested, controlling sound loss through portals (so you can have glass break sound).

 

You can't just add a portal between 2 trees and have it work visually or sound wise. It has to seal on all 4 sides. So if you have a very large open area the only way to seal it is to have a tight 'doorway' (cave, building, etc...) at each entrance to the area.

 

And the sound will travel through that. But in the open area sound will travel properly from source to player. Huge visportals are tough to close anyway, so having them in huge open areas really doesn't make sense. I used some pretty large ones in the Rift, but they basically only close after a second small portal in a tight area is crossed. Hence the exact reason why putting multiple small portals in tight curvy tunnels is so important.

 

So if you have large open areas, expect the sound to travel properly straight to player, and plan your optimizing by having tight narrow entrances to the point.

 

And use the tight twisty tunnels to your benefit and definitely add several portals in them.

 

=======

to add...

 

If visportals take processing power than so would audio portals. So replacing one for another, would that really help anyway? And with 'audio only' you lose the major benefit of vis portals, which is culling the unseen visuals.

 

So you're not getting a overhead performance improvement but you're losing an optimizing technique.

[New Horizon]

I didn't think the issue was so much about using sound portals in large areas, as it was about 1. being able to use vis where only absolutely necessary, and 2. being able to place sound portals with sound exclusively in mind.

 

In any case, I now have a better understanding of how it works.

 

The sound loss setting sounds ideal though. Just a thought on controlling the sound loss through open portals though. Rather than always having to place it manually, would it be possible to have the sound loss automatically adjusted based on the size of the visportal? Once you get to a certain size there would be no loss, but perhaps a baseline might be a set of 'open'double doors. As they get smaller than that, the sound loss is scaled accordingly.

 

Anyway, yeah, I see where the sound loss setting would be more beneficial now.

[Tels]

What would be an example of a case where mappers might want to use an "audportal" and couldn't use a visportal to accomplish the same thing? I can't think of one right now.

 

Visportals automatically split terrain into two areas. I am not sure if it would be possible for an audio portal to NOT do the split, but still work correctly for sound travels - as the code might not know the audio portal is there at all.

 

But if it works, then there might be a benefit for using an audio portal instead of a visportal. (e.g. no split of the world, you don't need an extra portal_info entity just to feed the settings etc.)

 

You are probably right, tho, one type of portal with appr. sound spawnargs would be probably enough.

[Baddcog]

I don't think in most cases the extra splits in world geometry are worth worrying about. Most geometry should be func_staticed anyway, and that won't be split by portals. Most of the time portals are places in areas like doorways that will probably be split anyway.

 

Sure there's the possibility that it wall add a few more lights per some tris, but might also make fewer. 50./50

[demagogue]

I agree a working sound_loss spawnarg would take care of micromanaging the sound-flow well enough. If you have walls, L-shaped halls, big brush obstructions, etc, you should be using visPortals anyway... and the big missing piece is walls with holes and windows which let in all the light but not all the sound, which sound_loss addresses.

 

And yeah, the VP method is better than the old room method from Thief et al, since if you can make a room you can make a leaf, but a leaf's area doesn't have to only be a rectangular box. I guess the room method was notable in forcing no-leaks (so could have silent patches, in the world but out of a room), but if you're building with leaks like that it's probably bad design anyway.

 

(I also like how our ambient sound is set up to leaf's now too. In Thief, since it was a proximity trigger, you could stumble into the ambient from the other side of a wall, long before you reached the room. I remember dramatic music suddenly playing on an empty street for no reason because of that, lol.)

[Tels]

In any way, we do not have the source for the sound system (e.g. the player audible sounds), so we cannot modify them, anyway.

 

The only thing we could do would be write out own sound class, that:

 

* places "virtual" speakers either inside the current area, or somewhere in the face of one of the visportals to the next area. (All sound that the player hears must come from either inside the current area, or through a visportal

* adjusts the volume of these speakers according to:

** visportal size, distance to the player, distance traveled through other visportals etc. (speakers outside the current room that are not loud enough to be heard by the player can be skipped).

 

Basically it amounts to rewrite the id soundsystem from scratch, but using their sounds system to output the actual sound.

 

I am pretty sure this would allow for very sophisticated effects, but at the moment we do not have any manpower to even attempt this.

[New Horizon]

In any way, we do not have the source for the sound system (e.g. the player audible sounds), so we cannot modify them, anyway.

 

I'm confused...

 

Correct me if I'm wrong about any of this.

 

My understanding is that visportals will reduce sound when they are closed, but if the visportal is open it will not call on that same closed portal function to reduce the sound of an open portal? Correct?

So there's no way we can tell a visportal to act as if it's closed (applying sound loss) while the player is looking through it, yet still render the scene?

 

They added a lot of different types of portals to Enemy Territory: Quake Wars. Audio portals being among them. It is too bad we don't have the adequate source code to put them in.

 

http://wiki.splashdamage.com/index.php/Portal_Basics#audioportal

[Tels]

I'm confused...

 

Correct me if I'm wrong about any of this.

 

My understanding is that visportals will reduce sound when they are closed, but if the visportal is open it will not call on that same closed portal function to reduce the sound of an open portal? Correct?

So there's no way we can tell a visportal to act as if it's closed (applying sound loss) while the player is looking through it, yet still render the scene?

 

As far as I understand it, yes.

 

They added a lot of different types of portals to Enemy Territory: Quake Wars. Audio portals being among them. It is too bad we don't have the adequate source code to put them in.

 

http://wiki.splashdamage.com/index.php/Portal_Basics#audioportal

 

J.C. Denton already asked why we don't switch to this engine, as it is quite compatible, but has a lot of improvements. Unfortunately, I do not think we have the manpower anymore... but it would solve a lot of issues (like instancing, megatextures etc.) The other option is to wait for id open source, and then re-implement them ourselves.

[Springheel]

My understanding is that visportals will reduce sound when they are closed, but if the visportal is open it will not call on that same closed portal function to reduce the sound of an open portal? Correct?

 

Yes, grayman and I have both confirmed that.

[demagogue]

The other option is to wait for id open source, and then re-implement them ourselves.

 

Well the nice thing about this is that some of the Doom3World guys may do the work of porting these improvements into Doom 3, making it much easier for us to coattail on their work. I just suspect there's going to be a rush of work on vanilla Doom 3 when the tech goes open source by a lot of people, and we can benefit from it.

[Tels]

Well the nice thing about this is that some of the Doom3World guys may do the work of porting these improvements into Doom 3, making it much easier for us to coattail on their work. I just suspect there's going to be a rush of work on vanilla Doom 3 when the tech goes open source by a lot of people, and we can benefit from it.

 

"Hopes dies last"

[New Horizon]

I just suspect there's going to be a rush of work on vanilla Doom 3 when the tech goes open source by a lot of people, and we can benefit from it.

 

Oh, absolutely. There are guys sitting over there just itching to fix some of the long standing issues with modding.

[eigenface]

I wonder which idtech4 they're going to open source - the original doom 3 version, the more advanced quake wars version, probably not the even more advanced prey version... hmm.