Programming & VR Programming & VRI've been programming in Python
for 10 years now, and so far haven't found a more beautiful
language to draw me away from it. Although my official titles at my
previous
job were "Designer" and "Artistic and Technical Researcher", I spent
much of my time (3 years) working on solving complex programming tasks
(you can read about that below). I've been an Open Source
developer since 1996, and spent 2 years from 2001 through 2003 focusing
on
various Open Source projects. I was a partner in VexTech Corporation for three years
where I did
closed-source development based on Open Source
packages. I currently run my own small software consultancy.
I have various pieces of documentation
which seem to be useful to some people:
There are various modules I've created floating around the web that I haven't bothered to link here, I've contributed to a number of projects including wxPython, win32all and Stackless Python, and generally de-list a module when I no longer see the need to be a distribution point for it (such as when it is incorporated into another project).
Most of my work as part of VexTech focussed on one of our joint partnerships, Cinemon Inc (of which I am the CTO). Our first product, Cinemon is a Cable System Monitor, that is, a server which sits in a Cable ISP/Cable Television operator's head-end and monitors the health of the equipment both in the head-end and out in the field. The system uses TwistedSNMP, PySNMP, PyTable, PostgreSQL and a few other tools to monitor networks of a few thousand or tens of thousands of cable modems to provide early-warning notification of network failures and/or degradation.
I also worked on the VoIP provisioning module for the VIBES ISP billing system, a project on which I continue to work with my new company.
Commercial Software (for Tpresence Inc.)I worked for Tpresence Inc. (A.K.A. VRTelecom) for three years under contract as a designer (one year) and a researcher (two years). The company created a Virtual Reality system for use on Windows desktops using standard hardware. The primary product, Holodesk Communicator, was released in (if memory serves) 1999, and included person-to-person voice chat, three different avatar formats, approximately six background environments, with the ability to use any standard VRML 97 world as a background, and a set of collaborative mechanisms including a shared in-world whiteboard, slide show, file sharing, and avatar-based gesturing (all produced by "in-game" scripting of core functionality provided by the underlying system).
VRML 97's event model was horribly broken, especially as implemented in Cosmo Player. The original code for Holodesk (when I arrived at the company) was attempting to use Java-based VRML code with custom-written Java classes for every piece of content (and there was almost no content as a result of the extremely technical requirements for creating it). The Java bindings in Cosmo were so flaky that the system was usable only for a few minutes at a time.
Although technically working as a Designer at the time (charged with optimizing one of the world's geometry), I concluded that there was no way to work with the system as designed. I embarked on a project (with my friend Eric Mason) to completely re-construct the system using certain principles I had discovered in my Thesis work regarding ways of producing robust VRML 97 code (basically an object-oriented approach using VRML prototypes religiously with ECMA-Script as the scripting language). Combined with the exploitation of the Cosmo COM APIs, it was possible for us to produce VR environments with access to specific system services (such as file-sharing) which Eric coded using C++.
We went from a programmer-coded environment (every object was a Java class handling network data-sharing itself, as seen in the only text on the subject at the time (written by my thesis supervisor, incidentally)) to one which could load user-scripted worlds based on an open content standard (Living Worlds). We went from a system that might last for a few minutes at most to one which ran stably for hours. We produced one of the most complete Living Worlds-based systems ever created. Basically, within the limits of the technology available, we produced a cyberspace browser.
The prototypes I produced during this project were still the primary source of interactivity in our worlds 3 years later, with only a tiny number of bugs logged against tens of thousands of lines of unique code running in a fundamentally non-deterministic system and embodying the bulk of the direct user experience. I trained three content developers in my approach to VRML 97 coding, and they were largely able to construct new objects to order without any alteration of the basic prototypes I provided or the services Eric had exposed.
I am very proud of this work, and I think I can say that, along with Eric's masterful coding on the C++ side, it was a significant contribution to the company.
This project was carried out at the same time as the Interactive Objects project. The original avatar code was based on custom coding throughout the system and provided only the most rudimentary features. I created a set of bridge prototypes which allowed standard H-Anim avatars to be loaded into our new Living Worlds-based system. Eric had a lot of headaches working around the quirks of Living Worlds (poorly specified) Avatar semantics, but he did manage it in the end.
As a bonus, I developed a system for applying action scripts to avatars (eventually including "displacer" actions (an H-Anim term meaning a vertex-interpolation script)) which became one of the most popular features in the system. The ability to use almost any H-Anim avatar provided for a wider choice of avatars, but more importantly, it made it possible for us to have our in-house creators only worry about modelling the avatars. As a note, it also meant that during the VRML99 conference, Holodesk was used to demonstrate a number of H-Anim avatars in live VR worlds.
As another bonus, the avatar system was generic enough to allow the creation of bridge prototypes for three other avatar formats. As a result, it was possible for our users to install custom avatars from other VR systems with full support for their built-in actions.
SkeletonBuilder was originally an in-house tool to allow our designers to produce H|Anim-compliant VRML 97 avatars from the output of 3-D Studio Max, Alias Power Animator and Maya. I developed the primary engine and original interface (using the mcf.vrml library and Python's Tkinter GUI) over a weekend, and that version of the software was used for quite some time within the company.
Later on, as we expanded our operations and wanted external developers to be able to generate content for the Holodesk system, I rewrote the interface to be more compact and professional looking (replacing the Tkinter interface with a wxPython one). This rewritten version of the project was distributed on the content creators' CD.
I was involved in trying to get the Living Worlds Working Group of the VRML Consortium to improve the Living Worlds specification to be more readily implementable. Eric and I spent a huge amount of time trying to work around and/or fix problems with Living Worlds as we were building Holodesk 1.0, and we wanted other companies to be able to produce content we could use (in a standard format) without that barrier to entry. The Working Group eventually disbanded, abandoning the standard as too complex.
During our work with this committee I proposed a dramatically smaller standard (Fruits of Living Worlds) modelled loosely on the Component Object Model (COM) from Microsoft, but the untimely demise of VRML (VRML largely imploded when the group charged with directing it decided to re-focus on "Web3D", instead of "Cyberspace") made attempts to define a VRML-related standard somewhat pointless.
Among the projects I undertook during my period as a researcher with Tpresence was the "Portals" Next Generation multi-user technology (MUTech) project. This project attempted to create an entirely distributed interconnection mechanism which would allow huge numbers of computers to participate in the maintenance of a shared/negotiated Virtual Reality environment linked to any number of real world services.
I produced and delivered the prototype system three or four months before my contract expired with Tpresence. Unfortunately, no-one had been assigned to work with me to learn the new system. With me leaving and no other MUTech specialist to continue the work, the project was shelved in favour of the original Holodesk Communicator code, the design of which was more familiar to the remaining development team.
From what I understand, the entire Portals project is currently sitting on a backup disk, but is otherwise untouched. This was one of the most disappointing features of my time with the company, as, at the time I wrote it (2000 and early 2001), the system was an amazing piece of work that could have made whole classes of Point-to-Point application considerably easier to develop. In retrospect, management probably knew that the company wouldn't last long enough to commercialise the new product (though they hadn't shared that information) and so decided to put their money into the more established product instead. It was likely the right decision, but it doesn't make the disappointment any less acute.
Having been pulled from the Portals project, I turned my last few months with the company to the problem of automatically generating and composing virtual reality worlds into content suitable for use with the Holodesk Communicator system. In large part this was an exercise in producing an intuitive interface for a complex and involved process. Although the result was functional, and was able to produce usable Holodesk worlds from the unmodified output of the various modellers, it would have been useful to have had another two months to work on the interface, which though usable, required the user to learn about the underlying object model, rather than allowing a natural interaction.
WorldBuilder replaced an earlier project which I had produced to manage the content development process. That system allowed the user to store individual prototypes in separate files, with the project files including the various used to prototype declarations, content files etc. in a "recipe file" which included "coded" interactions, settings and markers for further customization points. WorldBuilder wrapped the process of writing those files (in reality, an entirely different mechanism was used for the process, but from the user's point of view it had the same effect) in a point-and-click/drag-and-drop interface. I'm not sure if WorldBuilder ever made it onto the content development CD. The earlier recipe-file system was included on the content development CD.
I spoke/presented at a couple of VRML conferences regarding the work Eric and I did with a number of these projects. Tpresence has largely disappeared these days, closing up shop a few months after I left, so unfortunately I can't point you to downloads of Holodesk or SkeletonBuilder any more. The open-source package mcf.vrml (see above) on which SkeletonBuilder and WorldBuilder were built is still available, and I'd be happy to send anyone who's interested a copy of the Fruits of Living Worlds proposal.