Paul Fishwick has been documenting how to build OpenSim with modrex (at least for Windows). You can help test by following the instructions on the Opensim wiki. Feel free to update the Linux build instructions if that’s your preferred environment.

A fairly current list of implemented features is documented here. The status of Python event handlers is here.

I hope to report soon that some of my tutorials have been implemented successfully on Opensim+modrex.

But what if your goal is to measure the energy use of an entire community in order to change consumer behavior? There are many wireless and power line networks being implemented today by power companies to capture real-time energy data from homes. Unfortunately, some of these companies have no plans to share the data with you, your community or your government, nor to enable you to integrate other data nor to control your resource usage remotely. A good example of the arguments on both sides can be found in this correspondence (PDF) between Good Corporation on behalf of Direct Energy  and the Public Utility Commission of Texas.

All utilities are in the process of filing for increased tariffs (or have new tariffs approved) so that you bear the cost of the systems that help them delay the construction of new generating capacity. This presentation (PPT) by Freeman, Sullivan and Co. shows that Advanced Metering Infrastructure (AMI) can result in net savings to utilities (at least in Vermont) through reduced service costs, avoidance of meter reading, and improved response to storm damage. You have to wonder why we’re being asked to pay for these systems.

Enthusiasts around the world have been building energy monitoring systems for years. With the rise of the Arduino project (an inexpensive microcontroller project with an open design first released in 2005), numerous designs have appeared on the internet, in Make magazine, and have been produced in kit form or embedded in products. Arduino has competitors like Phidgets, offering a richer set of analog sensors and more capable software for a significantly higher price.

In the UK and Europe, the Current Cost Meter is a popular solution. Its serial interface enables one to capture total power usage and temperature and build databases of historical energy usage. The Current Cost Meter doesn’t provide you with any control and doesn’t fetch real-time pricing data from utilities.

So much for collecting data. What if you want to share the data with others in your community? There are two sensor networks of interest today, but like social networks, social data networks (SDNs) such as these will proliferate as entrepreneurs discover their power to aggregate audiences with specific shared interests and use them to sell products and services to them.

Sensorbase is an iteration of a data logging system developed by the Center for Embedded Network Sensing (CENS) at the University of California. (Sensorbase should not be confused with the Sensorbase database in the Hackystat system, an instrumentation project for collecting real world data about all phases of a software development project.) The new design addresses problems with earlier versions of the CENS data logging systems which were distributed but difficult to query in a correlated fashion. Sensorbase is built on star schema, enabling OLAP queries with common time and location dimensions and efficient aggregate queries. It’s quite easy to define a project, a table and upload CSV or XML data to Sensorbase.org through your browser. Data can also be published or fetched through HTTP POST operations from your favorite language. I haven’t found any examples yet of people connecting Sensorbase to Second Life, but it has been connected to Google Earth to visualize micro-climate data for the James Reserve, located in the San Jacinto Mountains east of Riverside, California.

Pachube (usually pronounced patch bay) grew out of its founder’s interest in “hacking” buildings to sense the built environment and display or control it remotely. Usman Haque, an architect with a deep interest in systems and performance art, spun out a business to promote what could be termed a Global Service Bus (in the style of an Enterprise Service Bus). Anyone can put data on the bus, and anyone can the consume the data. The current implementation (as of Jan 21, 2009) has limited support for history (only 24 hours), but the roadmap includes support for extended history. The original intent of Pachube was that it might become the YouTube of streaming data, in other words a deep repository of information that can be searched, embedded, tagged, etc.)

Pachube leads Sensorbase slightly in its integration with virtual worlds, and will likely pull ahead given the social thrust of Pachube versus the scientific thrust of Sensorbase. Code is available on the Pachube site for collecting and consuming data in Second Life. In the coming weeks, code will be published for connecting Pachube feeds to elements in Sketchup models, allowing visual representations of sensor data to be placed on Google Maps or in Google Earth. (Since Microsoft Virtual Earth also supports KML, it’s reasonable to think that the same models would work with little or no change on Virtual Earth.)

A third network, AMEE, is devoted to the very specific issue of aggregating the world’s carbon footprint. The AMEE network seeks to document the operational and upstream (associated with manufacturing, transportation and storage) carbon footprint of every object we use. The first AMEE/Second Life integration was a project called Carbon Goggles, a heads-up display that superimposed a dark gaseous cloud over objects being modeled in the virtual world.  The size of the cloud was proportional to the carbon footprint of an appliance or vehicle. Tish Shute has described AMEE and interviewed its founder Gavin Starks in a recent post. She also interviewed Andy Stafford Clark, creator of the Current Cost meter. 

Pachube and Sensorbase are serious competitors for the web portals associated with the Advanced Metering Infrastructure (AMI/AMS) being pushed by the utilities. For a start, you control who you share your data with. Secondly, you can integrate data that a power utility might not be interested in, such as water consumption, oil usage, wood fuel usage, propane, or caffeine. Thirdly, you can use these networks to remotely control systems in your home. Both are capable of feeding data to a PC or control system that controls appliances or thermostats. The commands could be posted by a standard SMS text message, a tweet from Twitter, or by an HTTP POST from a smartphone.

In coming posts I’ll explore the integration of these sensor networks with OpenSim, realXtend, Sketchup and Google Maps/Google Earth. If you’ve done something cool with sensor networks and virtual worlds or maps, I’d love to hear about it!

As in Windows XP, the Program Files folder in Windows Vista requires elevated privileges to install software. But Vista goes further in that it virtualizes per-user files in another folder. If you or your software application attempts to modify settings in a plug-in, the modified file will be written to C:\Users\{user}\AppData\Local\VirtualStore\Program Files (x86)\Google\Google Sketchup 7\Plugins. The idea is to protect each user from the other by ensuring that they see either the original version of the file, or their personal version if they have modified it. Of course, to modify a file in the Plugins directory, you have to invoke Notepad or another editor with the “Run As Administrator” option before you open the file.

The first thing that needs to change is where we store the plug-ins if they need to be modified by the user. We should store them in the user’s data area, either in AppdataRoaming or in the Documents hierarchy and call them from a stub script in the Plugins folder. This approach allows the user to customize the script without elevated privileges.

The second things that needs attention is the use of installer scripts for plug-ins. It has been many years since I built an installer script and a lot has changed such as the introduction of separate folders for 64-bit and 32-bit programs, new file locations in Vista, etc. I don’t have access to the full Visual Studio development suite anymore either. So I looked at free and open source installers. After examining the NullSoft installer and Microsoft’s Wix, I opted for Wix since it didn’t require me to learn another scripting language and I didn’t have cross-platform requirements that NullSoft’s installer addresses.

After a lot of work learning Wix and dealing with the lack of accurate documentation on system-related APIs in the Sketchup Ruby documentation, I have created a workable installer for the Ogre Mesh Exporter plug-in discussed previously. The installer is presently optimized for Vista (32-bit and 64-bit). A more complete implementation with support for XP is coming soon. (I’m waiting for an answer on how to determine from a Sketchup plug-in which OS platform we’re running on.)

The installer places the three Ruby scripts (the export script, the configuration file and backfaces.rb) into the standard Plugins directory. On first use of the exporter, if it can’t find the C:\Users\{user}\Documents\Sketchup Plugins directory, it creates one, copies the  config file to it, then loads it. You may happily edit the config file in your Sketchup Plugins folder without needing any elevated privileges. As with the initial release, the code assumes the existence of a “My Models” folder in Documents. Each exported model will be stored in a separated directory in My Models. Unique ids are no longer attached to the materials, but you can set $g_ogre_append_unique_prefix to true of you want this behavior.

You can fetch the new installer from here. Just click on the link to run .msi file and install the add-in.

Notes:

1. Google Sketchup 7 must be installed before the plugin is installed
2. DocumentsMy Models directory must exist before running the add-in from the Sketchup Tools menu.
3. If you want to store the models somewhere other than My Models, edit the ogre_export_config.rb file after running the exporter once.
3. You can uninstall the plugin from the Control Panel.

I’ve just started to explore the potential of this approach, so I’ll give you one working example to get you started. This example demonstrates solutions to a few problems that bug builders from time to time:

• How to switch units from meters to cm, feet or inches
• How to specify colors by name using the W3C / X11 color names
• How to automatically place cloned objects on the ground when the ground is uneven

The example uses the Python ConfigObj library by Michael Foord and Nichola Larosa. ConfigObj implements a read/write (round-trip) handler for .ini files. Grab a copy of ConfigObj and store it in the rexserverScriptenginesLib folder. (By rights, it should be stored in site-packages, but the IronPython doesn’t seem to look there.)

We will use ConfigObj to read configuration data for a prim that looks like this:

[Units]
length=m
[Main]
color = SteelBlue
height = 10
width = 1
depth = .5

The [Units] section presently supports one key – length – which specifies what our unit of length is. The sample code handles “m” (meters), “cm” (centimeters), “ft” (feet) and “in” (inches). You can add conversions for other units.

The [Main] section lets you override the color, height, width and depth of a prim. I am being deliberately vague about the meaning of width and depth. At some point in the future I plan to determine which face of the prim is facing the avatar and define the width of that face as the width of the prim. (Of course it’s quite meaningless for a sphere or torus, but this is just a toy example.)

The configuration data is stored in the Data sub-panel of the reX tab in the object editor.

The data is processed by the DisplayConfig class in the Python script called sampleconfig.py. You indicate this by setting the class on the Misc sub-panel of the reX tab.

The key ideas in the code are the following.

1.  At the head of the code we import two Python libraries:

from configobj import ConfigObj
import StringIO

2. In the EventTouch handler we instantiate a ConfigObj and pass it the data from the reX Data panel via a StringIO object. The rexGetPrimFreeData() method returns the blob of data as a string. It could have been an XML data structure, a Python Pickle object, or the URL of an external (and possibly dynamic) data source.

    def EventTouch(self,vAvatar):
        configstring = StringIO.StringIO(self.rexGetPrimFreeData())
        config = ConfigObj(configstring)

The config variable is assigned a hierarchical dictionary of results which is easily indexed.

        length = “m”
        if config.has_key(‘Units’):
            section_units = config[‘Units’]
            if section_units.has_key(‘length’):
                length = section_units[‘length’]
        if length == “m”:
            length_conversion = 1.0
        elif length == “ft”:
            length_conversion = 1.0 / 3.2808398950131
        elif length == “cm”:
            length_conversion = 0.01
        elif length == “in”:
            length_conversion = 1.0 / 39.370078740157
        else:
            self.llSay(0,”Unknown Unit: ” + length)
            return false

You can also iterate over the keys. Here we process the keys in the [Main] section.

        section = config[‘Main’]
        for k in section.iterkeys():
            key = k.lower()
            if key == “height”:
                # set height of prim
                targetheight = float(section[k]) * length_conversion
                my_scale = self.llGetScale()
                x = my_scale.x
                y = my_scale.y
                z = targetheight
                # adjust the height of the object so it sits on the ground
                land = self.llGround( Vector3(0.0, 0.0, 0.0) )
                pos = self.llGetPos()
                self.llSetPos(Vector3(pos.x, pos.y, land + (targetheight / 2.0)))
                self.llSetScale(Vector3(x,y,z))
            elif key == “width”:
                # set width of prim
                targetwidth = float(section[k]) * length_conversion
                my_scale = self.llGetScale()
                x = my_scale.x
                z = my_scale.z
                y = targetwidth
                self.llSetScale(Vector3(x,y,z))
            elif key == “depth”:
                # set depth of prim
                targetdepth = float(section[k]) * length_conversion
                my_scale = self.llGetScale()
                y = my_scale.y
                z = my_scale.z               
                x = targetdepth
                self.llSetScale(Vector3(x,y,z))
            elif key == “color”:
                # set color of prim
                targetcolor = section[k]
                if DisplayConfig.color_LUT.has_key(targetcolor):
                    v = DisplayConfig.color_LUT[targetcolor]
                    ALL_SIDES = -1
                    color = Vector3(v[0]/255.0, v[1]/255.0, v[2]/255.0)
                    self.llSetColor(color,ALL_SIDES)
                else:
                    self.llSay(0,” Invalid color – check spelling & case: ” + targetcolor)

The color Lookup Table (DisplayConfig,color_LUT) is initialized in the EventCreated method. Here are a few lines from the hundreds that define the colors.

class DisplayConfig(rxactor.Actor):
    color_LUT = {} # a dictionary object
    def GetScriptClassName():
        return “sampleconfig.DisplayConfig”

    def EventCreated(self):
        super(self.__class__,self).EventCreated()
        print “DisplayConfig EventCreated”
        # Red Colors
        DisplayConfig.color_LUT[‘IndianRed’] = (205,92,92)
        DisplayConfig.color_LUT[‘LightCoral’] = (240,128,128)
        DisplayConfig.color_LUT[‘Salmon’] = (250,128,114)
        DisplayConfig.color_LUT[‘DarkSalmon’] = (233,150,122)
        DisplayConfig.color_LUT[‘LightSalmon’] = (255,160,122)

Lastly, here’s a quick video of me creating a default cubic object and assigning it the configuration data above. The text is hard to read and you can’t see the touch event. However, you will see the object changes size and color to match the configuration data. When cloned by SHIFT-dragging, the copy is left above the ground, but when clicked, it attaches itself to the ground. I’ll try to replace this one with a higher quality recording in the next day or so.

Happy New Year!

Today’s tutorial involves the construction of a realistic working overhead projector. It’s realistic to a point, but it doesn’t project the slides onto your avatar if you step between the projector and the screen! Here’s a video to give you a sense of what it’s like.

I’m going to assume that you can build or find a suitable projector and screen using the techniques described in the tutorial on the streamlined tool chain. I chose this one by Jeff and colored it with my own textures after assigning the mesh to a cubic prim. The screen is just a pair of thin rectangular prims. For this exercise I didn’t bother with a tripod or other mounting hardware. Further, I’ll assume you can create a slide and place it on you projector, much like this:

Create a small cube to hold the RTT camera and position it above the slide near the mirror and lens. The projector I’ve chosen has an offset mirror & lens so I place the RTT camera directly above the slide where the mirror and lens should be. Dimensions of 0.05m cubed should be fine.

Drag a texture on the blank screen and record its UUID. Modify the samplertt.py script in the following ways and save it as overheadrtt.py. The key five lines in my script are:

        pos = self.llGetPos()
        lookAt = pos + Vector3(0, 0, -0.340)
        cameraName = “overhead_cam”
        textureId = “303a8c94-e879-4215-a3a9-43f0cf77caa7” #slide_texture
        textureWidth = 512
        textureHeight = 512

The script is assigned to the cube by setting the class name to overheadrtt.RttCam (case-sensitive.) The first line gets the position of the cube. The second line tells the camera to look at a point .34m below. You should determine this value by calculating the difference between the center of the cube and the top surface of your slide. (It won’t matter if you use the Z-coordinate of your slide since the slide is very thin.)

After you save the script and restart the Python interpreter, you’ll see an inverted image which may be rotated if you rotated the slide object or the screen object while positioning them. Remove all rotations by setting the angles to zero and try to compensate by rotating and flipping textures. You can also decide whether you want conventional overhead projector behavior where the presenter faces the audience and the slide is oriented the correct way for the presenter, or whether you want the slide oriented towards the audience as it is in my example.

Before we finish, we have to deal with the plywood block. You can shrink it to .001m cubed, change the color and even make it almost transparent. Before you do any of this, link the projector to the cube and edit linked parts to select the cube. It can be very difficult to find a completely transparent cube! A better solution would be to implement a command in the script to toggle its transparency between 0 and 100%. You can combine this action with the existing logic that turns the RTT camera on and off.

If you have a collection of slides in a textures folder, you can drag the textures at will onto the top surface of the slide. You can amuse your audience by moving the slide around with your mouse. (You don’t have to edit the slide prim to do this.)

I leave it as an exercise for the reader to organize a slide flipper and a nice animation for the presenter  to flip the slides.

The only documentation available on the RTT camera at present is the sample Python script (samplertt.py) in rexserverScriptenginesPythonScriptSamples. Here’s the full code listing:

The RTT camera is implemented in the viewer. The rexRTTCameraWorld method (line 35) instructs all avatars in the region to create a camera at position pos, looking in the direction of lookat and render the scene onto any texture with the given textureId. A localized method, rexRttCamera, operates on just the agent invoking the script.

We can use this script with a few small changes to implement a mirror. First, reset the material in the mirror portion of the dresser to blank. In my case, this was the third material in the rex material panel, though the material was called 2_Metal_Corrogated_Shiny.

Next, we need to make thin prim to hold the texture. The “glass” in the dresser model is recessed into the wood, so it is possible to create a thin prim that just touches or penetrates the wooden frame. The following discussion assumes that your dresser is positioned at the south end of a room. You should build the glass prim without any rotations. Otherwise, you’ll need to code rotations in the script, and that can be painful if you’re not conversant with rotations in LSL. The dimensions of my mirror were:

X (width) 0.850m
Y (depth) 0.020m
Z (height) 0.608m

The rotations were all 0.0.

The front texture (facing my avatar) was set to 2_Metal_Corrogated_Shiny. When the mirror was carefully positioned in the frame, the effect was indistinguishable from the original design. Assign a name to the prim if you haven’t already.

Copy the samplertt.py file to samplemirror.py and make the following changes. You don’t need to shut down the server or the viewer, but you do need access to the server file system and console to do this:

1. Change line 15 to:    return “samplemirror.RttCam”
2. Change line 19 to:  print “samplemirror.RttCam EventCreated”
3. Change line 30 to: lookAt = pos + Vector3(0, 0.010, 0)
4. Change line 31 to:  cameraName = “mirror_cam”
5. Edit line 32 by substituting the UUID of 2_Metal_Corrogated_Shiny for the UUID assigned to the textureId variable. (To get the UUID, right-click on the texture in your inventory and “Copy Asset UUID”. You can paste this into the editor in the conventional manner.)

Save the samplemirror.py file.

The lookAt parameter above is set to look at the surface of the mirror, which is half the depth in the positive Y direction from the center of the mirror prim.

Edit __init__.py in the sample directory. Add the line “import samplemirror” to the end of the file and save it.

When you alter or add a Python script, you need to restart the IronPython scripting engine. You can do this without restarting the entire server by typing “python restart” in the opensim console. (In Windows this is the DOS command window with rexserver in the title.) 

Edit the glass prim and select the rex tab, Misc sub-tab. Set the class name to samplemirror.RttCam and close the editor dialog. (Note that the portion of the class name after the period must match the case of the name used in the code.)

If you’ve done everything correctly, clicking on the mirror will result in something like this – an inverted image! Clicking again will result in the default texture being displayed.

The inverted image problem is easily fixed by setting the horizontal and vertical flip options in the texture tab for the mirror.

With the basic functionality in place, there are a couple of refinements you should attempt. Firstly, if you zoom in on the reflection you will notice that the image is a little blocky due to the low resolution (caused by the 128 x 128 texture). Secondly, you should be aware that the RTT functionality is optimized for textures whose dimensions are a power of two. The mirror is rectangular. Mine has proportions of .850/.608. The texture has dimensions of 128 x 128. The Python script is coded to capture a 256 x 256 image. You could find or make a model that has mirror with better proportions (square or twice as long in one dimension as another). The approach I took was to use a square mirror (.85 x .85) and a higher resolution texture 256×256. The bottom part of the mirror is buried in the frame so it looks rectangular. I also linked the mirror and dresser, and scaled the combination up a little so that the top of my avatar’s head was just visible in the mirror. Lastly, the reflections are stronger if you have some local lights.

I recommend modeling with Sketchup 7. The new templates for working in different measurement units make it so much easier to build models that transfer correctly to realXtend if you choose one that is in meters. Start with “Simple template – meters” if you can’t decide. If you haven’t installed Google Sketchup, you can get it here. After installing it, you need to add two files to the Sketchup plugins directory. You can retrieve them from here.

Before following the tutorial steps below, be sure to edit the ogre_export_config.rb file. As distributed, its assumes that the user’s login name is “Peter” and that there is  a folder called “My Models” under “My Documents”. The username on line 39 also needs to be changed unless your login is “Peter”. You must create the target directory “My Models” or whatever you use before running the procedure. Also, edit line 47 to reflect the location of the OgreXmlConverter tool and line 54 to indicate the location of the rexmeshtool.

The following screenshots illustrate how to use the tool chain to import models into realXtend very quickly.

Step 1 – delete the avatar. With the selection tool (arrow) selected, click on the avatar and press the DEL button.

Step 2 – File –> 3D Warehouse –> Get Models…

Step 3 – In the search box, enter “Bedroom dresser”.

Step 4 – In the search results, select “Dresser with Mirror” by Bearly. We’ll use this model for another tutorial about making mirrors. When you click on the model, you are presented with a more detailed view that allows you to rotate the object and see the sides and back. Note that the dimensions are also provided on the details page.

Step 5 – Click the Download button to load the model into Sketchup. The model is inserted. Your cursor is the four-headed move/copy one, indicating that you can position the object before left-clicking to finalize the placement. Try to place the dresser at the origin, with the model centered on the origin.

Step 6 – Make sure the model is selected (highlighted in blue.) If it is not, click the selection tool (the first icon on the toolbar) and click on the model.

Step 7 – Export the model and launch the xml2mesh and rexmeshtool. Tools –> Export Selection to Ogre Mesh

Step 8 – Enter a name in the popup box that asks for a name for the model and click OK.

Step 9 – Verify that the export produced a non-zero number of triangles and click OK to proceed. If you do see a zero triangle count it is because you forgot to select the model before exporting it. Note the number of materials. If it exceeds 12 you will have a problem assigning all the materials in realxtend.

The OgreXlmConverter will be launched in a console window. You will typically see an error message at the end about no skeleton being present – just ignore it. Next you will see the rexmeshtool splash screen. It wants you to select DirectX or OpenGL rendering. It doesn’t matter which one you choose.

Step 10 – Adjust the positioning of the model in the rexmeshtool.

• Set the X, Y and Z Align drop downs to “center”. This ensures that the mesh will be centered in the base prim that you map in onto in realXtend
• The axes are different between rexmeshtool and realXtend. To rotate the dresser so it faces you, set the Y Rotate value to 90 degrees.

Step 11 – Click “Save changes & exit”. If you inspect your “My Models” folder, you will now have a sub-folder called “Dresser” and within it will the following files:

If any errors occurred in any of the export and conversion steps, they will be listed in the logfiles which are conveniently separated from the logfiles for every other model.

Step 12 – Import the mesh and the materials into realxtend.

• Create a cubic prim and size it roughly to the proportions of the dresser
• In the rex / display tab assign the Dresser mesh to the mesh name
• As this point the mesh becomes visible and you can determine whether the orientation is correct for the intended location. I prefer to size the underlying prim to the exact size if known. You will recall from step 4 that the dimensions were listed as 6’ 6 7/16” H x 62” W x 20” D. In metric that’s 1.992m x 1.575m x .508m. Adjust the X, Y and Z size fields in the Object tab to suit your object’s orientation and set the “Scale Mesh to Prim” option in the rex / Display tab.
• On the rex / material tab, assign the materials in the order 1_Wood_Cherry, 2_Metal_Corrogated_Shiny (sic), and 2_Metal_Corrogated_Shiny. Note that there are only three materials, not four as reported by the Ogre exporter (presumably because some triangles have been merged.) Note also that the prefix on the materials in this screenshot doesn’t match the filenames above as a result of having to redo some of the screens at a different time.

Voila! You have a nice dresser, correctly scaled!

You’ll find that this procedure takes very little time once you are familiar with it, typically a couple of minutes. The whole world of the Google 3D Warehouse is now available to you. Please observe the usage rights of model owners. I recommend setting the object description to the TinyURL of the model, which in this case is http://tinyurl.com/7y8gr5.

UPDATE: Learn how to make the mirror reflect like a real mirror using this tutorial.

Of Second Life, Gina says that “In [her] experience, it’s not an application that can be integrated into an enterprise environment.” I have to agree. The mistake is to think that you integrate Second Life or another other virtual world existing in the cloud into an enterprise. The trick is to work out how to integrate the enterprise into Second Life. Second Life is not just an application outside the firewall like Kenexa’s Brassring or ADP’s payroll services.  It’s a constellation of communities, creative individuals, micro-applications, an economy, government embassies, educational institutions, large corporations and small businesses, all evolving in strange and wonderful ways. We don’t integrate the Canadian market into an enterprise any more than we integrate the world of Second Life into the enterprise. It behooves the enterprise to determine whether there’s value in integrating into Second Life, and how its customers, partners, employees, competitors, shareholders and analysts might use this rich and social communication channel to interact with the company.

Gina mentions the problems connecting to the rapidly expanding Second Life grid. These problems are strictly a function of technologies like NAT’ed firewalls and a company’s security policies. They’re not something you can change overnight or inexpensively. However, Second Life is the canary in the coalmine here. If an enterprise can’t manage connections to the Second Life grid which is growing by hundreds of servers per month, there’s no way the enterprise can connect to the sprawling cloud services of companies like Microsoft. (See this short video for a brief overview of a highly dynamic containerized data center that can move around to take advantage of cheaper land or power and faster internet connections.) There’s a big impedance mismatch between the rigid, predictable highly managed network run by IT and the wispy nature of the cloud.

To be fair to IT here, the problem is not just connectivity. Even assuming that there are no virus threats in a typical virtual world viewer, there are compliance and trust issues. IT has to ensure that sensitive content (intellectual property, employee data, customer data) is not made public by an employee exposing such data either by copying it to the virtual world or building an integration bridge between enterprise applications and the virtual world in the cloud. Most IT organizations buy compliance engines from network equipment vendors and are thus constrained by the filtering technology provided by the vendors.

The trust issues in virtual worlds arise from the peculiar insistence that your name in Second Life can’t be your real name and from the absence of any facility for a corporation to attest to the identity of someone purporting to represent the company. This is not a problem unique to virtual worlds as Sarah Palin well knows from her interview with the fake Nicolas Sarkozy.

The challenges of integrating into Second Life prompt some enterprises to implement Opensim, realXtend, Olive, Qwaq or other virtual worlds inside the firewall. It is a great way to expose the company to the capabilities of these platforms for collaboration, data visualization, simulation, training, media production, etc. The costs are probably higher than for Second Life since there are fewer sources of assets (content) and services. Opensim and realXtend are still alpha quality. Qwaq is extremely new and generally requires Smalltalk skills to extend it. The freelance designers and consultants who can meet you in Second Life can’t meet you inside the firewall unless you bring them to your physical facilities or arrange VPN access for them. Even then, it’s extremely difficult for them to bring assets into your private world from the external ecosystem. Without those experienced designers, builders and scripters the learning curve for the enterprise is definitely steep. (We constantly use the word steep when we mean shallow – the time axis is horizontal and the vertical access is proficiency, so a complex system has a shallow learning curve.) The more expensive systems like Olive include rich asset libraries and usually include some packaged consulting.

I know from discussions with Gina that her views are shaped by her particular training challenges. Part of Gina’s group develops technical training for hardware systems still in beta. The technical documentation is incomplete, there are bugs in the products, and demo hardware is hard to acquire in sufficient quantities. Their target audience is the trainers who will train others, and the first teams who will install and support the beta equipment at customer sites. The team doesn’t have time to develop detailed models of storage devices, controllers, connectors, cables, etc., and script them to slide in and out of racks, expose their inner workings and animate the replacement of field replaceable units.

Another part of Gina’s group develops training materials for partners and customers. The challenge here is keeping up with the constantly changing functionality of the software. The production cycle for the instructional materials is already quite long, and having to maintain materials in an additional format could be burdensome, especially when the tools to move assets from one environment to another are limited or non-existent.

Sloodle is the first attempt to wrap a 3D interface around a 2D course management system. It enables the projection of 2D content  (course schedules, chat rooms, quizzes, slide presentations, etc.) from Moodle-based systems into Second Life virtually immediately. It’s an interesting first step but doesn’t go very far towards reusing 2D assets in a 3D world. Moreover, it doesn’t attempt to address the issue of presenting animated 3D objects from Autocad or 3D Studio Max into Second Life. The only other 3D VLE (Virtual Learning Environment) that I know of is Edusim, a Croquet-based teaching environment driven by a provider of interactive electronic whiteboards used in classrooms. Some progress has been made recently in bringing Collada-based assets into Cobalt, a new viewer for Croquet-based worlds. Neither of these tools directly addresses the needs of corporate instructional designers or corporate learners.

Proprietary LMSes will eventually adopt a 3D front-end, but whether they adopt the common open source platforms or continue their proprietary practices remain to be seen. The Immersive Education Initiative is working to accelerate the adoption of immersive environments by developing cross-world data standards (Open File Formats) and a open education grid (MediaGrid.org) for the exchange of educational assets (including SCORM-compliant assets used in many corporate environments today.) The MediaGrid should provide Gina’s team with a choice of platforms, tools and basic assets (classroom affordances for example) as well as best practices and a community of subject matter experts to draw on. Her IT organization will still have to solve the problem of connecting to a dynamic multi-platform grid or her team will be denied access to increasingly valuable tools and knowledge.

There’s a lost opportunity here which needs an organizational solution. If the 3D assets had been built by a corporate design group that focuses on long-lived or reusable assets, the ROI would be dramatically different. Imagine that the engineering CAD systems deliver simplified meshes of the new products to this design group. The design group, versed in the virtual worlds technologies that the company uses, prepares assets for Gina’s training team, for the video group doing animations for the launch video, for the virtual trade show platforms used to reach customers far from the trade shows in New York, San Francisco or Las Vegas. They use these assets  to populate virtual data centers attached to virtual Executive Briefing Centers. Gina’s team now has options. The first training class may well be done in the conventional way due to time pressure. Learning from this initial training course, her team delivers the second wave of training on a global scale using a combination of simulations in a virtual world, video from the first class, plus real-time collaboration with the trainers and the first wave of experts who are now in the field with some installation experience under their belts.

There’s a precedent for this central group of designers  who prepare reusable assets – it’s the corporate presentation or art department that develops the PowerPoint presentations and Flash animations that the rest of the company repurposes for specific situations. Few of us have the time to develop the skills to build Flash animations, but we recognize when they should be used and happily leverage the corporate resources that can produce them.

So far we’ve only discussed training materials originating inside the corporation. For today’s continuous, just-in-time learners access to material outside the corporation is just as important. Most canned content is accessible to corporations for read-only consumption. The challenge comes with multimedia content combined with live commentary from participants (text and/or voice) or with 3D content in Second Life or other public virtual worlds. The compliance issues associated with monitoring content in those interactive channels cause many IT organizations to declare them off-limits because their compliance filters and e-Discovery archivers only work with email or HTTP traffic on port 80. As more 3D content becomes available on mobile phones, this stance will become increasingly untenable.

What about cultural issues? They are really, really tough to change. To give just one example – Anders and I sat through a presentation yesterday where the speaker talked about the confrontational culture in his company. It was prized as being almost Darwinian in its ability to select the best ideas. Despite support from the most senior executives for virtual meetings, the middle and upper management objected that the technologies prevented them from shouting and bullying. It sounded like a company that eats its young.

Perhaps the toughest cultural challenge for companies adopting virtual worlds for training is the participatory nature of many of these worlds. These are not platforms for projecting content and people into the physical world in the way that LiveMeeting or Webex are. They are much more akin to distributed Lego Mindstorms(tm) kits. Leave the room for a little while and someone will combine the parts and re-program them in ways that you didn’t anticipate. The trick is to build a culture that wants to leverage the kind of creativity that a Lego Mindstorms kits generate.

The solution involved hacking the Ruby scripts to create a separate folder for each model exported from Sketchup, and invoking the rexmeshtool application after the OgreXmlConverter was run. A side benefit of the process is that the log files for each export and conversion are stored in the model’s folder.

Since I was using a newly built PC, I installed the just-released Sketchup 7 and started to modify the scripts mentioned in the tutorial. (The scripts were written by Fabrizio Nunnari, based on the initial script by Kojack.)  When I finally tested the results this morning, realXtend 0.4 wouldn’t import the meshes. Since I was using a new version of Sketchup, a new version of realXtend and a freshly rebuilt laptop, I had to test a number of configurations to determine where the problem lay. I was able to import the meshes produced by Sketchup 7 into rexserver 0.31 using rexviewer 0.31 on an older laptop, but could not import them using the rexviewer 0.4 connected to rexserver 0.31. I logged a bug report in SourceForge this afternoon and posted a message in the realXtend group. Eight minutes later Gustavo Alberto Navarro Bilbao confirmed that he had discovered the same problem with realXtend 0.4. I have subsequently verified that the meshes can be loaded without errors by the Cegui Mesh Viewer.

Since I had to learn Ruby yesterday to modify the exporter script, and the author of the script was also a first time Ruby coder, I’ll do a little cleanup before I post the revised scripts here (today or tomorrow). The scripts are not backward-compatible with Sketchup 6. If possible, I’d like to address that problem before I release them. If any Sketchup plugin developers have pointers to the API documentation for chdir, mkdir_p and similar calls for Sketchup 6, please drop me a comment.

Opening scene in Beneath the Waves

Major features of this release include a full implementation of Ogre materials and material scripts, including lighting effects and a material editor. Ogre materials can be used on meshes, primitives and particles. Flash animations are supported, and used frequently in the quest embedded in the sample world. (If at first you’re puzzled about how to proceed, approach one of the fish sculptures and click on it. From there you should be able to work everything else out. There are more clues in the video below.) Mozilla plugins are discoverable by the embedded browser, so lots of new functionality should be possible. Another foundation feature that enables a more realistic world is mesh animations. From fish to flexible trees to caterpillars, these animated meshes will add a huge amount of realism (and fantasy) to realXtend worlds.

Once you can present a realistic animal or a rustling tree, it needs to make sounds that emanate from it, so there’s now support for location-based sound loops. And to move that animal over the landscape or under the waves, there’s a new rexbot feature that allows you to control the locomotion of these non-player characters.

There’s so much more to describe, but it will take quite a few postings to cover any of these features in adequate detail. I’ll focus the next few posts on those features can enhance enterprise applications. For now I’ll leave you with the short video and encourage you install it and try it out.