• All submissions to this site are governed by Second Life Project Contribution Agreement. By submitting patches and other information using this site, you acknowledge that you have read, understood, and agreed to those terms.
Issue Details (XML | Word | Printable)

Key: VWR-478
Type: New Feature New Feature
Status: Open Open
Priority: Low Low
Assignee: Unassigned
Reporter: StarSong Bright
Votes: 19
Watchers: 3
Operations

If you were logged in you would be able to see more operations.
1. Second Life Viewer - VWR

Create the ability to dampen sound with walls

Created: 18/Apr/07 04:19 AM   Updated: 27/Apr/08 04:44 AM
Return to search
Component/s: Building (in-world)
Affects Version/s: None
Fix Version/s: None

Issue Links:
Duplicate
 
Relates
 


 Description  « Hide
Privacy is a MAJOR problem in SL! 20 meters is a long way and when voices carry like that right through walls it can be VERY intrusive. I would like to see a check box added to the objects for "dampen sound". Even if it just dropped your "voice" off at 5 meters (like a whisper) instead of 20 it would make a huge difference. It would improve multiple story buildings and rentals quite a bit.

Even if it had to be a special purpose prim - it would waste prims but I think people would use it anyways. It would be better if was incorporated as sound dampening for existing prims.



 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Lex Neva added a comment - 18/Apr/07 08:57 AM
This is MUCH harder to implement than you think. It's likely to be nigh impossible to do something like this while still retaining a decent client framerate.

Rita Cummings added a comment - 28/Apr/07 01:36 AM
I have no idea of how hard this would be but they eliminate prims from rendering if they are behind other prims in certain conditions, why would it be much harder for sounds?
And there are way less sounds than prims.

Daedalus Young added a comment - 30/Apr/07 04:34 PM
At least a quick fix would be to have the option to restrict text to a parcel. If I understood correctly, this is possible for the new voice chat, so adding it for text would not be too hard, I'd say.

Saii Hallard added a comment - 06/Jun/07 08:35 AM
Interesting feature.... It would give the possibility to make 'sound shields', so women can walk around without hearing 'hi sexy' all day =)

But i also think this is very difficult to make without loosing a lot of performance.
I would suggest to be able to change channel for normal chat or making a small option to adjust the chat range. That should be do-able


darling brody added a comment - 06/Jun/07 06:19 PM
Right there with you Saii Hallard !

Seriously now, the ability to block text chat the way we can block sound using a parcel of land would be far more usefull than a sound proof prim. It will not work verticaly of course, but will help if you have spammy neighbours running casinos too.

A Whisper button beside the Say and Shout buttons on the viewer would be nice alternative too.

I will list this a a new suggestion too. i think blocking regular chat on a parcel like we block sound deserves consideration.


Ironton Furse added a comment - 30/Jun/07 12:39 PM
PLEASE! OH, PLEASE! ADD THIS FEATURE!

My neighbor and I have our houses very close to each other. I am able to set my land to not hear actual sounds from his land and for him not to hear sounds from my land, and If I don't want to be easily looked at I can place a privacy wall between us, but chat is a different story. Last month he was in his bedroom with his girlfriend talking dirty, and I was receiving every word that was said. I could either ignore the chat as it rolled up my screen or be forced to walk to 20 meters away from them.
If one of us were able to have a sound dampening wall between the houses, this wouldn't be a problem.


Hewee Zetkin added a comment - 31/Jul/07 02:19 AM
A simple solution that might address this in great part is to add a whisper feature to the official client. There are existing clients that allow users-not just scripted objects-to whisper.

LaeMi Qian added a comment - 08/Aug/07 01:42 AM
Parcel-bounds chat-clipping would be a good way to solve this on the horizontal planes. Possibly a parcel option for 'vertical-chat-attenuation' would solve the high-rise issue.

Default is 100% (20m-chat / 50m-shout range on the vertical). But the parcel owner could set it to, say, 20% so that anyone more than 4m (10m-shout) above or below the speaker (ie, not on the same floor) would be out-of-range and not receive the chat.


Alpha Manatiso added a comment - 21/Mar/08 04:31 PM
Agreed. It would seem to give apartments, for example, greater privacy. It would certainly reduce the ammount of embarrasment in hearing everyone else's chat. You would be able to "talk dirty" without everyone getting it as well.

Colin Kiernan added a comment - 13/Apr/08 12:50 PM
This wouldn't take much processing power to implement. Just calculate the line between the speaker and listener and see which prims it intersects. It wouldn't even be too bad to do sound bouncing off prims and things like that, it's just basically ray-tracing but with sound. Yes, I know ray-tracing is very expensive but that's because it needs to trace a ray for each pixel on the screen. Here it would only need a ray for each person hearing the sound, which is probably not going to be more than 20 or 30 at the most.

Aimee Trescothick added a comment - 13/Apr/08 06:25 PM - edited
I'm writing ray tracing software for audio spacialization applications at the moment. So this is actually something I've been thinking about applying to SL for a while. My work is dealing with a few thousand rays from each source, each with thirty or more reflections to generate fairly accurate reverberation, attenuation and source location (e.g. you hear someone outside through the doorway not in a straight line). However if we are just dealing with occlusive attenuation and not concerned with reflection, diffusion or refraction, this need not be anywhere near that complex.

Processing it on the client you only have one listener to be concerned with, so you just need to trace one ray from each possible voice source to the listener. The first fly in the ointment I can think of is that it would rely on the client having all the geometry between source and listener loaded. Since the server side interest list is based on the viewer's camera frustum, If the source happens to be off screen then the occluding geometry is likely not going to be loaded.

The second is that doing it client side would not provide real privacy, it would be useful more for avoiding stuff you don't want to hear, rather than protecting against being overheard. It would not guard against deliberate eavesdropping as it could easily be bypassed in the client, which might mislead people into thinking they have real privacy with they don't.

Proper privacy would have to be catered for server side, which then involves the server having to trace rays from each source to each listener, and prevent audio being streamed to the client at all if the path is occluded.

So with say only three people talking and 20-30 listeners (including the speakers) that then becomes 60-90 rays (well, technically a couple under that). As any of those listeners could start talking at any time though, you need to trace all the possible paths in advance, so you need to trace a path between every pair which then becomes 200-450 rays.

An additional load on the server, though not necessarily excessive. Compared to ray-tracing in graphics, which in basic form, traces two rays for each pixel (with a single light source) that's equivalent to producing an image of only between 14x14 to 21x21 pixels in size. Add to that the fact that for the purpose of determining acoustic occlusion a relatively low update rate of say once or twice a second will suffice and it seems quite feasible.


Aimee Trescothick added a comment - 15/Apr/08 10:04 AM
There would would also be an additional dividend to all this, a reduction in load on the voice servers as they are streaming less, and a corresponding reduction in network traffic.

Also, just to clarify, I am talking solely about voice, not about any other audio, which is handled separately.