I had a comment from Eloise Pasteur on my last blog asking whether running Sikuli out of debug mode speeded things up. I said "a lot" but on reflection that may have been an overestimate. Anyway, the video above illustrates the use of Sikuli to rez in standard mode but this time I've included a couple of extra features.
Firstly, as prims rez, they chat and that chat is registered by a chart prim which updates a shared media chart texture based on the Google Visualization API. For the moment the chart is as basic as it could be but is intended as a reminder that we no longer have to reinvent 2D graphs inworld. In a more general way, it also illustrates the use of shared media as a complement to prims. There is doubtless plenty of further scope for this type of integration. Dusan Writer laments the lack of obvious shared media developments beyond the most basic (he sees this as a consequence of the poor uptake of Viewer 2.0). It would be nice to move this area on a little.
Secondly, after rezzing has finished, I used the Sikuli findAll command to locate the spheres and then count them, displaying the score in a popup. As the capacity of the sensor facility in SL is limited to 16 objects, this might be an interesting alternative to use of sensor arrays, albeit that it requires that objects be within the field of view, static and non-overlapping. Coping with rotation is also an issue with more complex objects.
One could go a lot further with Sikuli by introducing visual conventions for other parameters such as elevation and rotation. Prims might themselves have additional codes on them so a second level of prims could be added. "Intelligent" prims might act to close gaps by rezzing further prims.
As Sikuli is based on Jython, the Java implementation of Python, it has access to a wide range of code libraries and, more importantly, can read and write to local files as well as the web. For very simple, single-level builds therefore, it might facilitate documentation and re-rezzing. Of course, there are easier ways to do this already available but bear in mind that Sikuli could take objects exported in XML format (with appropriate permissions) and rez them inworld, maybe taking additional data on size, elevation, scaling, etc from a separate scene file. These refinements could be implemented via Sukuli's control of the Build menu of a suitable third party viewer. (In all this, I assume, of course, that you have created all components of the object; export under these circumstances is compatible with the SL ToS. Scripts are not presently archived so some additional work would be required).
More interestingly (and bearing in mind my 2010 predictions #4 and #5), Sikuli could be used to monitor changes in the scene (registered visually, via the web or communicated to a HUD prim watched by Sikuli) and make corresponding alterations to it. For example, if one scene is successfully completed, a flag is displayed and the next scene is rezzed. This begins to sound a little like learning design. The idea of using a vertical view of a scene in SL to design and implement a learning experience that responds to student activity is quite attractive.
A list of requirements for a simplified learning design implementation has been compiled by Scott Wilson, though it does assume the availability of a SCORM implementation. I doubt that I'll pursue the learning design aspect, not least because options such as PIVOTE and, at a lower level, LibOpenMetaverse already exist. Moreover, the requirement to have Sikuli running in the foreground on a PC somewhere is onerous, not least when you attempt to scale to multiple scenes being used simultaneously by different groups. It might be done in conjunction with a facility for camera repositioning but it would not be pretty.
That said, the introduction of a 4th dimension, viz time, into SL builds is pertinent to other smallscale projects I have in mind and Sikuli is definitely an option to consider there.

