Introduction

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.

Temple, an island by Omurtag Milev in Condensation Land

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.

History

Condensation Land started as an experiment in looking for alternatives to Second Life after the OpenSpace fiasco. The initial six months of this process are explained in detail here. Shortly after writing this article, the company I was working for decided that virtual world technology was not adequate for their needs and started using WebEx. The initial founders of Condensation Land (Ludmilla Writer, Favio Piek and myself) decided to keep Condensation Land as an experiment and a playground, and to invite people to show their content in the mini-world.

Technical status

Condensation Land is a mini virtual world powered by Opensim. We are using r13558 of the Diva distribution (D2); the Wifi page can be accessed here. Condensation Land has a WordPress blog, used mainly to keep users informed of new releases and content additions, and a Flickr group.

The physical machine

The whole Condensation Land virtual world runs on a non-dedicated home machine with Windows XP SP3, 3 GB of RAM, and two SATA ST3400620AS HD’s of 372 GB each. The first HD (C:) hosts the operating system and the swapfile, while the second HD (D:) is dedicated to Opensim and MySQL. Apart from keeping the system updated and running the disk defragmenter every so often, the machine requires almost no maintenance.

Networking is provided by JazzTel (a spanish ISP) in the form of a symmetrical 2 Mb SDSL line; the machine has an external IP address and can thus be used for HyperGrid teleports, accesed from anywhere, etc. This line costs around € 200/mo, which is more or less US$ 250/mo.

World setup

Condensation Land (loginuri: http://condensationland.com:9000) comprises 11 regions, of which 10 are public. The region with most prims is Condensation Land, with 10,278 prims, and the region with more active scripts is Angelico Miguelis, with 706 active scripts. The whole world uses 38,065 prims and 1,934 active scripts, as detailed in the following table.

+---------------------------+--------+---------+
| Region                    | Prims  | Scripts |
+---------------------------+--------+---------+
| Angelico Miguelis         | 10,024 |     706 |
| Conceptior                |  6,280 |     531 |
| Condensation Beach        |  2,455 |      46 |
| Condensation Land         | 10,278 |      97 |
| Condensation North        |  1,610 |     122 |
| Condensation South        |  1,908 |       7 |
| Condensation SouthWest    |    992 |      77 |
| Shoshisn                  |    555 |     163 |
| Temple                    |  3,239 |     139 |
| Tralfamadore              |    427 |      29 |
| (private region)          |    297 |      17 |
+---------------------------+--------+---------+
| Total                     | 38,065 |   1,934 |
+---------------------------+--------+---------+

MyWorld.ini sets CombineContiguousRegions to false to avoid the use of megaregions. The bin\library directory contains the default IARs shipped with D2, plus the large objects library downloadable from the D2 downloads page, plus some small animation IARs created by myself with freebie anims found elsewhere. I’ve not had time to set up default avatars for male, female and neutral preferences.

Performance

Opensim.exe is pretty stable. and oscilates between 0% and 10% of CPU usage (even when idle, there are a lot of scripted objects, and object status has to be saved frequently), and uses between 167 MB when idle to 512 MB with one avatar and 1 GB of RAM with some few avatars. MySQL.exe consistently uses 250-300MB of RAM, and MySQL backups (in .sql format) occupy 3.51 GB, 1.32 GB when zipped.

The following video shows a party with four avatars in the Condensation Land region:

Content evolution

After 20090430, I added a 2,889-prims Klein bottle,

and an exhibition called Mirror Worlds featuring pictures from Florence Babenco, Ludmilla Writer, Mikil Tiki, Monika Finchy, Senna (SennaSpirit Coronet), Shoshisn Shilova and myself, and sculptures by Shoshisn Shilova.

After that, a very nice thing happened: people started to contribute their own stuff to be shown at Condensation Land! :-)

Breen Whitman donated a fantastic building called “Eastern Gaswork”, which I placed in Condensation South;

Breen Whitman's 'Eastern Gasworks'

Shoshisn Shilova got an island (called “Shoshisn”) and Mikil Tiki got another island (called “Tralfamadore – La Mikilina”);

Condensation Land world map after adding "Shoshisn" and "Tralfamadore"

and finally Omurtag Milev added three awesome islands called Temple, Conceptior and AngelicoMiguelis,

which you should absolutely visit (or, at least, look at the videos and pictures here).

Condensation Land world map after the addition of Omurtag's islands

Condensation Land now has ten regions, instead of the initial five, and a lot of new wonderful places to visit! :-)

Conclusion

Condensation Land is a non-for-profit, home-based, virtual world maintained in my free time (and in the free time of the respective region owners). Obviously, since we don’t get any money from it, it’s a work of love. It’s also a proof-of-concept: of what can be done with simply some free time, a lot of passion for the technology, and some very talented friends :-) I won’t say that caring for Condensation is always nice and easy — being the administrator of even such a small world as Condensation takes quite a lot of work: users forget their passwords; upgrades don’t always work; we had a serious case of inventory messup, where tons of spurious folders were created and which I had to clean manually using SQL; sometimes electricity fails for so long that the UPS dies (yes, this happens in Barcelona in 2010) and the machine has to be physically restarted; and so on. But the feeling of having all this wonderful stuff in a machine of yours, and of being able to share it with the world, is more than enough to compensate for all of it :-)

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).

Temple

Conceptior

Angelico Miguelis

All three islands were created by the incredibly talented Omurtag Milev (blog, Flickr). Omurtag has had several islands in Second Life, he’s been the curator of several exhibitions, and he’s more creative than I can adequately describe in words — therefore, I will leave you with two videos showing these islands, and with the recommendation to visit them, via Hypergrid 1.5 or using your local avatar, if you have one.

So much for the idea that virtual worlds powered by Opensim are wastelands :-)

[See the list of updates at the end of the article]

Introduction

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.

Product comparison

1. Features

                       | Second Life | Opensim+Skype | WebEx
  Voice                | Builtin     | Builtin(Skype)| Builtin
  Slide shows          | Complicated | Complicated   | Builtin
  Whiteboards          | --          | --            | Builtin
  App/Desktop sharing  | --          | --            | Builtin
  Real-time video      | Third-party | Third-party   | Builtin
  Mixing it all        | Bad         | Better        | Builtin

The needs for educators and for people wanting to hold online meetings are quite similar and very clear. First of all, they need some form of voice conferencing system. In most cases, there is a need to present slideshows (ideally, Powerpoint presentations); a form of shared black- or whiteboard is also very useful; the possibility of sharing an application or the full desktop comes also very handy; and having some form of real-time video streaming is also very desirable, so that “remote” people can see the teacher or the person who’s currently speaking.

For our feature comparison we will use three scenarios: Second Life, an Opensim grid with voice over Skype, and WebEx.

Voice

Voice is a built-in feature of both Second Life and WebEx, and can be implemented using Skype in Opensim grids (there’s also an Opensim solution for voice, Freeswitch, but I haven’t used it and I can’t comment about it). Both Skype and WebEx have excellent dynamic noise and coupling cancellation algorithms — many participants won’t need to mute their microphone while not speaking because of these algorithms. On the other hand, Second Life voice algorithms are much more sensitive to noise and coupling, and this implies that everybody has to be very careful to mute their microphone when not speaking, and that you’ll have coupling problems in mixed reality scenarios in the RL end of the meeting.

Slideshows

Slideshows are directly supported in WebEx — you can directly share a Powerpoint presentation, or, if you are using a different application for your presentation, you can share that application. In Second Life/Opensim, on the other hand, even such a simple task is painful and unreliable. You can capture all your slides as images, for example using a screen capture program, upload these images (which costs some additional money in Second Life, but not in most Opensim grids), and then build a slide presentation tool (or buy one) and put all the textures inside the tool. The textures get rescaled to a maximum of 1024×1024, which can be a nuisance in some cases, and when you change textures there’s a good chance that some of the clients don’t load the texture in time, so that they see a gray screen or a partially rezzed texture (there are some ways to overcome this problem, but they imply extra work and they vary between releases).

Another possibility is to create some web pages that contain your presentation, and either write a small program that interacts with the parcel media to show these pages in a screen or manually change the displayed page. In all cases, you have to play with the texture so that it fits the screen and your presentation is not cut or has ugly extra margins, which is tedious and wastes some time.

It should be noted here that while Second Life forces you to choose between showing a web-based presentation or a video stream, this is not the case with Opensim: you can use the OsSetDynamicTextureURL function to load a presentation from the web into a prim while still showing video via the parcel media.

Whiteboards

WebEx has a built-in whiteboard, and you can decide with whom to share it. Of course it’s not very comfortable to use, but no softwate whiteboard is. In Second Life or Opensim there is simply no way to implement a whiteboard.

Application or desktop sharing

WebEx has builtin support for application and desktop sharing — if in the middle of a class or a meeting you realize you’d like to show a web page to your attendees, for example, you can open that page in a web browser and share the browser, so that everybody can see the page. Second Life or Opensim do not implement any form of application or desktop sharing. There have been some experiments done with a plugin for VNC, but it’s not still something usable by the general public. Much before the tests with Second Life, RealXtend (an Opensim derivative) allowed VNC sharing on a prim.

Real-time video streaming

WebEx has built-in support for up to six simultaneous video streams. Image quality depends a lot on bandwidth and is generally webcam-like, but the synchronization with audio is perfect, and you experience no delay. Second Life or Opensim do not act as stream broadcasters, so that you have to buy a separate solution for video streaming (like Veodia) that meets the specifications of streams for Second Life (for example, if your streaming provider sends Windows Media or Flash streams you’re out of luck). Then you have to configure Second Life so that the parcel media displays the streamed video, which is not complicated in itself but requires some skills (while the WebEx solution works out of the box). Of course you can only have one video stream, not six like in WebEx.

Mixing it all

Of course in a real class of meeting you’ll want to mix all these elements dynamically following the needs of the meeting. For example, you may want to switch from your presentation to a whiteboard or a web page, and then get back to your presentation; or you might want to enlarge the video signal of somebody who’s making a long speech and then get back to your slideshow, etc. With WebEx all of this is very simple and can be performed with some few clicks; with Second Life, some things can not be done, and others are painful and disruptive to the meeting or class. For example, you can interrupt a web-based presentation and connect a video channel instead, but this takes some programming or complicated manual intervention, during which the class is interrupted, and then you have to wait for the video to buffer — very disruptive.

Opensim and its derivatives fare slightly better that Second Life in that respect: as noted, Opensim allows to texture a prim from a URL, which SL does not, and this can allow for simultaneous web-based presentations and video streams; RealXtend implements some support for VNC desktop sharing and also allows to have several video streams in the same parcel, etc.

2. Costs

                       | Second Life   |  WebEx
                       | Min    Avg    |  Min    Avg
                       | ------ ------ | ------ ------
  Setup fee            |  1,000  1,000 |      0    300
  Avatar setup         |      0    481 |    N/A    N/A
  Streaming video/mo   |      0     84 |      0      0
  Monthly fees (1 sim) |    295    295 |     42     81
  Monthly cost (-setup)|    295    379 |     42     81
  Yearly cost  (+setup)|  4,540  6,029 |    504  1,272

[Legend: This is a cost comparison for 25 avatars. We have estimated an average of L$ 5000 per avatar to make them look decent. We have converted L$ to US$ assuming a 260 conversion rate. Streaming video costs are calculated assuming a yearly cost of US$ 1000. All numbers are expressed in US$ and rounded to the nearest integer.]

All considered, it’s clear that Second Life/Opensim cannot be compared to WebEx in terms of features and ease of use. Let’s examine now costs.

Second Life

To be able to have complete control of your experience, you’ll need a private island — if you rent a homestead from a land baron, you risk having your land confiscated at any time without reason or warning and lose all your work and money, and you’ll not be able to do anything about it; things like this are happening every day in Second Life. A full sim has a setup fee of US$ 1000 and a monthly fee of US$ 295. Then you’ll have to invest money in buying the tools you need or develop them yourself. If you want your executives, employees, students etc to look good, you have to spend between L$ 5000 to L$ 10000 per user, and lose time buying clothes, skins, hair, etc — this can be a lot of time if you don’t want to end up with an army of clones. Finally, if you need video, you have to shop for a suitable streaming video provider and pay for the service, which can cost you around US$ 1000 per year.

Opensim

Opensim in itself is not a service, as Second Life and WebEx are, and this the reason why I have not included Opensim in the above comparison (it does not make sense to speak of “the cost of Opensim”, but of the cost of a determinate solution using Opensim, and there’s no sensible way to determine what’s “minimum” or “average” in this context). Opensim software is in itself is free, and, therefore, depending on your existing infrastructure, costs may start at US$ 0, and add as you need to hire services from third parties (i.e., video, a hosting provider, etc).

WebEx

WebEx has a small one-time setup fee (something like €200 in Spain, this should be around US$ 300 — I’m not sure this applies to the USA), and a monthly cost of US$ 42 (we pay more in Spain, € 54, which should something like US$ 81).

3. Support

Webex offers email-based and phone-based technical support. If a user has problems with her connection, you can send them to WebEx support and they help them. With WebEx, you have a single point of support, and it works acceptably well.

On the other hand, although technical support people from Second Life are very polite, helpful and nice (at least at the concierge level), getting effective support there is always a mess, and in some cases plainly impossible. Since Linden Lab only sells you “the platform” and you have to buy your tools elsewhere (for example, a scripted screen for presentations), if that tool fails you can’t call the Lindens for help — you have to contact the author of the tool instead. Most merchants in SL are fine people and are very helpful, but in case they are not, you don’t have a place to complain. The same is true when you want to solve a problem with video streaming: the Lindens can’t help, because they are only selling “the platform”; the video provider will say that you have a problem with your ISP, and your ISP that you have a problem with your streaming provider. To summarize, in a typical setup you may have 10-20 points of support, and this is clearly a mess and not efective at all.

I can’t comment on the level of support for Opensim hosting providers, since I have never tried one. Anyway, if you are using Opensim you’re supposed to have a good technical level, since Opensim is alpha software. And the Opensim community is very enthusiastic and helpful. In any case, at the moment Opensim is not for amateurs.

Immersion

A theoretical approach

We saw that Second Life/Opensim do not compare to WebEx in terms or features or ease of use, and we have just seen that it doesn’t compare either in terms of costs or support. Since many people insist on the interest and even superiority of Second Life as a platform for meetings and education, and this superiority cannot be attributed to the features, ease of use, costs or support, there must exist a different factor which is exclusive to Second Life/Opensim (or where Second Life/Opensim excels) and which compensates for the inferiority of the product in other areas. But the only candidate for such a factor is immersion.

Contrary to “features”, “cost” or “support”, which are objective qualities of a product, “immersion” is a psychological quality of experience, and therefore a subjective factor and ultimately something which cannot be attributed to a product, but to the way users experience it — and this will vary wildly from one user to another, as such is the prerrogative of everything subjective. Defining “immersion”, as with everything subjective, is difficult. If you ask somebody who has experienced immersion whether they know how to define it, they will reply “yes, for sure” — but when actually confronted to the task of defining it, they will begin to hesitate — this is due to a very common fact: mistaking the certainty of having experienced something with one’s ability to define what one has experienced.

Thus, we will not attempt to define what immersion is — this would be a task for an essay, not a blog post. What we will do is to look at how the term is used, what are its most usual synonyms, and proceed from there — this will be enough for the purposes of this post.

“Immersion” is usually used as “the feeling of being there”. When used in this way, the argument of those defending immersion runs as follows: products like WebEx (or even more sophisticated teleconferencing systems) don’t provide the feeling of “actually being there”, because you are permanently confronted to a screen which gives you, at most, an abstraction of what’s going on “in the other side” — immersion, however, makes you feel “present” in that other side, and therefore somehow abolishes the separation between “your place” and “the other side”. The argument starts to falter when you ask why that feeling of “presence” or “immersion” should be benefical for attending a meetings or a class. Indeed here the argument mistakes “being there” in the physical sense for “being there” in the intellectual sense. What is needed for a successful meeting or class is not “the feeling of being there”, which is something psychological and ultimately cannot be evaluated, but the actual fact of being involved in the conversation and participating in it, which is something objective, can be evaluated, and does not depend on “feeling that you are there”. In fact, the actual surroundings are of no importance when you are actually involved in a conversation — this explains why some people close their eyes when concentrating: surroundings are distracting, a nuisance — be them “there” or “here”.

Actual experiences

“Immersion” is therefore a state of the mind. It always involves some dose of roleplaying: you have to pretend that you are your avatar, you have to act as if the other avatars actually “are” other people, you have to behave as if “you” are sitting when your avatar “sits”, “you” are actually shaking hands to other people when your avatar shakes hands with another avatar, and so on.

The fact is that not everybody experiences immersion. See for example what Eric Krangel, reporter for Reuters in Second Life, had to say in an interview for the Silicon Valley Insider: “As part of walking my ‘beat,’ I’d get invited by sources to virtual nightclubs, where I’d right-click the dancefloor to send my avatar gyrating as I sat at home at my computer. It was about as fun as watching paint dry.” You could argue that Mr. Krangel was somehow immersion-impaired, and that Reuters could well have chosen somebody with better feelings towards the product — but the fact is that my experiences with other people are very similar to Mr. Krangel’s experiences.

Now I hear the legions of immersionist fanatics starting to organize a lynch mob in which I would be the unwilling star. Stop it. I’m an immersive avatar, I enjoyed immersion since my first second in Second Life, I have an active and wonderful social life in Second Life, and I’m myself in love with virtual worlds. I even host an Opensim-based micro-grid. Go check my Flickr, my YouTube or this blog for details. It’s not about me that I’m speaking, but about what’s happening to most people.

For example: In the companies I worked for, I personally trained 20+ people: executives, teachers and advanced students. I showed them how the client worked, accompanied them to buy nice skins and clothes, taught them how to use the tools needed to manage a meeting or a class, etc. Of these 20+ people only three (3!) found the experience interesting enough that they devoted some of their free time to explore the world, socialize, etc. Other people ranged from a sudden and immediate loss of interest (i.e., they never used it except when it was needed for their work) to a clear phobia to use the system: they said that they felt “ridiculous using that game”, that they felt that their avie was “a sinister puppet”, and they could never go beyond the feeling that they were being forced to use a game that was distracting them from the tasks they had to perform.

Horrors of (non) immersion – a sample case

Here’s a case I followed closely: classes were held in a mixed-reality scenario; some of the students attended the class in RL, while others came via Second Life. An image of the SL class was projected in the RL class, and a real-time video of the RL class was shown in SL. The audio system was configured in such a way that what was being said in RL was channeled to the audio stream of SL, and when somebody from SL spoke, their woice was heard in RL through the speakers.

Cool, no?

Well, in reality it was not cool at all. Let’s see what happened:

SL side

In the SL side, things got pretty boring after the first minutes. The sitting animations are mostly static, and animations for teachers are dull and repetitive. After taking a peek at their fellow students and at the classroom, the interest of people participating in the class via SL faded quickly — the only visual element that could show any novelty was the video stream, which had a delay of 5+ second with respect to the voice channel and therefore gave a somehow creepy impression. Most people ceased to look at their screens or opened another application (to sort out their spam in the meanwhile, for example). This had the unwanted side effect to make them fall in the “away” state rather quickly. Since many of them had absolutely refused to spend a cent in bettering their appearance, they were not precisely nice looking. And they were away. Very depressing :-)

RL side

In the RL side things were not much better. Since most RL students were not aware of the existence or meaning of virtual worlds, projecting an SL image in the RL class gave them the impression they were being shown a video game. SL has glicthes and SL students weren’t very skilled at managing the product, so that they ended up sitting in the head of some fellow student, sitting on a table, suddenly unsitted and started to fly, etc, which was extremely distracting for everybody, real or virtual, and interrupted the class. Spatial voice is a disaster for classes; when a student that was sitting far away from the camera spoke, the RL teacher had to quickly move the camera so that she could be heard. Changing web-based slides was a mess and interrupted the class, and so on.

The immersive people

I’ve already mentioned that some few people had immersive avatars. You could quickly identify them because their avatars were much more beautiful, they took the time to change outfits for each meeting, etc. They explained that they spent most of the time looking at themselves and at their immersive fellow students (as everybody does in SL, by the way). After some minutes, they also got bored and started some other application while listening at what the teacher had to say.

So, is immersion absolutely useless?

Please notice that I’m not saying that immersion is completely useless for education. To the contrary, I’m convinced that there are scenarios where it is a wonderful tool — for example, real-time collaboration in 3D modelling. What I am saying is that, in the general case of meetings and classes, the use of virtual worlds is presently useless.

Of course one could argue that this is due to the current imperfections of the technology. Better technology, goes the argument, would eliminate all the current pitfails of SL as a tool for meetings: the user interface will be more intuitive and less intrusive; animations will reflect accurately what the user is doing, and so they will stop being dull; avatars will automatically resemble their humans (if their humans so desire), and they’ll even show facial emotions (like in James Cameron’s film), etc. All of this might happen, and I for one would be very happy if it happened as soon as possible; but unfortunately this speaks of some possible future products and platforms, not of what we have today.

Wishful thinking, collective delusion, or a marketing strategy?

Since it appears clearly that it cannot be rationally claimed that virtual world technologies are useful, in a general sense, for business meetings and classes, we can ask ourselves why so many people are insisting that this is the case. It could be that the people making these claims were victims of some form of wishful thinking; it could also be the case that they were victims of a collective form of delusion; finally, it could also be that they were making these claims as some form of marketing strategy. My personal impression is that these three factors operate simultaneously.

Wishful thinking

It’s human to mistake one’s own desires for reality. It’s happened to me, it’s happened to you, it happens to everybody, daily. When I entered SL, I immediately experienced immersion. Since I was experiencing it, I didn’t understand how it could be that other people weren’t experiencing it. I attributed this fact to several factors: they were not so good with computers as I am, the technology was too new and they needed some time to adapt, they were future-shocked, etc. It took me several months to realize the truth: they weren’t experiencing immersion because they were not interested in experiencing it; they simply didn’t want to “be” an avatar. I call my self-delusion “wishful thinking” because at the time I really desired that everybody had an avatar. One could do so many nice things if everybody had one and experienced immersion as I did! But, as time has teached me, my wishes and how things are in reality are completely different things.

Collective delusion

Sometimes I think about Linden Lab. I don’t know the company from inside, but I can imagine it — a big company, formed by enthusiasts of virtual worlds. At least this was surely so at the beginning. Now the have hired new people, but it’s a dogma that they all must pretend to be very immersive and enjoy their virtual lifes very much — else LL would risk enraging the residents because they’ve put somebody who’s not “one of us”, who “understands nothing”, to manage a certain part of the company.

Isn’t that a perfect field for collective delusion? People from Linden Lab always explain how much they meet in Second Life, how they save considerably by doing so, and so on. If you think of it, it’s no surprise — it’s as if you asked people who attended a party in SL whether they believed they had attended a party: of course all of them would reply they had.

What I’m arguing here is that Linden Lab is not a good example of the composition of your average company or your average school. What they say they are experiencing must be true for them, but it cannot be generalized to other collectives. So that they must be suffering of some form of collective delusion, believing that what is good for them can be immediately extrapolated to other businesses.

Marketing strategy

We could also be a little more cynical and think that some Lindens are not under any form of delusion, but that they are speaking about the superiority of Second Life as a tool for companies and educational institutions as a form or marketing strategy. Saying so would give them part of the market, and in the meanwhile they could invest to better the platform, so that in a short time it would not be such an inferior beast, but more comparable to WebEx and the rest of the competition. They could also be hoping that virtual worlds would “go mainstream” (M Linden actually says so in many places, including the interview cited at the beginning of this post), etc.

The problem with such an strategy is that it is very risky. What’s happened to the companies I’ve been working for is happening now to a big number of other companies, and will happen in the near future to still more companies. And Linden Lab will have burnt these customers. As Adam Frisby says about a related topic (tele-workers), this risks provoking “yet-another-media ‘Are virtual worlds over-hyped?’ rush.”

Conclusion

Virtual world platforms like Second Life and Opensim are today not developed enough to be of use, in the general case, for companies wanting to hold meetings and for educational institutions. This does not mean that it’s false that, as the homepage for Opensim says, “many people are doing exciting things with it”. Promoting the use of Second Life or Opensim as a tool for enterprises and educators, without adding big warnings or disclaimers, is the best way to actually delay adoption of the technology for several years: early adopters will get burned and start a backslash against the technology.

I will end this post citing part of a comment by At0m0 Beerbaum in an article by the Second Life Alphaville Herald about my Openspace Fiasco article. It’s a comment that made me think a lot, and, seen in perspective, I have to say that I tend to agree with everything he says.

However, I said this months ago, SL is not a platform to do business on, it’s more of the spider enticing the fly into its web. Linden Labs has no interest in actually providing enterprise support, they just want to push out a half-assed system, claim it has business potential because it can play embedded video and has voice, and profit from it with lots of feel good sales speak.

Hell, they havent even properly implemented shadows in their mainstream client, nor did they go anywhere with windlight.

You can easily go with a cisco conferencing solution or any other video conferencing solution, and pay much less overall than what Linden Labs wants to charge for zero support, and small pieces of server space.

SL is an entertainment platform, aka, a game. If you want to conduct real business, go with a company that has experience in this field. Otherwise if you just want a time waster and some eye candy, or a marketing hook, then look into getting a sim.

Update 1: There was an error in the calculation of costs for Opensim which has now been corrected. Given the variety of uses and configurations for Opensim, it’s very difficult to estimate meaningful “minimum” and “average” values for the cost calculation. I’ve opted to set the minimum value to zero, assuming an intranet use where all services (voice, streaming video, etc) are provided by the intranet, and set the “average” value to the cost of a well-known provider + the cost for streaming video.

Update 2: I received some comments that made me realize that including Opensim in the cost table was not a good idea after all. Opensim is not a service (as Second Life and WebEx are), and therefore it doesn’t make sense to speak of “minimum” or “average” costs “for Opensim”. It would make sense if we chosed a determinate Opensim hosting provider, but again in this case there’s no clear “average”: OSGrid is free (if you can host your own sims), for example.

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:

1. Read Snickers article and adjust your Avatars United settings
2. Go and finally get a GMail/Yahoo/Hotmail/whatever address for your avatar

[End of Peter's post]

Realmente son bikinis para perder la cabeza...

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… ;-)

Enlace: Hispagrid.

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 tool

The tool works in a very simple way: the OAR contents is first optionally extracted, and then it iterates over each object in the megaregion, extracting the x and y coordinates from the XML2 file and calculating the position of the corresponding region in the grid (relative to the SW region). Then a copy of the object with new non-megaregion coordinates is written to a temporary directory called ‘objects.i.j’, where ‘i’ and ‘j’ are the grid coordinates offset + 1 (for example, the SW region will have i = j = 1, the region to its east i = 2, j = 1, the region to its north i = 1, j = 2, etc). Finally, each of these directories is temporarily renamed to ‘objects’ (the standard directory name for objects in a OAR), and the ‘tar’ command is invoked to produce a file called fname.i.j, where fname is the name of the original OAR file, or ‘region’ if this name is unknown.

For example, using the tool against a 2×2 megaregion OAR called ‘test.oar’ will produce 4 OARs: test.1.1.oar (the SW region), test.2.1.oar (the SE region), test.1.2.oar (the NW region) and test.2.2.oar (the NE region). The current version of the tool has two problems: the first one is that it does not attempt to perform asset splitting, that is, the original megaregion OAR contains the assets (i.e., textures, scripts, object contents, etc) for all the objects in the megaregion, and the splitted OAR files will contain a copy of all the assets in the megaregion (instead of only the assets corresponding to the objects in the splitted region); this can be manually corrected by “normalizing” the OAR file: load it into an empty region and save a new OAR.

The second problem cannot be corrected, and is due to the (already mentioned) fact that megaregions do not contain terrain data for regions different from the SW region. Due to this fact, all the OAR files produced will contain the same terrain file, that is, the terrain file corresponding to the SW region (would it be better if I simply didn’t include any terrain?). This is not so much of a problem as it appears, if we can have access by other means to the missing terrain files: we can manually load the terrain in the target region and later load the oar with the ‘–merge’ option, or we can first load the oar and then the terrain.

How should megaregion terrains be stored in OAR files?

It is very probable that a future version of the OAR file format will include terrain information for all the regions in a megaregion. There are two ways to store such information: one is to store a big r32 file with the terrain data for the whole megaregion, and another one is to store the individual terrain files for each region. Both approaches have advantages and disadvantages: storing the terrain for the whole megaregion is ideal if we want to do some kind of online editing of the terrain (this can also be done if we have the single-region terrain files, but we have to aggregate the terrains first, which is cumbersome); on the other hand, storing the individual terrain files is ideal for megaregion splitting tools like the one presented in this article. The ideal solution would be to include both the megaregion terrain and the individual region terrains, and define semantics for the OAR load process: for example, “use the megaregion terrain if it is present, else use the individual region terrains”.

Implementation and technical details

To save coding time, I’ve implemented the tool as a new command called “SPLIT” in version 0.2 of my ZOE OAR editor. You open a megaregion OAR file with ZOE, type “SPLIT”, and that’s it — in some seconds you have the new OAR files. I’ve also updated ZOE so that it now depends on Cygwin being installed (instead of using 7z like in version 0.1) — this means that ZOE should run unchanged under Linux (but I can’t test that since I don’t have access to a Linux machine). This also means that ZOE should be called using “rexx zoe oarname” instead of “zoe oarname” (Cygwin bash does not understand the latter). To summarize, here’s what you’ll need:

1. Open Object Rexx.
2. (Only for Windows:) Cygwin (tested with Cygwin 1.7.1-1).
3. ZOE version 0.2, which you can download here.

Other minor changes in ZOE 0.2 are that the “zoe ??” and “zoe (c)” special calls have been eliminated (please refer to the documentation for ZOE 0.1 for details).

]]> http://zonjacapalini.wordpress.com/2010/02/13/splitting-megaregions/feed/ 10 Zonja Capalini Splitting megaregions http://zonjacapalini.wordpress.com/2010/01/25/partial-documentation-for-xml2/ http://zonjacapalini.wordpress.com/2010/01/25/partial-documentation-for-xml2/#comments Mon, 25 Jan 2010 17:55:25 +0000 Zonja Capalini http://zonjacapalini.wordpress.com/?p=583 ]]> Warning: This is a work-in progress. I’m publishing this article now to see whether it generates interest and which kind of feedback I get. The material published here is incomplete, and contains for sure errors, ommisions and inaccuracies. I plan on extensively modifying it during the following days. Please take that into account when reading it.

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.

SceneObjectGroups

An Opensim “object” or “linkset” is a linked collection of “parts” (prims or prim-like objects, like Linden trees), called a “SceneObjectGroup”. This collection cannot be empty, i.e., it contains always at least one part, but it might contain several, in which case there is a distinguished part called the “root” part. The XML2 representation of a SceneObjectGroup, thus, contains the root part, the (possibly empty) collection of the other parts, and (optionally) the saved states of the scripts running in the linkset, so that a “load oar” is as equivalent as possible to a region restart.

  SceneObjectGroup ::= '<SceneObjectGroup>'
                            RootPart
                            OtherParts
                           [GroupScriptStates]
                       '</SceneObjectGroup>'

Parts are technically called “SceneObjectPart”s.

  RootPart ::= SceneObjectPart

When there is only a part, an empty “OtherParts” tag is used; otherwise, the sequence of the other parts are is enclosed between matching “OtherParts” tags.

  OtherParts ::= '<OtherParts />'
               | '<OtherParts>' SceneObjectPart+ '</OtherParts>'

The GroupScriptStates section may be absent; when present, a sequence of SavedScriptStates is enclosed between matching “GroupScripStates” tags:

  GroupScriptStates ::= '<GroupScriptStates>'
                            SavedScriptState+
                        '</GroupScriptStates>'

SavedScriptStates are, for the moment, undocumented, and will probably remain so until some changes are made in the Opensim script engine:

  SavedScriptState ::= TBD

Basic types and non-terminals

We will now need a set of basic non-terminals so that we don’t have to include BNF for things that don’t interest us at this stage, like real numbers, integers or text strings:

  bool       ::= 'true' | 'false';
  byte       ::= (* a natural number >= 0 and <= 255 *);
  sbyte      ::= (* a whole number >= -128 and <= 127 *);
  ushort     ::= (* a natural number >= 0 and <= 65,535 *);
  int        ::= (* a whole number >= –2,147,483,648 and <= 2,147,483,647 *);
  uint       ::= (* a natural number >= 0 and <= 4,294,967,295 *);
  ulong      ::= (* a natural number >= 0 and <= 18,446,744,073,709,551,615 *);
  uuid       ::= (* see http://en.wikipedia.org/wiki/Universally_Unique_Identifier *);
  float      ::= (* a real number, 7 digits of precision,
                 between 1.5 x 10–45 and 3.4 x 1038 *);
  string     ::= (* a descriptive string *);
  TBD        ::= (* To Be Documented *);
  Vector3    ::= '<X>' float '</X>'
                 '<Y>' float '</Y>'
                 '<Z>' float '</Z>';
  Quaternion ::= '<X>' float '</X>'
                 '<Y>' float '</Y>'
                 '<Z>' float '</Z>'
                 '<W>' float '</W>';

SceneObjectParts

Please refer to SceneObjectPart.cs in the Opensim source for details.

  SceneObjectPart ::= SOPStart SOPContents SOPEnd
  SOPStart ::= '<SceneObjectPart'
               ' xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance'
               ' xmlns:xsd="http://www.w3.org/2001/XMLSchema">'
  SOPEnd ::= '</SceneObjectPart>'

The extra attributes in the “<SceneObjectPart>” start tag are due to the fact that SceneObjectParts are serialized automatically by the .NET/Mono runtime (while SceneObjectGroups are serialized manually).

  SOPContents ::= [AllowedDrop] CreatorID FolderID InventorySerial
                  TaskInventory ObjectFlags UUID LocalId Name Material
                  PassTouches RegionHandle ScriptAccessPin GroupPosition
                  OffsetPosition RotationOffset Velocity AngularVelocity
                  Acceleration Description Color Text SitName TouchName
                  LinkNum ClickAction Shape Scale UpdateFlag
                  SitTargetOrientation SitTargetPosition SitTargetPositionLL
                  SitTargetOrientationLL ParentID CreationDate Category
                  SalePrice ObjectSaleType OwnershipCost GroupID
                  OwnerID LastOwnerID BaseMask OwnerMask GroupMask
                  EveryoneMask NextOwnerMask Flags CollisionSound
                  CollisionSoundVolume

Remember that the list of attributes of a SceneObjectPart can change between different releases of Opensim. For example, older version 0.2 OARs don’t include an AllowedDrop attribute (that’s why I have marked it as optional), and newer SceneObjectParts may include new attributes not specified here.

Most attributes are represented by the basic types defined above, exceptuating TaskInventory, which is a list of TaskInventoryItems representing the contents of a prim (i.e., what’s on its “Contents” tab) and Shape, which is itself a structured attribute with many subattributes (please refer to PrimitiveBaseShape.cs in the Opensim source for details:

  Shape ::= '<Shape>'
      ProfileCurve TextureEntry ExtraParams PathBegin PathCurve
      PathEnd PathRadiusOffset PathRevolutions PathScaleX PathScaleY
      PathShearX PathShearY PathSkew PathTaperX PathTaperY PathTwist
      PathTwistBegin PCode ProfileBegin ProfileEnd ProfileHollow
      Scale State ProfileShape HollowShape SculptTexture SculptType
      SculptData FlexiSoftness FlexiTension FlexiDrag FlexiWind
      FlexiForceX FlexiForceY FlexiForceZ LightColorR LightColorG
      LightColorB LightColorA LightRadius LightFalloff LightIntensity
      FlexiEntry LightEntry SculptEntry
    '</Shape>'

For our purposes, the attributes of the SceneObjectPart and the attributes of its Shape attribute can be treated as a homogeneous set. You will notice that there is a Scale attribute both in the SceneObjectPart and in its Shape attribute; these are one and the same (i.e., they have always the same value). We will classify the combined set of attributes following the tabs of the standard object editor in the Second Life type of viewers.

General tab
Object tab
Features tab
Texture tab
Content tab
Other attributes

General tab

  Name ::= '<Name />'
         | '<Name>'
              string
           '</Name>'

Name of this part. If this is the root part, this is also the name of the whole SceneObjectGroup.

  Description ::= '<Description />'
                | '<Description>'
                     string
                  '</Description>'

A (possibly empty) description for the part. If the part is the root part, this is also the description for the whole SceneObjectGroup.

  CreatorID ::= '<CreatorID><Guid>' uuid '</Guid></CreatorID>'

Uuid of the creator of this part.

  OwnerID ::= '<OwnerID><Guid>' uuid '</Guid></OwnerID>'

Uuid of the owner of this part (and therefore of the whole SceneObjectGroup).

  LastOwnerID ::= '<LastOwnerID><Guid>' uuid '</Guid></LastOwnerID>'

Uuid of the last owner of this part. Useful when returning objects.

  GroupID ::= '<GroupID><Guid>' uuid '</Guid></GroupID>'

Uuid of the group this part (and therefore the whole SceneObjectGroup) is assigned or deeded to.

  BaseMask ::= '<BaseMask>' uint '</BaseMask>'

See the PermissionMask enum in Permissions.cs in the libopenmetaverse source. The following information was adapted from http://opensimulator.org/wiki/OpenSim:Permissions:

 public enum PermissionMask : uint
 {
    None        = 0;
    Transfer    = 1 << 13, //0x00002000
    Modify      = 1 << 14, //0x00004000
    Copy        = 1 << 15, //0x00008000
 // EnterParcel = 1 << 16, //0x00010000 -- Obsolete
 // Terraform   = 1 << 17, //0x00020000 -- Obsolete
 // OwnerDebit  = 1 << 18, //0x00040000 -- Obsolete
    Move        = 1 << 19, //0x00080000
    Damage      = 1 << 20, //0x00100000
    All         = 0x7FFFFFFF
 }

Default: PermissionMask.All. This field represents the highest amount of permissions the owner of an object can have. For example, if you set next permissions as ‘No transfer’ for an object and transfer it, the NextOwnerMask will have the Transfer bit unset (see below), this will ANDed to the BaseMask, and thus the new BaseMask will also have the Transfer bit unset, so that the new owner cannot transfer the object or make it transferable again.

  OwnerMask ::= '<OwnerMask>' uint '</OwnerMask>'

Default: PermissionMask.All. These are the current owner’s permissions for the object.

  GroupMask ::= '<GroupMask>' uint '</GroupMask>'

Default: PermissionMask.None.

  EveryoneMask ::= '<EveryoneMask>' uint '</EveryoneMask>'

Default: PermissionMask.None. These are the permissions that the general public have on the object. When the ‘Move’ flag is set, this is a ‘Anyone can Move’ object; similarly, when the ‘Copy’ flag is set, this is a ‘Anyone can Copy’ object.

  NextOwnerMask ::= '<NextOwnerMask>' uint '</NextOwnerMask>'

Default: PermissionMask.All. These are the permissions that the owner sets with the Modify, Copy and Transfer checkboxes.

BaseMask, OwnerBask and EveryoneMask  have their flags ANDed with the NextOwnerMask when the object is transferred.

  Flags ::= '<Flags>' flag [flag]* '</Flags>';

  flag ::= 'None' | 'CreateSelected' | 'ObjectModify' | 'ObjectCopy'
         | 'ObjectAnyOwner' | 'ObjectYouOwner' | 'Scripted' | 'Touch'
         | 'ObjectMove' | 'Money' | 'Phantom' | 'InventoryEmpty'
         | 'JointHinge' | 'JointP2P' | 'JointLP2P' | 'JointWheel'
         | 'AllowInventoryDrop' | 'ObjectTransfer' | 'ObjectGroupOwned' | 'ObjectYouOfficer' 
         | 'CameraDecoupled' | 'AnimSource' | 'CameraSource' | 'CastShadows'
         | 'ObjectOwnerModify' | 'TemporaryOnRez' | 'Temporary' | 'ZlibCompressed'

A set of flags. See the PrimFlags enum in Primitive.cs in the libopenmetaverse source. The following information was adapted from http://opensimulator.org/wiki/OpenSim:Permissions:

 public enum ObjectFlags : uint
 {
 None = 0,
            Physics = 0x00000001, CreateSelected = 0x00000002,     ObjectModify = 0x00000004,       ObjectCopy = 0x00000008,
     ObjectAnyOwner = 0x00000010, ObjectYouOwner = 0x00000020,         Scripted = 0x00000040,            Touch = 0x00000080,
         ObjectMove = 0x00000100,          Money = 0x00000200,          Phantom = 0x00000400,   InventoryEmpty = 0x00000800,
         JointHinge = 0x00001000,       JointP2P = 0x00002000,        JointLP2P = 0x00004000,       JointWheel = 0x00008000,
 AllowInventoryDrop = 0x00010000, ObjectTransfer = 0x00020000, ObjectGroupOwned = 0x00040000, ObjectYouOfficer = 0x00080000,
    CameraDecoupled = 0x00100000,     AnimSource = 0x00200000,     CameraSource = 0x00400000,      CastShadows = 0x00800000,
  //not defined yet   0x01000000,                  0x02000000,                    0x04000000,                    0x08000000,
  ObjectOwnerModify = 0x10000000, TemporaryOnRez = 0x20000000,        Temporary = 0x40000000,   ZlibCompressed = 0x80000000
 }

Default: ObjectFlags.None (0).

These bits are different from the previous masks, in the sense that they contain the ‘actual’ or ‘calculated’ values for the object (and many more options, to store, for example, whether the object is physical, phantom, or touch).

  SalePrice ::= '<SalePrice>' int '</SalePrice>'

Sale price.

  ObjectSaleType ::= '<ObjectSaleType>' byte '</ObjectSaleType>'

TBD

  OwnershipCost ::== '<OwnershipCost>' int '</OwnershipCost>'

TBD

Object tab

  GroupPosition ::= '<GroupPosition>' Vector3 '</GroupPosition>'

A vector defining the position of the whole SceneObjectGroup, that is, of its root part. It has the same value for all the SceneObjectParts — each individual part individualizes its position by defining an OffsetPosition (i.e., for each part, its position = GroupPosition + OffsetPosition).

  OffsetPosition ::= '<OffsetPosition>' Vector3 ''</OffsetPosition>'

Offset of this part, relative to the position (GroupPosition) of the root part. See GroupPosition.

  Scale ::= '<Scale>' Vector3 '</Scale>'

Size of the part. Please note that the Scale attribute of the SceneObjectPart and the Scale attribute of its Shape attribute have always the same value.

  RotationOffset ::= '<RotationOffset>' Quaternion '</RotationOffset>'

Rotation of the SceneObjectPart, relative to the region if this is the root part, or relative to the root part if this is not the root part.

  ProfileCurve ::= '<ProfileCurve>' byte '</ProfileCurve>'

A logical OR of the byte values of the HollowShape and ProfileShape attributes.

  ProfileBegin ::= '<ProfileBegin>' ushort '</ProfileBegin>'

[See Opensim.Region.ScriptEngine.Shared.Api.LSL_Api,  SetPrimitiveBlockShapeParams and SetPrimitiveShapeParams.]

When Building Block Type is “Box”, “Cylinder”, “Prism”, ”Torus”,”Tube”, “Ring”: (ushort) (50,000 * (Value of “Path Cut Begin”))
When Building Block Type is “Sphere”: (ushort) (50,000 * (Value of “Dimple Begin”)).
When Building Block Type is “Sculpted”: 0.

  ProfileEnd ::= '<ProfileEnd>' ushort '</ProfileEnd>'

[See Opensim.Region.ScriptEngine.Shared.Api.LSL_Api,  SetPrimitiveBlockShapeParams and SetPrimitiveShapeParams.]

When Building Block Type is “Box”, “Cylinder”, “Prism”, “Torus”, “Tube”, “Ring”: (ushort) (50,000 * (1 – (Value of “Path Cut End”))).
When Building Block Type is “Sphere”: (ushort) (50,000 * (1 – (Value of “Dimple End”))).
When Building Block Type is “Sculpted”: 0.

  ProfileShape ::= '<ProfileShape>'
                      ( 'Circle' | 'Square' | 'IsometricTriangle' |
                        'EquilateralTriangle' | 'RightTriangle' |
                        'HalfCircle'
                      )
                   '</ProfileShape>'

Where Circle = 0, Square = 1, IsometricTriangle = 2, EquilateralTriangle = 3, RightTriangle = 4, HalfCircle = 5, but the name is stored, not the value.

When Building Block Type is “Box”, “Tube”: “Square”.
When Building Block Type is “Cylinder”, “Torus”, “Sculpted”: “Circle”.
When Building Block Type is “Prism”, “Ring”: “Equilateraltriangle”.
When Building Block Type is “Sphere”: “HalfCircle”.

Hollow attributes: ProfileHollow and HollowShape

  ProfileHollow ::= '<ProfileHollow>' ushort '</ProfileHollow>'

[See Opensim.Region.ScriptEngine.Shared.Api.LSL_Api,  SetPrimitiveBlockShapeParams and SetPrimitiveShapeParams.]

When Building Block Type is “Box”, “Cylinder”, “Prism”, “Sphere”, “Torus”, “Tube”, “Ring”: (ushort) (50,000 *  (Value of “Hollow”)).
When Building Block Type is “Sculpted”: 0.

  HollowShape ::= '<HollowShape>'
                     ( 'Same' | 'Circle' | 'Square' | 'Triangle' )
                  '</HollowShape>'

Where Same = 0, Circle = 16, Square = 32, Triangle = 48, but the name is stored, not the value.

  PathBegin ::= '<PathBegin>' ushort '</PathBegin>'

When Building Block Type is “Sphere”, “Torus”, “Tube”, “Ring”: (ushort) (50,000 * (Value of “Path Cut Begin”)).

  PathCurve ::= '<PathCurve>' byte '</PathCurve>'

Byte value (mask?) of the enum “Extrusion” in PrimitiveBaseShape.cs: Straight = 16, Curve1 = 32,  Curve2 = 48, Flexible = 128.

When Building Block Type is “Box”, “Cylinder”, “Prism”: Extrusion.Straight.
When Building Block Type is “Sphere”, “Torus”, “Tube”, “Ring”, “Sculpted”: Extrusion.Curve1.

  PathEnd ::= '<PathEnd>' ushort '</PathEnd>'

[See Opensim.Region.ScriptEngine.Shared.Api.LSL_Api,  SetPrimitiveBlockShapeParams and SetPrimitiveShapeParams.]

When Building Block Type is “Sphere”, “Torus”, “Tube”, “Ring”: (ushort) (50,000 * (1 – (Value of “Path Cut End”))).
Zero otherwise.

  PathRadiusOffset ::= '<PathRadiusOffset>' sbyte '</PathRadiusOffset>'

[See Opensim.Region.ScriptEngine.Shared.Api.LSL_Api,  SetPrimitiveBlockShapeParams and SetPrimitiveShapeParams.]

When Building Block Type is “Torus”, “Tube”, “Ring”: (byte) (100 * (Value of “Radius”)).
Zero otherwise.

  PathRevolutions ::= '<PathRevolutions>' byte '</PathRevolutions>'

[See Opensim.Region.ScriptEngine.Shared.Api.LSL_Api,  SetPrimitiveBlockShapeParams and SetPrimitiveShapeParams.]

When Building Block Type is “Torus”, “Tube”, “Ring”: (byte) (100 * (Value of “Revolutions”)).
Zero otherwise.

  PathScaleX ::= '<PathScaleX>' byte '</PathScaleX>'

[See Opensim.Region.ScriptEngine.Shared.Api.LSL_Api,  SetPrimitiveBlockShapeParams and SetPrimitiveShapeParams.]

When Building Block Type is “Box”, “Cylinder”, “Prism”: (byte) (100 * (2.0 –  (Value of “Taper X”))).
When Building Block Type is “Torus”, “Tube”, “Ring”: (byte) (100 * (2.0 –  (Value of “Hole Size X”))).
When Building Block Type is “Sphere”, “Sculpted”: 0.

  PathScaleY ::= '<PathScaleY>' byte '</PathScaleY>'

[See Opensim.Region.ScriptEngine.Shared.Api.LSL_Api,  SetPrimitiveBlockShapeParams and SetPrimitiveShapeParams.]

When Building Block Type is “Box”, “Cylinder”, “Prism”: (byte) (100 * (2.0 –  (Value of “Taper Y”))).
When Building Block Type is “Torus”, “Tube”, “Ring”: (byte) (100 * (2.0 –  (Value of “Hole size Y”))).
When Building Block Type is “Sphere”, “Sculpted”: 0.

  PathShearX ::= '<PathShearX>' byte '</PathShearX>'

[See Opensim.Region.ScriptEngine.Shared.Api.LSL_Api,  SetPrimitiveBlockShapeParams and SetPrimitiveShapeParams.]

When Building Block Type is “Box”, “Cylinder”, “Prism”, “Torus”, “Tube”, “Ring”: (byte) (100 * (Value of “Top Shear X”)).
Otherwise: 0.

  PathShearY ::= '<PathShearY>' byte '</PathShearY>'

[See Opensim.Region.ScriptEngine.Shared.Api.LSL_Api,  SetPrimitiveBlockShapeParams and SetPrimitiveShapeParams.]

When Building Block Type is “Box”, “Cylinder”, “Prism”, “Torus”, “Tube”, “Ring”: (byte) (100 * (Value of “Top Shear Y”)).
Otherwise: 0.

  PathSkew ::= '<PathSkew>' sbyte '</PathSkew>'

[See Opensim.Region.ScriptEngine.Shared.Api.LSL_Api,  SetPrimitiveBlockShapeParams and SetPrimitiveShapeParams.]

When Building Block Type is “Torus”, “Tube”, “Ring”: (byte) (100 * (Value of “Skew”)).
Otherwise: 0.

  PathTaperX ::= '<PathTaperX>' sbyte '</PathTaperX>'

[See Opensim.Region.ScriptEngine.Shared.Api.LSL_Api,  SetPrimitiveBlockShapeParams and SetPrimitiveShapeParams.]

When Building Block Type is “Torus”, “Tube”, “Ring”: (byte) (100 * (Value of “Taper X”)).
Otherwise: 0.

  PathTaperY ::= '<PathTaperY>' sbyte '</PathTaperY>'

[See Opensim.Region.ScriptEngine.Shared.Api.LSL_Api,  SetPrimitiveBlockShapeParams and SetPrimitiveShapeParams.]

When Building Block Type is “Torus”, “Tube”, “Ring”: (byte) (100 * (Value of “Taper Y”)).
Otherwise: 0.

  PathTwist ::= '<PathTwist>' sbyte '</PathTwist>'

[See Opensim.Region.ScriptEngine.Shared.Api.LSL_Api,  SetPrimitiveBlockShapeParams and SetPrimitiveShapeParams.]

When Building Block Type is “Box”, “Cylinder”, “Prism”, “Sphere”, “Torus”, “Tube”, “Ring”: (sbyte) (100 *  (Value of “Twist End”)).
Otherwise: 0.

  PathTwistBegin ::= '<PathTwistBegin>' sbyte '</PathTwistBegin>'

[See Opensim.Region.ScriptEngine.Shared.Api.LSL_Api,  SetPrimitiveBlockShapeParams and SetPrimitiveShapeParams.]

When Building Block Type is “Box”, “Cylinder”, “Prism”, “Sphere”, “Torus”, “Tube”, “Ring”: (sbyte) (100 *  (Value of “Twist Begin”)).
Otherwise: 0.

  SculptEntry ::= '<SculptEntry>' bool '</SculptEntry>'

This SceneObjectPart is sculpted.

  SculptTexture ::= '<SculptTexture><Guid>' uuid '</Guid></SculptTexture>'

The uuid of the sculpt texture, or the null uuid (“00000000-0000-0000-0000-000000000000″) when this part is not a sculpty.

  SculptType ::= '<SculptType>' byte '</SculptType>'

  SculptData ::= '<SculptData />' | '<SculptData>' TBD '</SculptData>'

TBD

Features tab

Flexible path attributes.

  FlexiEntry ::= '<FlexiEntry>' bool '</FlexiEntry>'

Whether this part has a flexible path.

  FlexiSoftness ::= '<FlexiSoftness>' int '</FlexiSoftness>'

Flexible path softness, as in the ‘Features’ tab.

  FlexiGravity ::= '<FlexiGravity>' float '</FlexiGravity>'

Flexible path gravity, as in the ‘Features’ tab.

  FlexiDrag ::= '<FlexiDrag>' float '</FlexiDrag>'

Flexible path drag, as in the ‘Features’ tab.

  FlexiWind ::= '<FlexiWind>' float '</FlexiWind>'

Flexible path wind, as in the ‘Features’ tab.

  FlexiTension ::= '<FlexiTension>' float '</FlexiTension>'

Flexible path tension, as in the ‘Features’ tab.

  FlexiForceX ::= '<FlexiForceX>' float '</FlexiForceX>'

Flexible path force X, as in the ‘Features’ tab.

  FlexiForceY ::= '<FlexiForceY>' float '</FlexiForceY>'

Flexible path force Y, as in the ‘Features’ tab.

  FlexiForceZ ::= '<FlexiForceZ>' float '</FlexiForceZ>'

Flexible path force Z, as in the ‘Features’ tab.

Light attributes

  LightEntry ::= '<LightEntry>' bool '</LightEntry>'

Whether this part emits light.

  LightColorR ::= '<LightColorR>' float '</LightColorR>'

The ‘Red’ component of the light color, between 0.0 and 1.0.

  LightColorG ::= '<LightColorG>' float '</LightColorG>'

The ‘Green’ component of the light color, between 0.0 and 1.0.

  LightColorB ::= '<LightColorB>' float '</LightColorB>'

The ‘Blue’ component of the light color, between 0.0 and 1.0.

  LightColorA ::= '<LightColorA>' float '</LightColorA>'

The Alpha value of the light color, between 0.0 and 1.0.

  LightIntensity ::= '<LightIntensity>' float '</LightIntensity>'

Light intensity, as in the ‘Features’ tab.

  LightRadius ::= '<LightRadius>' float '</LightRadius>'

Light radius, as in the ‘Features’ tab.

  LightFalloff ::= '<LightFalloff>' float '</LightFalloff>'

Light falloff, as in the ‘Features’ tab.

  LightCutoff ::= '<LightCutoff>' float '</LightCutoff>'

TBD

Texture tab

  TextureEntry ::= '<TextureEntry>' string '</TextureEntry>'

A Base64 encoded string. TBD.

  ExtraParams ::= '<ExtraParams>' string '</ExtraParams>'

A Base64 encoded string. TBD.

Content tab

  TaskInventory ::= '<TaskInventory />'
                  | '<TaskInventory>'
                       TaskInventoryItem+
                    '</TaskInventory>'

List of items contained in this part (i.e., what’s on the ‘Contents’ tab for an object’s settings).

Other attributes

  AllowedDrop ::= '<AllowedDrop>' bool '</AllowedDrop>'

TBD

  FolderID  ::= '<FolderID><Guid>' uuid '</Guid></FolderID>'

Same as UUID (except for very old prims).

  InventorySerial ::= '<InventorySerial>' uint '</InventorySerial>'

TBD

  ObjectFlags ::= '<ObjectFlags>' uint '</ObjectFlags>'

Flags of type OpenMetaverse.PrimFlags. See http://openmetaverse.org/viewvc/index.cgi/omf/libopenmetaverse/trunk/OpenMetaverse/Primitives/Primitive.cs?view=markup for details.

  UUID ::= '<UUID><Guid>' uuid '</Guid></UUID>'

Uuid of the part.

  LocalId ::= '<LocalId>' uint '</LocalId>'

TBD

  Material ::= '<Material>' byte '</Material>'

Semantics: Material type for a primitive. Value range: One of 0 (Stone), 1 (Metal), 2 (Glass), 3 (Wood), 4 (Flesh), 5 (Plastic), 6 (Rubber), 7 (Light). [Source: The Material enum in Primitive.cs]

  PassTouches ::= '<PassTouches>' bool '</PassTouches>'

TBD

  RegionHandle ::= '<RegionHandle>' ulong '</RegionHandle>'

TBD

  ScriptAccessPin ::= '<ScriptAccessPin>' int '</ScriptAccessPin>'

Pin for remote loading of scripts.

  Velocity ::= '<Velocity>' Vector3 '</Velocity>'

Physics-related attribute. The velocity of the prim.

  AngularVelocity ::= '<AngularVelocity>' Vector3 ''</AngularVelocity>'

Physics-related attribute. The angular velocity of the prim.

  Acceleration ::= '<Acceleration>' Vector3 '</Acceleration>'

Physics-related attribute. The acceleration of the prim.

  Color ::= '<Color />'
          | '<Color>'
               color
            '</Color>'

TBD

  Text ::= '<Text />'
         | '<Text>'
              string
           '</Text>'

Maximum length = 255, truncated otherwise. TBD

  SitName ::= '<SitName />'
            | '<SitName>'
                 string
              '</SitName>'

TBD

  TouchName ::= '<TouchName />'
              | '<TouchName>'
                   string
                '</TouchName>'

TBD

  LinkNum ::= '<LinkNum>' int '</LinkNum>'

This is a sequential number that defines the order in which parts are linked: it’s always zero for the root part, 1 for the next part, etc.

  ClickAction ::= '<ClickAction>' byte '</ClickAction>'

TBD

  UpdateFlag ::= '<UpdateFlag>' byte '</UpdateFlag>'

TBD

  SitTargetOrientation ::= '<SitTargetOrientation>'
                              Quaternion
                           '</SitTargetOrientation>'

TBD

  SitTargetPosition ::= '<SitTargetPosition>'
                           Vector3
                        '</SitTargetPosition>'

TBD

  SitTargetPositionLL ::= '<SitTargetPositionLL>'
                             Vector3
                          '</SitTargetPositionLL>'

Same as SitTargetPosition.

  SitTargetOrientationLL ::= '<SitTargetOrientationLL>'
                                Quaternion
                             '</SitTargetOrientationLL>'

Same as SitTargetOrientation.

  ParentID ::= '<ParentID>' uint '</ParentID>'

TBD

  CreationDate ::= '<CreationDate>' int '</CreationDate>'

The date this prim was created, in TBD format.

  Category ::= '<Category>' uint '</Category>'

TBD

  CollisionSound ::= '<CollisionSound><Guid>'
                        uuid
                     '</Guid></CollisionSound>'

Uuid of TBD, or the zero uuid (“00000000-0000-0000-0000-000000000000″) when TBD.

  CollisionSoundVolume ::= '<CollisionSoundVolume>'
                              float
                           '</CollisionSoundVolume>'

TBD

  PCode ::= '<PCode>' byte '</PCode>'

Semantics: Type of primitive. Value range: One of: 9 (Prim: a Primitive), 47 (Avatar: An Avatar), 95 (Grass: Linden grass), 111 (NewTree: Linden tree), 143 (ParticleSystem: A primitive that acts as the source for a particle stream), 255 (Tree: A Linden tree). [Source: The PCode enum in Primitive.cs]

  State ::= '<State>' byte '</State>'

TBD

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.

What’s an ‘eternal’ exhibtion?

When I first though about making an exhibition in Condensation Land, I was thinking of setting up a permanent exhibition, i.e., one in which the artists changed and/or rotated with time. Soon I realized that virtual worlds technology allowed something more interesting: as artists changed, I could copy the old versions of the exhibition and put them in an airbox, so that visitors could come to look at the current version of the exhibition, but also teleport to the airboxes and see all the previous versions. That way, nothing would be lost, and we would have in fact, something new (and impossible IRL): an eternal exhibition.

Now since (if we got enough artists willing to participate) I envisaged having to perform the cloning operation several times, I decided to develop an automated tool to assist in the cloning, and I developed the (admittedly hacky) tool I called Zoe — you can find a detailed description of the technical details in my post “Moving and rotating OARs“.

Mirror Worlds: Layout, and some technical aspects

Mirror Worlds is located in the southeast corner of the Condensation Land region in the Condensation Land grid.

Aerial view of the 'Condensation Land' region. You can see the 'Mirror Worlds' exhibition in the southeast part, looking like an inverted 'L'.

The exhibition has seven rooms, with works from (left-to right, bottom-to-top) shoshisn, myself, Ludmilla, Monika (at the corner), Mikil, Florence and Senna. Since Mirror Worlds has to be integrated in the landscape (i.e., the sim is not devoted only to the exhibition), I was confronted to the following problem: what should be the aspect of the exhibition from outside? I wanted the building to be as luminous as possible and have almost transparent walls — but then pictures, when seen from outside, would present a blank face, and this would have been very ugly. Since we are in a virtual world, we don’t have to be 100% realistic; I could have copied the textures to the back side of the pictures, but then there would be no reason to enter the exhibition. I solved this dilemma by copying the textures to the back of the pictures and making this side 50% transparent — this way, the exhibition is beautiful from outside, and what you see from outside invites you to enter and see more.

Another decision was to also use the (cylindrical) ceiling as a place to also display pictures. You can see the results in the following shot, which shows a picture from Florence Babenco.

To make the 3D environment more lively, I added abundant water and fire:

I also counted on Shoshisn’s beautiful sculptures:

You can visit Mirror Worlds by using the hypergrid: just go to an hypergrid-enabled region and teleport to condensationland.com:9000 — the Condensation Land grid is centered at 7789,7789.

The human side

Building the exhibition, taking design decisions and solving technical/aesthetical dilemmas was the easy part of setting up Mirror Worlds — managing the human side of the problem was much more complicated. On the easy part, I first counted on two good old friends from the Second Life/Flickr community: Senna and Shoshisn.

Senna and me in the wheatfield

Senna has asked me to model several times and working with him has always been a pleasure. He’s a great friend and a very generous person — as soon as I asked him to participate, he gave me all his support and complete freedom to act. The current selection of pictures is mine, but he’s promised to make a new selection by himself, which will be featured in a coming edition of Mirror Worlds.

Shoshisn is a great friend, a great artist and a wonderful sculptor (apart from being very beautiful :-)). She’s one of the major contributors to Condensation Land: apart from the pictures and sculptures she has donated for the exhibition, she’s given us a lot of other nice sculptures, and, lately, these wonderful dolphins:

Shoshisn is also a believer in the future of Opensim, and she has helped me to contact a number of other artists for their present or future inclusion in Mirror Worlds. One of these artists is Monika Finchy, whom I don’t know personally — Shoshisn introduced us and Monika kindly agreed to have her fantastic work displayed.

Florence Babenco is an old Second Life friend. Florence, Ludmilla Writer and me made an exhibition in Second Life called “Las Tres Gracias” back in april 2008; for Ludmilla and me (but not for Florence) this was our first exhibition. When I asked her to participate, she immediately and generously agreed.

Mikil Tiki is a great friend, the kind of person you need to have in a party to ensure its success, metamorph extraordinaire, and a resident of Condensation Land. She’s also one of the most intelligent persons I’ve never met in Second Life. Philosophizing with her about the virtues, defects and nuances in general of being virtual is a delight. She generously accepted to have her work exhibited in Mirror Worlds immediately after I asked her.

Ludmilla Writer is my indefatigable RL friend, co-founder, contributor and resident of Condensation Land (she owns the Condensation Beach region), and co-owner with Favio Piek and me of Arrabal Tango Club. She’s helped me, in RL and in SL/Opensim, to think about Mirror Worlds, to prepare it, to select the pictures, and, in general, has given me moral support when I was finding the project too difficult. Without Ludmilla Mirror Worlds would not exist. It’s a pleasure to have her work shown there.

That was the easy part. Now I’ll talk about the not-so-easy part of building Mirror Worlds. First of all I have to say something: it’s the first time I work in something remotely related to being a curator, and I’m probably not the most idoneous person to do the job, because of (maybe) lack of sensibility and (for sure) of experience. On the other hand, some of the difficulties I faced when recruiting artists have to be attributed to the artists themselves, not to my lack of skills. However, some of the things I observed made me think quite a lot. Particularly:

1) Many people mistake Opensim for Open Life. This is probably a result of the mass rush to Open Life that happened around the Openspace fiasco, and is a very bad thing, because of two things: first, because the performance and stability of Opensim at the moment was much worse than it is right now (but people are unaware of that); and second, because Open Life is anything but open, and the identification between Open Life and Opensim is bad for the Opensim movement. The net result is that they are lazy (i.e., refuse) to try (again) an Opensim grid.

2) Many people simply didn’t seem to understand what Opensim, or an Opensim-based grid, is. They seemed to think that I was  talking about a special region of Second Life, or something like that. Awareness of Opensim between an important sector of SL residents is near to zero.

3) Between the people who do seem to understand what Opensim is, an important number found it too complicated to connect to a grid, even with my personal help and the presence of abundant documentation. This is specially problematic for Mac users, because of poorer support in general for Mac viewers. Many people who connect to SL routinely are artists or creative people in general, and they lack the skills to connect to Opensim. This is a problem because content creators and producers are much needed at the moment.

I mention these points here because Second Life has a rich, vibrant, artists community, and having this community to look with love to the Opensim grids, creating and showing their art in them, would be a very important bonus towards the general acceptance of Opensim as a platform.

Additional resources

Even if it’s not part of the Mirror Worlds exhibition, I would like to mention that Breen Whitman has donated a copy of his wonderfully crafted “Eastern Gasworks” building; it’s being shown in the southeast part of the Condensation South region — if you visit Mirror Worlds, please take some time to take a look at this building. It’s amazingly detailed, with a lot of shadows baked in the textures. I’m very grateful to Breen for this fantastic gift.

Here’s a video featuring a long travelling that includes the Mirror Worlds exhibition and Breen’s ‘Eastern Gasworks’:

Here’s another video featuring Mirror Worlds only:

Finally, here‘s a very nice article (in Spanish) about Mirror Worlds, written by my friend Albert Revolution.

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.

The XML2 SceneObjectGroup format

[Note: You can skip this section if you are familiar with the SceneObjectGroup/SceneObjectPart format.]

OARs are gzipped tarballs — you can find a detailed description of their structure here. Linksets are stored in individual XML files in Opensim’s own XML2 format. Altho the XML2 format is as yet undocumented, manual inspection of the actual files in several OARs and some peeks at the source code allows us to deduce the following:

1) Each linkset (or “SceneObjectGroup” in the Opensim parlance) is stored in an ASCII-encoded XML file with all non-significant white space removed. This means that there are no carriage-return, line-feed, or end-of-file characters, and that there are no extra blanks between tags (i.e., no formatting or prettyprinting).

2) Each linkset (or “SceneObjectGroup”) has the following form:

    <SceneObjectGroup>(RootPart)(OtherParts)[(ScriptStates)]</SceneObjectGroup>

where “(RootPart)” contains the information about the root part (the root prim of a linkset), “(OtherParts)” contains the information about all the other parts (prims) in the linkset, and the optional “(ScriptStates)” parts.

3) The “(RootPart)” is a “SceneObjectPart”. SceneObjectParts have the following format:

    <SceneObjectPart
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xmlns:xsd="http://www.w3.org/2001/XMLSchema">
                      (contents)
    </SceneObjectPart>

(I’ve indented the tag for readability, but this really occurs in one line, without extra blanks). “(Contents)” is a set of tags describing the properties of the SceneObjectPart (prim). Some of these properties are described using simple tags; for example, the name of a prim is stored as follows:

      <Name>(prim or plant name)</Name>

Other properties have a finer structure, and use nested tags with a fixed structure: for example, the spatial position of  a prim might be the following:

      <GroupPosition><X>167.5</X><Y>30</Y><Z>30.089</Z></GroupPosition>

Finally, other properties have a still more complex structure: for example, a prim may store “inside itself” (i.e., in the “Contents” tab) a number of other prims, scripts, animations, notecards, etc. — this is stored using a “<TaskInventory>” tag, and its contents will be the references to the (variable) contents of the prim. The same is true of the shape of the prim (I am not sure about that, but I think that Opensim stores the prim shapes in a separate SQL table, and that’s probably the reason why the shape information uses its own separate nested tag).

4) “(OtherParts)” is the (possibly empty) ordered collection of all the non-root prims (SceneObjectParts). If the linkset consists of only one part, an empty tag will be used:

      <OtherParts />

On the other hand, if there is more than one part in the linkset, the format will be the following:

      <OtherParts>(Part)[(Part)...]</OtherPart>

where each “(Part)” is in turn a “SceneObjectPart” as described above.

5) “(ScriptStates)” stores the states of running scripts, so that these scripts can be properly restored at OAR loading time. If there are no script states to store, there is nothing (i.e., not even an empty tag) in the XML2 file; if there are script states to store, they are bracketed between “<GroupScriptStates>” and “</GroupScriptStates>” tags.

Implementing SELECT and WHERE

Since the XML2 format is undocumented, I first implemented an agnostic XML parser, i.e., I read everything between “<tag>” and “</tag>” and stored it as-is as the value of the “tag” property of the containing object. Then I looked at the XML files and refined the parser to add hints to deserialize vectors (for example for the “GroupPosition” property) and quaternions (for example, for the “RotationOffset” property), as well as UUIDs (for example “CreatorID” or “UUID”).

I then implemented a simplified SQL WHERE condition parser and an algorithm to detect when an object matched a specified condition:

Now for simple properties like “Name” or “Description” this worked very well. But what about more complicated properties, like “GroupPosition”?

Adding sub-properties

This is not bad, but we clearly would need to be able to refer to the individual coordinates of the “GroupPosition” property — fortunately, there is a “natural” notation for that:

i.e., we extend the SQL notation to allow the use of subproperties of a “column”.

Adding alias

Of course, having to manually specify “GroupPosition.X”, “GroupPosition.Y”, etc. all the time is very cumbersome. It would be very nice if we could define an alias, of, say, “x” for “GroupPosition.X”, “y” for “GroupPosition.Y”, and so on:

This looks even nicer using an “AS” clause:

Using CALL IT

The alias facility has another important use: let’s assume, for example, that we want to manipulate objects created by me — but “me” (that is, “Zonja Capalini”) is identified in the OAR by an UUID, not by my name. I do know that I’m the creator of the 2889-prims Klein bottle:

We can copy and paste the creatorid to create an alias, or we can use the following hack command:

This is very handy — CALL IT only works when the previous instruction has been a SELECT with a one-row, one-column result set. Let’s see it in action:

This looks pretty neat! (Of course “y” and “z” have been conveniently aliased before executing this SELECT command).

Implementing functions

Some information about objects is either not stored as an explicit object property or is stored somewhere else. For example, the number of parts (prims) in a SceneObject can be easily calculated (it’s the number of SceneObjectParts in the OtherParts section plus one), but it’s not specifically stored anywhere; and the parcel a SceneObject is in is not stored anywhere, but it can be calculated from the parcel information with relative ease. These are two good candidates for our OAR-specific functions:

Here’s another example: we first identify the UUID of Ludmilla Writer, and then we use it (via CALL IT) to select all objects created by Ludmilla that are in the “Mirror Worlds” parcel.

Overall, this looks very easy and practical. Even if I’ve not (yet) implemented support for Shapes or TaskInventories, the expressive power of our very simple dialect of SELECT statements is quite strong. Let’s see what happens with DELETE and UPDATE.

Implementing DELETE

Once we have at our disposal the WHERE functionality described above, implementing DELETE statements is trivial:

Here’s a more sophisticated example:

Implementing UPDATE

It’s when we want to extend our till now quite successful model to SQL UPDATE statements when we start to find difficulties.

1) In some simple cases (e.g., the “Name” or “Description” properties), standard SQL UPDATE semantics works well:

This is due to the fact that, in the case of these properties, the semantics for the whole SceneObjectGroup is determined by the root SceneObjectPart, i.e., the name of a linkset is the name of the root prim, and the same holds of its description.

2) For other properties this is not true: for example, altering the “GroupPosition” property implies altering the same property for all the SceneObjectParts in the SceneObjectGroup, not only the root part (see “Moving and rotating OARs”). Something similar happens with other properties.

3) For still other properties, the semantics is unclear: while changing the OwnerID of the root prim should imply changing it too for all SceneObjectParts in the SceneObjectGroup, what does it mean to change the CreatorID? Changing it for the root part only, or changing it for all parts in the linkset?

4) Finally, there are properties that should not be changed by the user: the clearest one is “LinkNum” — LinkNum stores the relative number of the part in the linkset (the root part has LinkNum = 0, the second prim in the linkset order LinkNum = 1, and so on), and we clearly don’t want the user to be able to change that.

Future work, and some open questions

Clarifying UPDATE semantics

While the implementation of SELECT and DELETE semantics allow for a lazy parsing, relatively agnostic, implementation of SceneObjectGroups, UPDATE requires a good knowledge of the semantics of SceneObjectGroups. A conservative approach would be to implement UPDATE functionality only for properties of the SceneObhectGroup that are determined by the corresponding property of the root SceneObjectPart alone (i.e., case (1) above). Updates for case (2) could also be implemented, although this is probably better handled by separate, specialized commands (like “MOVE” or “ROTATE”) to avoid mixing root-part-only and all-parts semantics. Updates for case (3) should probably be forbidden in its direct form, but allowed by the extended select form presented below. Updates for case (4) should be strictly forbidden.

SELECT FROM OBJECTS, SELECT FROM <object>

Readers conversant with SQL will have noticed an omission from all the SQL statements showed here: the reference to a table. This is because all statements refer to the standard “table” OBJECTS, which can be omitted for simplicity. Hence, “Select where name like ‘%Zonja%’” really means “Select FROM OBJECTS where name like ‘%Zonja%’”. This will allow for possible future extensions where, for example, parcel data (or profile information, when/if it is added to OARs) can be displayed or manipulated.

Another interesting possibility is to manage a SceneObjectGroup itself as if it was a table. For example, if “3890889f-49de-4564-acc7-7a0aeb9f319e” is the UUID for the Klein bottle, we should be able to write

      Select name, description from "3890889f-49de-4564-acc7-7a0aeb9f319e" where linknum = 23

(here LinkNum is useful), or, using an appropriate ALIAS,

      Select name, description from KleinBottle where linknum = 23

DELETE semantics, when applied to linksets, would take care to preserve the LinkNum ordering; for UPDATE statements, semantics is in general also quite obscure and should be clarified.

Scripting

Using an interactive line-mode shell makes it trivial to implement a simple form of scripting for ZOE — indeed I’ve implemented one, but I have not described it here not to make this article too long. Scripting allows to do very nice things, like defining a set of standard alias (for example, for X, Y and Z), or programming simple modifications to a region (for example, a script cold be written which deleted all Linden plants and then distributed and used as-is by somebody without the knowledge about how to do such a thing).

Programmed object creation

While a combination of INSERT and UPDATE SQL statements seem to be overkill and probably too difficult to use to allow for the programmed creation of new objects, it would be relatively easy to expose an API for that, and use it to build objects offline. I will probably make some experiments in this direction when time allows.

Visual feedback: load oar –update, anyone? :-)

Justin Clark-Casey has hinted, in the opensim-dev mailing list, that he could consider the possibility of saving and loading OARs directly from the filesystem (i.e., without having to unzip and untar the OAR first). This would allow to do something very nice: edit an OAR, and every so often load that oar in a local sim, just to see the results (without having to tar and gzip it every time, which is time-consuming).

It would be still better if the Opensim “load oar” command implemented an “–update”  switch in addition to the “–merge” switch introduced in a4d2a9. Currently, the “load oar” command does one of two things: if “–merge” is not specified, it clears all objects from the region, then loads the new objects (and the terrain, etc); if “–merge” is specified, it does not clear the existing objects, but it simply adds the new ones; what “–update” would do is the following: keep all objects that have not changed alone, delete the ones that have been deleted, alter the ones that have been altered, and add the new ones, if any (I feel stupid writing that :-)). When a sim has a lot of objects and only a few ones have changed, this should be much cheaper than deleting everything and recreating it back (but I might be wrong about that).

Then, on a test installation, using a timed script with a “load oar –update” command would implement a great form of visual feedback.

Conclusion

Uding SQL as a way to manipulate OARs is not perfect, but it has a lot of potential, specially for SELECT and DELETE statements. UPDATE semantics needs to be carefully tuned to be of any practically use, but the use of non-standard SQL statements with a standard WHERE clause (e.g., “ADD 256 TO X WHERE …” or “ROTATE 90 DEGREES WHERE …”) can also be very practical.

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>&lt;0, 0, 0&gt;</UserLocation>
      <UserLookAt>&lt;0, 0, 0&gt;</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.

But — wait: parcel granularity in Opensim (and Second Life) is 4 meters — this means that parcel selection works in minimal units of 4 meters. Since a normal region is 256×256 meters and 256/4 = 64, this means that, parcel-wise, each region is like a 64×64 checkboard. But 64×64 = 4096, so this is a 4096-square checkboard. And, significantly, 4096/8 = 512 — so it might be that our binary chunk is representing the parcel map in the following way: let’s number the squares in their natural order (i.e., start by putting a one on the SW square and continue horizontally; when a line ends, go up one line and continue), and then construct a bit string consisting of a 0 for each square which doesn’t belong to the parcel, and a 1 for each square that does belong to it.

To check whether my hypothesis was working, I wrote a small program to visualize terrain files using a command prompt — I’d write periods instead of zeros to make the output more legible. Here’s the first result:

(I have only rescaled the image to make it square) This looks not bad, since Arrabal is really in the NW part of the region and is (roughly) square, but there is something wrong in the image: there’s a strange column of dots in the right part of Arrabal that should not be there. Interestingly. the number of 1s before the first dot is exactly 16. Could this have something to see with an endianness problem? I modified my program to order-reverse every 8 bits in the original chunk, ran it again, and — voilà!:

Now this looks pretty right! :-) Let’s take an aerial shot of (a local copy of) Condensation Land (the property lines can be seen if you look hard enough :))

and superimpose it with a (conveniently  alphaed, and positioned to fit exactly the island borders) version of the last map:

This looks as if it’s fitting perfectly! Now it should be pretty easy to implement deletion of objects by parcel in Zoe: since for each object we already have its X and Y coordinates, to evaluate whether the (root prim of the) object fits in a certain square, all we have to do is to divide X and Y by 4, truncate round both values, calculate Y*64+x, and use that value as a bit-level index into our binary chunk to determine whether the object is “inside” or “outside” the parcel:

Here’s the result of saving the OAR and loading it:

This looks pretty neat! :-) It’s been fun to do the research, it has all taken some few hours (including writing this post), and the next version of Zoe will include deletion by parcel name.