John Hurliman

sceneviewer using the new libprimrender engine

Just finished committing an early preview of libprimrender to the libsecondlife source tree. libprimrender takes libsecondlife primitive objects and creates 3D mesh data. The library only uses basic math and libsecondlife data types, so there is no platform or rendering library dependency. The code is released as a GPL v2 library written in C#, based on the official Second Life viewer source code (llvolume.cpp). The screenshot above shows sceneviewer (an old Second Life client written in C# using libsecondlife and XNA) using libprimrender to draw a twisted and sheared cube. The noise in the background is wireframe water left over from the original codebase.

The source code can be browsed at:
http://openmetaverse.org/svn/index.cgi/libsl/libprimrender/

Or checked out through SVN at:
svn://openmetaverse.org/libsl/libprimrender/

This is an early preview, it does not calculate tangents/normals/binormals and there are likely still some bugs. If you spot any please use the libsecondlife Issue Tracker or post a comment here.

Since January I’ve been working on a final research paper for my undergraduate degree in economics, and it is available to download now. The paper explores property valuation in virtual worlds, and specifically focuses on land prices in Second Life. To collect the data I wrote a libsecondlife bot that periodically logs in, takes a sampling of the land for sale, and compares it against the previous snapshots to detect ownership changes and check if a sale took place. A hedonic regression is constructed to try and make sense of land valuation and a few interesting things were discovered, but nothing an experienced realtor in Second Life wouldn’t already have discovered through experience. In my opinion the most important thing discovered through the research is that the limitations of searching for land in Second life introduced a selectivity bias in the collected data, and does not deliver complete information on the market to land buyers. Maybe one of the third party new search technologies can address these limitations.

Abstract

This paper explores the fast growing market of property in online virtual worlds by researching land prices in the online world of Second Life. As computing power and access to broadband Internet increases, immersive three dimensional worlds are increasing in popularity. In Second Life, a currency system with a floating exchange rate to the US dollar is in place and user-created synthetic goods are bought and sold. The only constrained resource is virtual real estate, and the more you own the larger and more complex structures you can build. A strong correlation between property size and price can be clearly established, but is this the only determinant of cost? A closer look at the parcels being purchased shows that size may not be the only consideration. Some residents may prefer a tropical beachfront location over snowy cliffs, or a more heavily trafficked area as a location for a new business. A background on the methods used to collect research data from Second Life is presented, and a basic hedonic pricing model for property in Second Life is constructed.

Virtual Appraisals: A Hedonic Pricing Model of Property in Second Life
Research paper + Excel data, source code, and MySQL schema

Last week I found out about the very cool band Long Range (MySpace), and also got the chance to help put on their concert in Second Life. Second Life has a problem with hosting large events as the maximum capacity of people on a private island is 100 people, but performance starts to degrade after about 50-60 people in the same area. The solution that was thought up was to “shard” the concert, with 12 identical islands running the same concert and load balancing people between them. The island setup was cloned, some very fancy LSL scripting kept the show and the lighting in sync, but there was one remaining issue. With five band members and 12 islands how do we get 60 band members playing their instruments at the same time? The answer was to use libsecondlife to log in 60 “actor” bots that would appear, set their appearance, and look for a specially marked object that was their “seat”. Once the bot was attached to this seat (which were really just small out of the way objects) the seat would trigger an animation for that actor to play the appropriate instrument. Using some hidden throttling techniques in Second Life I managed to get all 60 bots running from a single server, which might be a new record for stable connections with libsecondlife. A good show of music and technology, check out Long Range’s music and maybe we can talk them in to another show for Second Life!

And Merry Christmas to everyone, time for me to start wrapping gifts ;-).

Here’s a video of the 3d Second Life client sceneviewer I’ve been working on. At the end of it you can see a moving object, the program actually shows everything in real-time including creating, moving, resizing/rotating, and deleting objects. Support for spheres, rings, and torii is next, along with support for clicking on prims and then a full SL-style camera. Hopefully by then someone makes some progress on a decoder for LayerData packets so we have terrain, and our cloud renderer is ready to go. Texture support is just around the corner as well, we can already download and decode textures from Second Life but some more robust (and asynchronous) downloading methods are needed, along with texture support in the prim library. And maybe by that time either I’ll have a better grasp on shaders, or we’ll have another person helping with the project. For now I’ll have to take a break on this as school and some contract software design will be filling up my schedule.

For the readers outside of the libsecondlife circle, sceneviewer is a C# program using Microsoft’s new XNA library. That means it’s a Windows-only program for now, but hopefully someday we could either abstract out the 3D code to target both XNA and Tao.OpenGL, or maybe Mono.Xna will mature. We are always looking for new coders for libsecondlife, so if you know C# and want to help with sceneviewer or libsecondlife drop in #libsl on EFNet.

Shortly after I wrote a somewhat harsh post on the libsecondlife-dev mailing list detailing out why it wouldn’t be feasible to export Google SketchUp data in to prim data ready for Second Life import, Andrew Reynolds has written a Ruby plug-in for SketchUp that does exactly that. Well technically my original arguments still hold as it simplifies all surfaces in to a rectangular face, but the fact that any data at all was pulled out of SketchUp, and that it looks like the original data if you are using the basic tools is a big leap forward. Maybe we can convince him to use the .prims XML format that libsecondlife has been cooking up.

Every Second Life player that has aspired to build their own grand project at some point has yearned for more powerful tools. Second Life has made a building and texturing toolset that is incredibly easy for the average user with no familiarity with 3D modeling, but lacking in ability compared to full-scale 3D software. There are also times when you want to build things without being connected to the grid, and import them later. To fill this niche, Jeffrey Gomez has created an excellent plugin for Blender called prim.blender. The plugin is open source Python code, released under the GPL license and reads and writes a simple xml format that stores Second Life “prim” (primitive, a building block object) information. This is a great piece of software that allowed the creation of the wonderful libsecondlife headquarters shown below.

To complete the circle, I’ve been working on an object exporter named primexport to get prim data out of Second Life and in to Blender. This will eventually allow you to build structures in-world, export them and do the texture mapping, then import the finished product to Second Life. For now it’s still in very early beta, once a couple more issues are worked out a public beta will be available from the libsecondlife website. Here’s an example of a motorcycle created in Second Life and exported in to Blender. This is different from just grabbing the raw OpenGL data because it’s stored in an xml format that describes the prim information, so it can be edited and imported back in to Second Life with an existing import script.

If you look closely you’ll see a cube on the middle of the seat, which is the invisible prim that avatars sit on when they ride the bike. Transparency isn’t handled so it’s fully visible in prim.blender, and you also might notice a part of the seat is missing, hence why the software is early beta and still being worked on heavily. The rough edges should be smoothed over soon enough, and this could be a fundamental change in how Second Life information is treated. Traditionally, data in the SL metaverse is thought of as being locked up in a black box, and bought and sold between agents. By putting prim information in to an xml format, it can be transferred between grids, stored in versioning systems, downloaded from websites or peer-to-peer software, and integrated in to the rest of the web in general. It also brings the intellectual property of builders to about the same level of security that webpages, where anyone is free to view and copy the html source code. Should security measures be built in to primexport to try and hold on to the SL permissions system? Should such artificial restrictions be thrown to the wind so the virtual wild west can be embraced? What implications will this have for the Second Life building process, the economy, and intellectual property in the metaverse?

The six top sell offers on the LindeX market right now. A linear regression shows a T-value of -18.889, well outside the significance test at 99.9%. An R-squared value of 98.9%; I wonder if this is temporary or a reoccurring pattern of sell volume in the market? Could it be Linden Labs using the new sell option in the terms of service? I’ll have to keep my eye open for this more often.