Peter Amstutz, T. Reed Heges and Matt Barry

Virtual Object System: A new generation of Internet communications
The Virtual Object System (VOS) is a hierachical distributed object system [...]. It is an infrastructure for object-oriented network communication, and building flexible, distributed object networks for a variety of purposes, but our primary application is multiuser collaborative virtual environments. [...] Experimental Debian packages [...] Embedded web browser on 3D objects [...] Artists [...]

VOS is intended to be general purpose, and extensible for a variety of purposes and applications, but our primary application is multi-user 3D graphics environments. [...]

About VOS

Our original motivation was to start building The Metaverse: a shar- ed 3D virtual environment on the Internet, (inspired by things like Neal Stephenson's modern classic of science fiction, Snow Crash). Along the way we've created VOS, a new kind of networking system and protocol, with many unique features, including:

• Hierarchical organization of network-distributed virtual objects
• Network transparent access to objects (same API for local and remote objects)
• Objects have typing and tagging information to make it easy for applications to determine how to handle different sorts of objects.
• Simple XML-based object message protocol (which makes it easy to write scripts that use VOS)
• Automatic data updates help create a more dynamic environment
• Simple macro substitution language built into the protocol, along with the ability to refer to the replies of previous messages -- This means it is possible to specify compound transactions at the messaging level.
• Implementations in C++ and Perl

Our goal is to use this infrastructure to build multiuser collaborative environments. [...]

For a more extensive look at the VOS vision, and our thoughts about how we can create a new Internet reality, look at the opening chapter of the VOS Manual. [...]

[The VOS was also inspired by] Ted Nelson, dreamer of Xanadu[.]

An Introduction to the Virtual Object System
Posted 5 May 2002 by tetron

The Virtual Object System (VOS) is a hierarchical distributed object system, a desert topping, and a floor wax. It is an infrastructure for object-oriented network communication, and building flexible, distributed object networks. It also tastes good and will keep your floors shiny. In this article I discuss the core library and an example application under development that demonstrates some of the of power of using VOS. (A bit of shameless self-promotion for my free software project.)

VOS is a protocol and architecture design that you can use to build network application components (clients, servers, peer-to-peer nodes) for many purposes. It offers several convenient abstractions for the application programmer to support writing complex distributed applications.

VOS is explicitly object-oriented and supplies the infrastructure for passing messages between objects. Messaging is network-transparent, so the programmer is not concerned with the specifics of message delivery --- he or she simply passes the desired message to the target object. With this it is easy to implement remote procedure calls, where a message replying to a request can be matched up with that request. So far so good, but this describes about a dozen message passing systems already in use. What makes VOS different?

At the risk of stating the terribly obvious, in order to communicate with an object you must first know how to find it. Let me give an analogy with file systems: consider how difficult it would be if you could only refer to files by their inodes. In other words, directories don't exist, rather there is simply a large flat index of numbers, one for each file. To find out what other files exist you have to parse the files you already know about to find the inodes of the new files. Every file stores this information in a different place, of course. This would be a nightmare, wouldn't it? Well, this is essentially the state of the art of current distributed object systems. Typically in such systems objects are assigned unique identifiers by the object request broker (ORB, to use CORBA terminology.) Although an RPC call can return object identifiers allowing it to refer to other objects, every class will have a different way to do this. There is no uniform way to refer to an object by indirecting through another already known object. While it is the case that some systems such as CORBA offer a naming service on the side which does address some of these issues, there are many advantages to be had building such a feature into the core system that a separate naming service cannot provide.

A crucial feature of VOS is providing a standard protocol for expressing object interlinking, to the extent that it is part of the object model for a Virtual Object (hereafter termed "Vobject"). Vobjects consist of the following parts:
1. The Vobject exists with a unique name as a direct child of a Site. A Site is a Vobject (following all the other aspects of this object model) which acts as a connection point between processes. This is typically accomplished with a network socket.
2. The Vobject can exchange messages with other vobjects, with sites acting as intermediaries as necessary.
3. The Vobject has a set of type strings. These may be used to describe what interfaces this vobject supports, how to interpret the meaning of child vobjects, or tag the vobject for other special treatment by an application.
4. The Vobject has an ordered, associative list of links to other Vobjects. Following normal tree terminology the linked-to vobjects are termed children. Each link is tagged with a contextual name, used by the application to determine how to interpret the child in the context of the parent.
5. Vobject parent-child links are two-way. A Vobject can be linked to more than once, and the application can get a list of all parents of a particular Vobject.

Nearly all other features of VOS derive from this object model. Although we call VOS a "hierarchical" distributed object system, object interlinking is actually a directed graph. However, it is at its most useful when used to group objects in "contains" or "describes" relationships. We use URLs to refer to vobjects, so the meaning of the following example should be fairly intuitive:

• vop://interreality.org/world/ball/position

This refers to the vobject storing the position of a ball, which is contained in a virtual world at the site interreality.org. Note that this path is not the only way of referring to this object. Here are a couple more ways:

• vop://interreality.org/1264095060
• vop://interreality.org/1474612399/position

The former is the unique name of the vobject on its site. The latter directly addresses the "ball" vobject (instead of indirecting through the world vobject) to the position vobject.

Note that the fact that "vop://interreality.org/1264095060" happens to represents the position of something is entirely contextual, and determined by the parent-child linking. Another vobject could easily link to this with a different name and an entirely different meaning --- not so farfetched as it sounds, because a vobject can take on multiple types describing multiple interfaces.

This system provides the programmer a powerful and flexible way of organizing network-accessible objects. Because vobjects link in a uniform way, the same tools to access and inspect the vobject structure can be used for a variety of applications. For example, one tool is the command line shell mesh which allows one to browse vobject structures using familiar commands like "cd" and "ls" as well as send and receive messages interactively.

VOS is heavily event driven and allows one to register as an event listener to be notified when certain things happen, such as changes to a Vobject's list of children. This supports (and encourages) a style of programming similar to the model-view-controller (MVC) framework.

VOS has a number of other features which I will not enumerate here, for the sake of brevity.

As useful as it has turned out to be, VOS was not an end unto itself. Rather it is being developed to support a specific application which I briefly describe here.

The application is distributed, interactive multiuser 3D for the Internet. Few applications in computer science have received so much attention in the popular media, but have thus far failed to deliver in terms of an open, general purpose system. When deciding to embark upon this project three years ago, we decided to take a network-centric approach, rather than the more traditional approach focused on rendering. Three-dimensional graphics have advanced enormously in recent time, whereas much of the software infrastructure of the Internet --- application protocols like HTTP and RPC systems like CORBA --- have shown to be inappropriate for this task. Rather than work around the limitations of existing software, we decided build our own which has today evolved into the present VOS design and implementation. Although ultimately built with the purpose of describing 3D scenes, VOS is much more general purpose: one application for VOS is a network-accessible MP3 jukebox. I have also gotten email from someone intending to build a P2P network based using VOS.

We use the excellent Crystal Space 3D engine rather than writing our own, which allows us to focus on the networking and user interface aspects rather than the hairy details of 3D rendering. Presently the 3D client supports box and sphere primitives, loading 3D models from several standard file formats (such as .3DS), billboards (2d sprites that always face the camera), specifying world geometry directly using vobjects, and colored point lights. These objects can be added, removed, positioned, scaled, rotated, and otherwise modified on the fly through either direct manipulation in the 3D client, or using other tools such as the previously-mentioned mesh command line shell (which is able to do so despite having no intrinsic knowledge that the vobjects being manipulated describe a 3D scene.)

We have implemented a Virtual Webcam as an option to the 3D client that writes out an image file rather than rendering to the screen. If one visits our web page, one can see a live view of what is happening on our world server. If you were to join the world, your avatar would show up on the web cam (as well as the screens of anyone else present.) Furthermore, the webcam itself exists in the world with an avatar (a model resembling a movie camera.) The camera can be rotated and repositioned like any other 3D object, and the webcam's view will change accordingly.

The VOS reference implementation is in C++ (with additional lightweight implementation in Perl) and licensed under the GNU Lesser General Public License (LGPL). I believe that others might find the VOS platform useful for developing their own network applications.

About the Applications

See the pages below for more information and screenshots.

• Ter'Angreal, the multi-user 3D VR client -- the idea that started it all, is well underway using the CrystalSpace 3D engine and VOS to open the doors to the Metaverse ...[.]
• mesh (MEtaSHell) is a command-line interface to a running VOS object system, modelled after a Unix shell.
• The MP3 Jukebox keeps a playlist of song files, and includes a script to remotely play, stop, skip, shuffle, etc, a web interface, and rudimentary support for Icecast streaming over the Web. Files may be streamed from remote fileservers[.]
• The Metatronic remote GUI display client lets GUI components be distributed accross networks (just like Ter'Angreal's 3D objects), dynamically modified, and used collaboratively. This system also provides a VOS-based GUI system to other VOS applications.
• Extra libraries written for VOS but usable by anyone (they don't depend on VOS):
  • Use the Service discovery library to advertise and query for services on a local network or on a specific host[.]
  • Use libASE to parse information out of 3D Studio/3ds Max "Ascii Scene Export" files[.]

Ter'Angreal

This application represents the original driving goal that eventually spawned VOS. Ter'Angreal is a general purpose VR application. Using Ter'Angreal you can explore dynamic online virtual worlds, interact with the world, and talk with other people as well.

Screenshots

Here is a temple and a tree created by Sean Gallager (a/k/a 'hoda').

Well, the image itself pretty much says it. You can apply "text/plain" as a material to an object and you'll get text drawn onto the texture as shown.

This image demonstrates an experimantal feature: using surfaces on objects as a live Web browser (yes, it's a fully functional embedded Mozilla browser!). Look for this cool feature in future versions.

Now on startup Ter'Angreal can find available virtual worlds automatically and present the user with a list. This uses the new service discovery features in VOS.

This image demonstrates an animated MD2 (Quake II) format model, and a simple particle effect ("snow").

This is a "billboard". It is a 2D image that always faces towards the user. They can be shaped (have transparent parts) as you see here.

More examples of model loading (OBJ and 3DS). All objects can be moved, rotated and scaled using the mouse and keyboard. All other users in the world see all changes immediately.

Some shout-outs to cool projects

• Crystal Space 3D SDK
• wxWindows Cross Pratform GUI Toolkit
• OpenVRML
• Blender 3D modelling and animation software
• GNU
• Debian GNU/Linux
• Howl Rendezvous/Zeroconf ports

Object Type Definitions

OTDs define Metaobject types. An OTD is an XML document which describes what should be expected of a particular object type: messages it accepts, emits or replies with; child objects of certain names which should exist; general documentation on the type; and links to downloadable code on the web which implements the type (both "plugins" or just examples). [...]

Browse OTDs

core

• #000: core

misc

• #001: property
• #007: talkative
• #008: jukebox
• #009: song
• #010: text
• #011: space
• #012: metadata
• #013: hypercard
• #018: sound
• #019: avatar
• #021: property.extrapolated

a3dl
MetaObject types for representing 3D objects

• #002: object3D
• #003: object3D.cube
• #004: object3D.sphere
• #005: object3D.mesh
• #006: object3D.model
• #014: object3D.billboard
• #015: object3D.materialinfo
• #016: world
• #017: light
• #020: viewpoint
• #032: object3D.snow

image2D
MetaObject types for representing layers of 2D images.

• #022: image2D

gui
Types for representing components and layouts of graphical user interfaces (GUIs)

• #024: widget
• #023: widget.container
• #025: widget.button
• #026: widget.label
• #027: widget.input
• #028: menubar
• #029: menu
• #030: widget.select.boolean
• #031: widget.select.list
• #033: widget.input.numeric
• #034: widget.input.numeric.slider
• #035: widget.input.color
• #036: widget.input.file

Publications

• Peter Amstutz and T. Reed Hedges: The Virtual Object System: An Open Platform for Internet Multiuser Virtual Reality. [PDF]
• Peter Amstutz and Andrew H. Fagg: Real Time Visualization of Robot State with Mobile Virtual Reality., in Proceedings of the International Conference on Robotics and Automation (ICRA), May, 2002 [PDF]
• Peter Amstutz: An Introduction to the Virtual Object System

Annotations
This project was at the first sight interesting and led as well to oth- er webpages. But as longer and closer we looked at it we came more and more to the conclusion that we had here and on the linked websites indeed the actings by C.S. of the last years before, inclusive visions, arts, robotics, 3D simulation, architecture with columns, spaceships, like the starship U.S.S. Enterprise of the "Star Trek" saga, and so on.

We overworked and even extended this concept with our OntoScope component (see also the webpages of the Mekensleep Underware set and Roboverse), service discovery following the Peer-to-Peer, Grid computing and Castle in the Cloud™ Computing technologies, and also 3D cameras and the Ontoscope.

As an overall system, we have the