Recently, the page about performance in the Opensim wiki has been extensively updated, and this prompted me to gather some data for Condensation Land, a mini virtual world powered by Opensim which I administer, to be able to add this data to the page. Condensation Land is special in the sense that while it’s a quite small, home-based, world, at the same time it hosts a relatively big number of prims and scripts, and I thought that adding that data to the page might end up being useful to somebody.
When collecting the data I had to visit all the islands, one by one, and this made me remember the story of Condensation Land, how it all started, the things we did there, the people who have contributed wonderful stuff to be displayed, and I thought I’d write a blog post listing and commenting detailedly the technical data I had gathered, and at the same time giving an account of the history of the mini-world.
I’m proud to announce that we have three new islands in Condensation Land: Temple (secondlife://condensationland.com:9000:Temple), AngelicoMiguelis (secondlife://condensationland.com:9000:AngelicoMiguelis) and Conceptior (secondlife://condensationland.com:9000:Conceptior).
Surprisingly, Opensim fares quite better than SL in that respect
[See the list of updates at the end of the article]
A Google Buzz by Mo Hax alerted me of the existence of an article in PC Pro containing yet another interview to M Linden. M explains there that SL is being used for “meetings”, as a “virtual collaboration tool”, and that it provides “incredible savings”. This is not new. If you google for “Second Life Education”, the second hit leads you to “How Education Enterprises Use Virtual Worlds“, a page by LL detailing how great is SL for educators. Similarly, the Second Life Blogs are full of references to SL as a tool for educators. For example, in a one year old article, As Seen on CNBC: New IBM Case Study Showcases Value of Meeting Inworld, Amanda Linden compares Second Life to Webex and says that Second Life “creates a [more] immersive experience”.
Does really “immersion” provide an advantage for online meetings? Is “immersion” something that can be asked of somebody, a student or an employee, for example? What is the cost of being able to offer “immersion”, and how does it relate to the supposed benefits? Are Second Life/Opensim and other tools, like Webex, comparable? If yes, how do Second Life and Opensim fare when compared to them?
In this post I will try to address these questions. To do so, I will use two strategies: on the one hand, I will make a product comparison between SL, Opensim and Webex, comparing features, price, quality of technical support, etc: on the other hand, I will resort to my own experience: I have been working for companies that have used Second Life and Opensim for education and meetings for more than two years, and I’ll share some of the things I have observed. Continue reading
I’m reproducing below in its entirety a post by Peter Stindberg. I’ve seen many people from Opensim grids, specially from OSGrid, in Avatars United. Peter’s post identified a potential security breach in Avatars United by which a malicious application could harvest avatar-email associations. Apart from the exposure to spam, this can lead to disclosure of RL details for those who are using RL email addresses in association with their avatars.
[Start of Peter’s post]
For those of you using their RL-email for their SL-avatar, using the default settings of Avatars United might pose a risk of unintentional exposing the address!
Snickers Snook posted an insightful article about “Spam via Avatars United“, where she explained that since joining AU she receives significantly more spam on her supposedly undisclosed email address. She dug a bit into the settings and found that the default is that even non-installed AU-widgets can access certain data and send emails.
While Snickers primarily saw the spam problem, my friend Zonja Capalini pointed out that while being spammed is a nuisance, the bigger threat lies in the unsolicited disclosure of a potential RL email address and thus disclosure of the RL identity.
So if this concerns you, do two things:
- Read Snickers article and adjust your Avatars United settings
- Go and finally get a GMail/Yahoo/Hotmail/whatever address for your avatar
[End of Peter’s post]
Como explica muy bien Albert en su blog. Para mí es una suerte y un privilegio cooperar con estos compañeros fantásticos via internet, y, de cuando en cuando, en persona. Del post de Albert lo suscribo todo, o sea que no repetiré lo mismo aquí — sólo hay una cosa que me ha dejado pensando.
Dice Albert “Zonja Capalini, que combina sus bikinis diminutos pero tiene la cabeza realmente bien amueblada”. Las negritas son mías. El DRAE define “pero” como una “conjunción adversativa usada para contraponer un concepto a otro diverso o ampliativo del anterior”. Entonces, ¿bikinis diminutos “pero” cabeza bien amueblada? ¿Qué querrá decir? Lo de la cabeza bien amueblada se lo agradezco de corazón, pero la verdad, no creo que me vuelva más tonta cuando me pongo un bikini… ;-)
One of the most interesting developments in Opensim lately have been megaregions. Megaregions are non-standard “big” regions created by combining several standard, 256×256 meters regions. For example, you can combine four standard regions in a square to get a megaregion of 512×512 m. Megaregions are very convenient because of several reasons: for example the usual lag in region crossings disappears completely (since you are in the “same” region), and the same is true of vehicles. On the other hand, megaregion support is still experimental, and a number of things that work in normal regions don’t work or work only partially in megaregions. For example, you cannot define parcels outside of the SW region (this is due to the way parcel maps work), and therefore you can’t have independent music streams (for example) when x > 256 or y > 256.
Diva Canto’s distribution of Opensim directly supports megaregions. You can also migrate an existing non-megaregion installation to a megaregion configuration, if you follow certain precautions. Migrating from a megaregion configuration to a non-megaregion configuration is also possible — you change the setting that implements megaregions, “CombineContiguousRegions” to false, and it works as expected.
OAR support for megaregions is partial: since technically all the objects in the megaregion are stored in the SW region, when you take an OAR of the SW region you get all the objects of the megaregion but only the terrain for that same region — this means that you cannot fully rebuild a megaregion from an OAR, which is a pity (you will be missing the terrain files for all regions except the SW one).
In this post I’ll describe some experiments I made with an OAR manipulation tool I developped following a suggestion of Stefan Andersson. The tool takes as its input a megaregion OAR and splits it into several non-megaregion OARs, creating one OAR for each region that constitutes the megaregion and has objects in it. This is so because megaregions may have holes, and when a possible region does not have objects there’s simply no information in the megaregion OAR about whether a it’s a region with no objects (for example, a sea-only region) or a hole in the megaregion.
The XML2 format
The XML2 format is used in Opensim to serialize objects or linksets (called “SceneObjectGroups” in the Opensim parlance). XML2 dumps of objects can be obtained using the ‘save xml2’ or ‘save prims xml2’ console commands, and are used internally to serialize objects in Opensim Archive (OAR) and Inventory Archive (IAR) files. For example, OARs are gzipped tar files containing a directory called ‘objects’ with one XML2 file for each linkset in the region.
XML2 files are standard XML files using an ASCII encoding and no whitespace. This means that there’s no extra indenting or formatting between tags to make the file more pleasant to the eye. You can use any XML editor (including Internet Explorer) to display an XML2 file with some additional prettyprinting and formatting.
XML2 is practically undocumented, but the fact that it’s undocumented is itself (informally) documented :-), in comments scattered through the Opensim wiki and in the Opensim-dev and Opensim-users lists. Essentially, what this means is that the format is subject to change, but not much change: attributes (i.e., new tags) may be added to the format without breaking it — the developers program the classes taking this possibility into account and storing default values when an attribute is expected but not present (for example, if you’re loading an old OAR file which does not have the ‘AllowedDrop’ attribute into a newer installation which does have this attribute).
In this article I document partially the structure of XML2 files using a variant of the BNF notation. I include the productions for most of the format, interspersing comments wherever I have some idea of the meaning of the tag contents. I’ve obtained this information by manually looking at the XML2 files when developing the simple OAR editor I called ZOE and in recent modifications to that editor. I’ve also taken a look at the source code for Opensim and at the code for libopenmetaverse. There may be errors and there are for sure omissions; any kind of comment, addition, correction or clarification would be greatly appreciated.
The whole SceneObjectGroup/SceneObjectPart model is about to be heavily refactored to be able to include very cool things like hyerarchical objects or meshes, and this will most probably require a new format (XML3?) to serialize Opensim objects. I am writing this article as a way to teach myself, and I’m making it public in case somebody else can find its contents useful. Please keep in mind at all times that this is not official documentation :-) — that’s one of the reasons why this appears as a blog article instead as a page in the Opensim wiki, the other being that I’d prefer to get some feedback before writing such a complicated wiki page, in case it’s considered useful to have it.
In this long overdue post, I introduce “Mirror Worlds”, an eternal (I will explain what I understand by ‘eternal’ in a minute) art exhibition located in the Opensim-based, hypergrid accesible, Condensation Land grid. The exhibition features pictures from Florence Babenco, Monika Finchy, Shoshisn Shilova, and Senna (SennaSpirit) Coronet, and from the Condensation Land residents Ludmilla Writer, Mikil Tiki and myself. Shoshisn also has contributed several of her wonderful sculptures for the exhibition.
Art exhibitions of all sorts are very common in Second Life, but unfortunately they are more unusual in the Opensim-based worlds — and, in case they exist at all, they get little or no publicity. Which is a real pity, because, contrary to the general lack of content for avatar clothing and embellishment in Opensim, for example, there is nothing which prevents Opensim-based worlds from hosting beautiful exhibitions. Nobody will ask where did you take a picture, after all — and texture uploads can’t be cheaper :-)
In this post I’ll present the exhibition and explain some of its more unusual features. I’ll also describe some of the difficulties that I encountered in my work as an amateur curator — some of these difficulties may be due to my inexperience at the task, but I think that the other ones may help as a diagnosis of some problems the Opensim movement is facing. Continue reading
As I noted in my previous post “Moving and rotating OARs“, offline editing of Opensim Archives (OARs) opens a lot of interesting possibilities. In this article I present the results of several simple tests I have made by extending my “Zoe” OAR editor so that it supports (a very simplified sub-dialect of) SQL. Even in a simplified form, SQL has a lot of expressive power and allows to perform a number of pretty neat operation on OARs, when it comes to selecting and deleting parts of a region. Updating OARs, though, is much more complicated, because there is no “natural” semantics to apply when using the standard SQL UPDATE statement. Some simple cases can be singled out, however, where “natural” semantics actually make sense — and in some other “interesting” use cases, a custom pseudo-SQL statement seems to be sufficient. Continue reading
Format 0.2 Opensim Archives (OARs) include, since Opensim version 3c271b, a “landdata” directory that stores parcel data. For each parcel in the region there is a file in XML format in the directory. Amost all objects in Opensim are associated with a unique uuid that identifies them, and parcels are not an exception to that rule. Files in the “landdata” directory use the uuid of the parcel as their filename and have a “.xml” extension.
What’s inside each one of these .xml files? Let’s take a peek at a sample one:
<?xml version="1.0" encoding="utf-16"?> <LandData> <Area>6256</Area> <AuctionID>0</AuctionID> <AuthBuyerID>00000000-0000-0000-0000-000000000000</AuthBuyerID> <Category>-1</Category> <ClaimDate>1255170099</ClaimDate> <ClaimPrice>0</ClaimPrice> <GlobalID>bfbf7bd4-7d7b-4a35-aba0-c352201cddcf</GlobalID> <GroupID>00000000-0000-0000-0000-000000000000</GroupID> <IsGroupOwned>False</IsGroupOwned> <Bitmap>AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAP//fwAAAAAA//9/AAAAAAD//38AAAAAAP//fwAAAAAA//9/AAAAAAD//38AAAAAAP//f wAAAAAA//9/AAAAAAD//38AAAAAAP//fwAAAAAA//9/AAAAAAD//38AAAAAAP//fwAAAAAA/ /9/AAAAAAD//38AAAAAAP//fwAAAAAA//9/AAAAAAA=</Bitmap> <Description /> <Flags>505454667</Flags> <LandingType>0</LandingType> <Name>Arrabal Tango Club</Name> <Status>0</Status> <LocalID>4</LocalID> <MediaAutoScale>0</MediaAutoScale> <MediaID>00000000-0000-0000-0000-000000000000</MediaID> <MediaURL /> <MusicURL>http://xx.xx.xx.xx:8000</MusicURL> <OwnerID>69af4428-cec0-48d8-a0d9-c05268facca5</OwnerID> <ParcelAccessList /> <PassHours>0</PassHours> <PassPrice>0</PassPrice> <SalePrice>0</SalePrice> <SnapshotID>00000000-0000-0000-0000-000000000000</SnapshotID> <UserLocation><0, 0, 0></UserLocation> <UserLookAt><0, 0, 0></UserLookAt> <Dwell>0</Dwell> <OtherCleanTime>0</OtherCleanTime> </LandData>
That’s the xml file for Arrabal Tango Club in Condensation Land — I’ve only obscured the music URL and wrapped the part between the <Bitmap> and </Bitmap> tags, which originally used only one line, with no intervening blanks. This string encodes the shape and position of the parcel in the region. How do we know that? Well, the parcel map has to be stored somewhere, and it has to be quite large, so the only candidate is the “Bitmap” string :-) Most probably this long string is a text encoding of binary data.
Indeed this is the case: the string is using the Base64 encoding (you can find that quickly by browsing the Wikipedia). After decoding the string, we get a binary chunk of exactly 512 bytes. I checked that all the terrain files have strings of exactly the same length, so this number had to mean something. Continue reading