|
|
|
[
Permlink
| « Hide
]
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.
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. 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.
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. 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. 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. 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-
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. 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.
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.
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. 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. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||