In an earlier post I lamented the lack of printing support for notecards in Second Life. Bob Wellman commented that he submitted the original JIRA bug report requesting supporting for printing over a year ago. There followed some fruitful conversations and a suggestion that I contact Jani Pirkola at realXtend to see if he could squeeze the printing functionality into the next release.
I met Jani at the last meeting of the Gronstedt Group and followed up with an email. Jani hasn’t had a chance to reply yet (he’s got a new release of realXtend to get out the door!) but the conversations with Bob have continued to spawn ideas.
Bob is rightly frustrated about the use of notecards to define all manner of parameters to scripted objects. In a personal email to me this morning, he suggested that a new structured notecard – he calls it a datacard – is needed for specifying configuration data. He envisages datacards being maintained with your favorite spreadsheet program. Datacards would have two columns, one for names (or keys) and the other for values. He also envisages some new API calls in LSL (Linden Scripting Language) or the OpenSim API.
I responded that the meta issue is that LSL should have support for reading name/value pairs from all sort of data structures – CSV, XML, JSON, XLS, and ODF & OOXML spreadsheets. In concert with this, LSL should be able to deal with formats in some generalized document container (Bob’s datacard?), or external files (like the opensim.exe.config file) or delivered via RSS, ATOM or other web services.
Access to these formats will be much easier when the new implementation of LSL on Mono is completed. All of these data formats can be accessed more or less easily with C#. The OpenSim scripting implementation allowed C# to be mixed with (the fairly incomplete) LSL implementation many months ago. realXtend includes all the OpenSim scripting goodness, and adds IronPython scripting on the server side. As a .NET language, IronPython should provide easy reading of the abovementioned data formats as well.
So the next step in the thought process was to do with PowerPoint. Everyone is familiar with the dismal user experience of watching slides in Second Life progressively emerge from the primordial graphic ooze, taking advantage(?) of the progressive streaming features of their underlying JPEG2000 representation. It’s worse than lag on a busy island! Given that the Mono-based scripting engine will deliver 1-2 orders of magnitude better performance, and hence could support a much higher prim count, it makes sense to deliver PowerPoint slides as they were composed – as a series of graphic primitives delivered in a time sequence on a canvas.
I can envisage a projector object which accesses an external PowerPoint file (on Slideshare.net perhaps), and transforms the primitives on the current slide into their corresponding prims and composite prims on some whiteboard object. I’m assuming that text boxes would be converted to HTML on the fly and rendered as such on dynamically created prims of the right size. What’s interesting about this approach is the possibility of animating objects in the third dimension. For example, one might specify that a PowerPoint “fly out (up)” operation be mapped to a “fly one foot towards the viewer then follow an upwards arc before disappearing (de-rezzing)”.
This approach of returning to the graphical roots of PowerPoint slides also enables the projector object to process audio attachments, and to handle “hot spots” (clickable areas) on graphical primitives. Who knows, if this is done right, it could become the preferred mechanism for viewing AND interacting with PowerPoint slides in a distributed team setting. Just add a “tear-off” feature to clone a slide and you have real possibilities for team members to annotate or rearrange elements in a slide in a way that has not previously been demonstrated.