Thursday, February 17, 2011

First thoughts on OpenSim concurrency


At the weekend my home OpenSim grid had its third anniversary. This was celebrated by holding a masked Carnival ball on a wonderful Venetian themed sim complete with freebie costumes (cue picture; yup, that's me in the red playing wallflower). More to the point for an OpenSim newbie, the sim ran pretty well with 26 avatars inworld at one stage. A few dresses were sadly grey in parts due to missing textures but the dancing and music flowed more-or-less flawlessly for the hour or so that I was there. I'm well-aware that shared core sims can falter under relatively low loads so this (presumably) high end solution bode well for my own efforts to come.

Today I took my first tentative steps with a class of 20 students in OpenSim. I am renting a high-end server running bleeding edge 0.7.1 code so we can use shared media (though that will require using SL viewer 2 which I suspect is less stable in OpenSim so we stuck with Imprudence). I was in some trepidation, both because I seemed to be crashing the server on my ownsome for unexplained reasons (maybe the server is happier when used intensively or it just hates me?) and because I hadn't really had time to finish prepping the sim. I gave the students an introductory lecture so they had some idea of what was possible but also cautioned that this hands-on session was mainly just an avatar test-drive. I deliberately split the class in two to keep numbers down (the remainder are scheduled for next week when hopefully the sim will be more as I would wish it). I then split that half into four 5-person teams and allocated them a region per team to mirror the way the megaregion is setup. There's a reasonable amount of lag at sim crossings that can lead to problems if you cross too quickly so I put colour-coded walls between the sims both to facilitate orientation and discourage arbitrary crossings on foot. The students were reasonably restrained in their use of flight though there was, as ever, evident delight on first lift-off.

I preloaded and allocated the avatars (names, passwords and roles though we didn't get that far in this session, with group last names being simple colours to match the sim areas and the first names derived from the role; all very prosaic and non-immersive). Setting up the accounts from the console was pretty quick though clothing the avatars, installing a titler and setting their home took some time. We were very limited in the range of avatars (one male, two female) but the class seemed to take that in their stride and the titler (which showed avatar and student first name) may have helped. This new avatar site will be great when it's fully operational.

As the remote desktop used to monitor the server wasn't available on the university network, I took my laptop and wifi. Although the signal was perilously low in the PC centre we used, it did the job and, of course, the server never faltered during the 90 minute class. Better safe than sorry and maybe it's just my avatar it has issues with.

The major bugbear, in fact, was getting students onto the sim in the first place as the Imprudence viewer is not officially supported. My attempt to paste the path into the Run box failed for some reason on Windows 7 although it had been fine on XP. The backup was simply for each student to add the sim via the grid manager. I assume there's a way to do that "centrally" but at least the students came in OK after a slightly frustrating, not to mention fraught, start.

Performance on individual (low-end) machines was surprisingly variable. A small number of avatars remained as gas clouds and one student had trouble rezzing terrain textures though that was fixed by teleporting to an adjacent team's sim. I don't know whether the order in which people logged in made a difference but it's possible. The overwhelming majority of avatars performed adequately even if there was a some lag at times. The sim is pretty texture- and script-intensive so that wasn't entirely a surprise; I blame my predeliction for rezzers (cue second picture at bottom of page). Although I didn't get the opportunity to check on multiple machines, particles seemed to be a particular problem on mine. The occasional student machine had a client crash as well but that didn't seem to bother the students overly.

At the end (good timing!) all the viewers crashed simultaneously which I ascribed to a network or drive problem (which I hoped we weren't the cause of) as the server showed no signs of distress. Students were intrigued to hear that the software could all be run from a USB memory stick and that some elements of teamwork could in principle be sustained by merging individual contributions periodically.

Although this workshop was a self-selected option, it was great to see several of the students actively thinking how they could use this tech creatively and I greatly enjoyed the ensuing discussions.

My initial thoughts therefore were that addressing lag via high-end hardware had worked reasonably well. A class size of twenty equates pretty well with my previous use of SL. Next week hopefully more of the sim will function as it should and we can go beyond basic "mechanics" with the next group. And yes, I do intend using both viewers in one class so we can try shared media!

Monday, February 07, 2011

Non-musical chairs


I came across some camera control code and modified it so that it was triggered by having the avatar sit. To reduce lag in this shared core opensim region I've made the two multi-sculpted proteins temprez from the same script. The seat also IMs text from a notecard as it moves the avatar camera through positions likewise stored on the notecard. At the moment the cameras are simple prims that chat their position when prompted so the text can be copy/pasted to the notecard and then edited.

I don't have much time for developing/blogging at the moment so the demo is a little underwhelming with ad hoc camera positioning and no music -- but hopefully you get the idea. As ever, this is something students could do to annotate a build.

Blog Archive

Please note...

Second Life, Linden, inSL, SL, and SLurl are trademarks of Linden Research, Inc. As you might have suspected, this blog is in no way affiliated with that company. Moreover, the thoughts imparted here are, naturally, my own unless otherwise indicated and do not necessarily reflect those of my employer. Finally, I wish to assure readers that few if any unicorns were even mildly discomfitted in the production of this blog. Your mileage may, of course, vary.