a couple of weeks ago i blogged about our rather sobering tests with real avatars and that we run into serious trouble round about the 21 avatar mark. alan webb, arthur valadares, and i started looking at the what could possibly be biting us there.

having profiled opensim (albeit briefly, you end up with lots of data), arthur had found out that a lot of time was spend in the packet handling code, so we concentrated on the packet and textures handling — hypothesis #2 being that the on-rush of avatars trying to log in all at ance (and being logged in almost all at once) was causing a massive spike in textures demand: alan “outsourced” the texture handling to a thread of its own instead of having it part of the normal packet handling. arthur and i were successful in getting rid of a number of short-lived mass object instantiations.

the result: well, with even more vicious bots (20 of those new ones were sufficient to bring opensim to a stand-still now, similar to real avatars) we now managed to go up to 40 avatars! sure the region became laggy, but, and that is important, we could still use the in-world tools, could still move around, chat and work.

so, progress. now to figure out why massive amounts of collision events reported via LSL cause a deep ODE physics engine crash…

this morning i finally could push our VivoxVoiceModule into opensim trunk. we had been using it internally for almost three month as part of the Sametime3D project but only now got the necessary legal “paperwork” done so that we could finally release it into the wild!

VivoxVoiceModule works with the same voice technology which Linden Labs are using for their SecondLife virtual world — and, what’s even nicer, it plays along rather well with recent SecondLife clients (anything from 1.22.9 onwards), meaning you get full spatial sound, speaker indication, direct avatar-to-avatar voice chats, the works, without having to configure anything  client side.  you can even — in contrast to Linden Labs SecondLife grid — switch from spatial voice to conference call style voice channels, or change the range of voice, how quickly it fades, and so forth (all explained in OpenSim.ini.example). voice quality is superb — except for those occasions where we muck around with the grid itself (and thus cannot use in-world voice), we use it instead of conference calls and have been using it for a couple of months now.

VivoxVoiceModule does require a vivox voice server to talk to — which means that you need to obtain a customer admin account (IIRC) from vivox. as i don’t work for vivox (alan webb and i just wrote the module, nothing else), i can’t provide any further information on how to go about obtaining such an account nor can i tell you how it will cost. there are rumours on the opensim-dev mailing list that adam frisby has a bunch of licenses from vivox for OSgrid, again, i know no details.