Walls must be reduce voice range!

Many many versions ago they actually had something like this, only if I remember correctly you could only whisper to one person at a time.. Or maybe it was the other person had to accept the whisper and then when you chatted it was in whisper mode and others close by could hear the whispers, but the range was much less than chat. My memory is a bit hazey on this. It was in another lifetime.

Exactly. I'm all for having the parcel restriction to speech if it means it's available sooner. But the main problem IMO is that parcels force you to apply settings in a 2d way to a 3d space. They're limited, and most parcel settings are too restricted in this way.
Meh, I'm for any solution really so long as it's not so restricted as to be useless, the parcel idea is great for private homes so it's definitely a good start.

You could, like, actually use PRIM_MATERIAL for something other than changing the collision sound.
Either the client or the server can draw a line between the corresponding vertices of the av's bounding boxes, and if all 8 lines intercept PRIM_MATERIAL_STONE then you block avatars speech on channel 0. There's no need to get any fancier than that.

I think it'd have to be 6 or 7 of those lines. Remember the tiny cracks between prims.

The tiny cracks between prims only matter if both parties are precisely lined up so that one edge of BOTH bounding boxes are EXACTLY lined up with the SAME crack at the same time. The chance of even one being lined up that accurately is already remote. Trying to line both up even deliberately would be impossibly hard.

Hmm, I'm liking that idea, though it'd require me to go around setting all my materials more sensibly
I think you could add a meter or something that displays "Audio range" or something, so it gives a rating of the surroundings. If the distance is small then it's considered more private.

But um, this would have to be worked out between not only all avatars but also all listening objects, every time a message is sent? Unless it only worked in an enclosed space (in which case the client can tell the server, only these objects can hear me, or so)? It's still not the easiest thing to do I think, unless objects are assumed to be able to hear everything and it's only worked out for avatars? In this way the client can do that calculation and tell the server WHO can hear them, while the server then works out WHAT ELSE can hear them based on listens? That might be best.

I was thinking this would only want to be done for avatars, and only on channel 0 messages, because there's too many objects that use chat for control.

And, yes, the client could definitely do this since it's got all the information it needs at the time you hit return in the chat box, and with server support it could compress the list of avatars to as little as 8 bits per av (worst case, if you're at the corner of 4 sims, there could potentially be 200 avatars in listening range, which means you need 8 bits to enumerate them).

I don't think you'd need to enumerate 200 * 8 bits. If it's set up so that if ALL 8 need to be blocked (all 8 bits 0) then a simple logical-OR would solve the problem, as soon as one bit is set 1, all the rest are ignored (doesn't matter if they are blocked or not).
And besides, you only need to check for avs within listening range anyway (20m).

You need to be able to enumerate 200 avatars in the 4 sims. And of the avatars may be in range, and ones that are close may be blocked but ones further away aren't.

That is, let's say there's 15 avatars in draw distance that the server has designated 1, 2, 13, 17, and 30-42 (because the ones that were 3-16 and 18-29 have left to go to a poetry reading).
As it turns out: there's a rock wall between you and 17, 13, and 40-42; and 30-31 are 30 meters away.

The client could send to the server "\001\002\036\037\040\041...\000" (avatars not blocked), or "\001\002\040\041\042\043...\000" (avatars that should hear the say), or "\015\021\050\051\052\000" (avatars blocked). The last is probably most efficient since most of the time it's going to be a one byte string (just \000, null, the terminator).

Or you can send a bit string of 1 bit per avatar, up to 200 bits long, but that's only more efficient when there's more than 25 blocked avs in draw distance.
Yeh, but you don't want to have the server re-enumerate the avs every time the number in listening range changes, it's more efficient to have it just provide an ID for each av in draw distance when it first transmits that av's info to the client.

I suppose.

For the sound effects there's mention in the LSL Wiki about a sound-dampener that stops any sound from passing a point, but it says that it may be disabled.

- Jolan

hmm, it seems there would be an easier way, just enable people to change the range they speak at (I know I can change the rage my items listen at)

If you are in a room let them set it to 5m (maybe even just a toggle for the simpler people) manually.

maximum range something like 40 metres (a good club size)

Like the original poster of this message, I'd love to see speech indoors contained indoors. It's confusing to 'hear' voices from avatars you can even see. Not to mention the whole notion of being able to speak to folks in a room without worrying whether you're really alone or not.

It seems to me with all the cool things that LL has accomplished and managed to replicate in SL, finer-tuned restrictions on voice-carry distance could be done. It may not be easy but I wouldn't think coding any aspect of the program would be.

There is one problem with Skype Jolan and is also why i dont use team speak or anything like that for SL. You cant keep track of what was said or look back at it. once its said you have to ask can you repeat that please etc. It becomes a hassle in a meeting!!!

No it's not.

The occlusion system already traverses all the surrounding objects, so all it needs to do is to accumulate a heuristic for "how much I'm surrounded by obstacles" while it does so, and to pass the result periodically as a state parameter to the sound-dropoff algorithm.

Piece of cake.

Even when occlusion handling doesn't scan 360 degrees because of viewport optimization, this will still return a perfectly good dropoff heuristic.

OC only works on objects in front of you, everything outside of the camera's view is culled automatically, so to the OC system a completely closed room only has at most 3 walls since one of them must be behind you and therefore isn't considered, it just disappears. Besides, it divides things up based on a kind of grid/cube structure, if you have two rooms next to each other then one may not be culled at all because it's in the same cube that you are.

I thought it would be good for this too but it's not really well suited to it at all, since it's focus is on removing as many objects as possible that you can't see.

That's what I said:Physically accurate acoustics isn't what the thread originator asked for, but merely sound volume dropoff when indoors. Deriving a heuristic dropoff parameter from within the far-less-than-360 degrees of view frustum during OC would do exactly what's requested, and only a sound engineer would quibble with the lack of perfection.

Addendum: and if you want to make it slightly more physically accurate, then just cull occluded sound sources like you do occluded visuals. It'll make sound stop dead at walls rather than lose amplitude, but you may prefer that to the admittedly peculiar backwards dropoff on detecting a barrier in the forward direction.

I disagree with this statement.

I proposed a "Private chat on land feature - isolate land from external chat" version a while ago
/13/b2/67704/1.html

You're right, that calculation is a piece of cake. Unfortunately, it means doing prim penetration checks for each speaker-listener pair each time somebody says something. Let's look at this problem.

First, you can't just use the bounding box for the prim, because:
* prims can be hollow
* the avatar can be standing entirely inside the bounding box for a prim - in fact, for attenuation checks, this is likely to be true. The ray being cast would have to detect whether the speaker and the listener were inside the same prim to determine attenuation in that special case.
* bounding boxes can overlap, and frequently do.

Using just the bounding boxes for the prims would frequently result in instances where nobody could hear anybody say anything, because too many of them would overlap in a given volume of space, and where avatars were inside of buildings, the bounding box environment would create a puzzle impossible to solve in real time - which bounding boxes block sound? Which do not, and why? And when should these settings be overridden to facilitate expected transmission of sound.

So we've figured out we can't use prims' bounding boxes alone as the geometric criteria for blocking sound. It would work reasonably well if you were standing outside, but not inside buildings - and since we're hoping to have walls deaden sound inside buildings, that forces us to discard a pure bounding box approach altogether.

Now that we've had to discard bounding box tests, we have a new problem: we have to check intersection of the sound attentuation testing ray with every single polygon in the environment that might be between the speaker and the listener. To do this, we have to first determine which prims in the environment fall between the speaker and listener, and that's done with a mathematical contrivance called an octree. This is a subdivision of space, using rectangular prisms which divide the space into the most efficient possible volumes, for the purposes of determining what can and cannot be seen by a given avatar, and those volumes which can and cannot be passed through by that avatar.

So there needs to be an octree check performed by our sensing ray, traveling from speaker to listener, testing each prim encountered within each volume defined to determine whether that prim is intended to be a sound attenuating prim.

Ah, we're ready to make our determination!

But alas, we aren't - because avatars move constantly!! Any change in position of either avatar during the speech and listening process will invalidate the entire process and we must start again - because this would happen so often, the entire process would have to be repeated from scratch every single time anyone spoke. Further, it would have to perform this check in a sphere, 360 degrees on all three axis of possible direction to the listening avatar. This would have to be done no matter which way the avatar was facing.

"That sounds like a lot", you say, "but you only have to do it once per chat."

But again, alas, you don't. You have to perform this check for every single avatar, every time, in all directions, climbing through the octree and checking every single possible prim the testing ray might intersect and making a numercial evaluation of attentuation for each one to come up with a total attenuation for the chat - this on top of the hearing range test we're already doing now.

Now imagine trying to do this between two moving vehicles in a busy environment.

Nope, chat attenuation like what you're proposing isn't likely to happen. You'll have better luck asking for a "whisper" button to go with the "shout" button.

How about a check box on the prim->functions tab that blocks chat from passing thru it?
I'm sure clever people could fashion walls, doors, and windows that intersect to make an outside-chat-free zone... assuming chat isn't a lazy implementation of merely distance from the originator...

It's still a grossly disgusting mess. All you did is reduce the number of objects that need to be checked for ray intersection. It's the RAY CASTING itself that takes the most time.

Many many versions ago there was a whisper option

It would disappoint some people that that hot female avatar has a VERY deep voice.

I believe the numbers are that 1 in every 2 female characters is a male player and that 1 in every 200? male characters is a female player. Don't know if these stats were inclusive of SL or actual MMOs in general (i.e. WoW + Eve + EQ + few others = Stats or WoW + Eve + EQ + few others + SL = Stats).