Chapter 4. Frequently Asked Questions

A: VOS stands for Virtual Object System. Specifically, VOS refers to the core object technology, but it often used to broadly refer to the entire project. Although VOS has been applied to a number of applications, we are particularly focused on developing multiuser 3D virtual reality.

A: A contraction of "Internet" and "Reality". The goal of creating a virtual reality system for the Internet that is genuinely useful. The notion that all parts of reality are closely interconnected, and that our software systems must reflect this principal. It's also a cool domain name.

A: The VOS object system technology can be used by any system or application that needs to share dynamic (changing) data and data structures accross a network or the Internet, or needs a framework for structuring objects and responding to changes in those objects and other events. VOS offers several tools to do this, including a flexible and efficient network protocol, the VOS network-transparent object-oriented data structure, extesibility for your own types as well as a library of existing object types, and utilities for manipulating Vobjects.

The primary application being develped by The Interreality Project is multiuser shared 3D virtual environments. You can use VOS for social worlds, artistic worlds, collaborative 3D data visualization, and more. But the VOS technology is not restricted to this application. Other current projects include using VOS as a management system for websites (such as the interreality.org site). In the past, VOS has been used to implement a streaming music jukebox.

A: The project was originally hatched in the spring of 1999. The design went through several revisions with a lengthy prototype phase beween fall of 1999 and fall of 2000 where many ideas were tested in a Java implementation. The modern C++ implementation, embodying a third major redesign, was begun in the spring of 2001.

A: In terms of manpower, the vast majority of the work has been done by Peter Amstutz and Reed Hedges. Other contributers are credited in the AUTHORS files. In terms of code size, VOS in total (including all libraries and applications) consists of about 70,000 lines of C++.

A: Presently (version 0.23.0) we support GNU/Linux, Macintosh OS X, and Microsoft Windows (Windows 2000 or greater).

A: All VOS libraries are licensed under the GNU Lesser General Public License. This allows you to use the libraries in applications which are themselves under any license, but if you modify the library you must release the source code for those modifications. Most of the VOS applications are licensed under the GNU General Public License. This means that any modified versions of those applications must also be released, or applications using portions of that code must be released under the GPL. Tutorial, test and example programs are released in the public domain and have no restriction.

We chose these licenses in order to, on the one hand, allow the use of the VOS libraries in any application, but on the other hand, promote collaborative development of applications like Ter'Angreal which in turn drive development of the libraries and technology in general.

A: There are two layers that implement VOS network communications: The network protocol, VIP, and the VOS library. for object management. VIP is a bit like a transport layer similar to TCP or UDP (though it is in fact built using UDP) and may be used by itself without using the VOS object system. VIP is implemented in a separate library from VOS.

A: You can certainly modify any part of VOS since the source code is available and uses Free Software (or Open Source) licenses. However, to specialize VOS for your application, you don't need to modify the VIP protocol or otherwise make it incompatible with other VOS applications! VOS is designed specifically to be extensible and specialized for various applications while still retaining compatibility with other VOS tools and applications in the areas which are not application-specific by creating new Vobject types, and utilizing whatever other existing Vobject types are useful to the application. See the the rest of Creating Interreality and other Interreality Project documentation for how this can be done.

A: Since VOS is still in development, and is a part-time hobby project for the developers, we haven't done any rigorous evaluation of VOS's performance yet. VOS is intended to be a flexible, extensible system, however, a consideration which sometimes requires comprimise in performance.

Particular attention to performance has been made in the implementation of the low-latency and tunable network protocol and parser (which underwent several revisions partially due to performance), and in managing distribution of messages to multi-threaded MetaObject message handlers. In implementing libvos, care has been made to select appropriate tools from the standard libraries. We have also found that many important aspects of libvos improved greatly from C++ implementation rather than an earlier Java implementation.

At a broader system design level, the VOS philosophy is to avoid imposing policy on the user that that might restrict your desired object structure. Instead, a VOS application may be optimized by utilizing appropriate MetaObject extensions if available, implementing caching policies, and by deciding whether to distribute objects on many sites, or to consolidate certain kinds objects on one site. For example, to address both network performance and the problem of NAT gateways and firewalls, MetaObject extensions have been devised that allows a more powerful server to host objects on behalf of clients, when they normally might host the objects themselves.

In addition, in an application like 3D virtual environments with A3DL and TerAngreal, we take a slightly less rigid view of how closely different user clients need to be synchronized than some other virtual environment projects, so the system doesn't demand a certain level of performance (e.g. <30ms or similar), and it allows that some clients may experience more latency than others. If a particular application requires a garauntee of service with a certain type of degredation when faced with adverse conditions, then it must use extensions to achieve its specific desired goal.

We assume that the future will bring us some increased network capability and computational power in client computers. For 3D virtual environments in particular, our current goal is to be able to support many smaller worlds interlinked by portals or hyperlinks, each containing an approximate maximum of about 200 participants or agents, with world geometry detail comparable to action video games of the Quake 2-3 variety (plus modern capabilites in client graphics such as lighting and surface materials that depend on the client computer's graphics rendering hardware more than network performance), with comfortable download and interractivity on a consumer broadband link (e.g. cable modem or DSL).

A: VOS offers a sophisticated and fine-grained access control system for user authentication and access control.

The VOS protocols are designed to prevent most kinds of known imposter and man-in-the-middle attacks. At the moment, encryption is not supported but this may be implemented by your application or by a VIP protocol extension in the future. (One solution is to use TLS/SSL.)

A: Both. While designed to be used as a peer-to-peer system, it is often not practical to do so and one or some sites act like servers, while others act like clients. Special tools for creating proxy objects have been created and continue to be developed, which allow a fully client-server system unaffected by restrictions imposed by firewalls and NAT gateways which require clients to only communicate with the server or servers.

One useful feature of the VOS system is it allows you to be flexible in server architecture, since the members of an interlinked structure of Vobjects may easily exist on any Internet host. Objects can be disributed accross many machines in one facility or anywhere on the Internet, but still form a single logical system presented to clients or user applications.

A: VOS is implemented using C++. We are currently working on creating bindings to the C++ libraries for various languages. Our priority is to first support Python, then Perl, followed by Java, then Ruby, Lua and others. This is an area in which help is needed. There is also a lightweight Java implementation of VOS using the older VOP protocol, which could be updated.

A: There are several ways to store the state of a Vobject structure: a binary format file (COD), a text XML file (XOD), "live" as a set of individual files and directories on the filesystem, or "live" in a mySQL database. The file import/export library is extensible.

A: The VOS source code package contains a number of example programs. The Interreality.org website contains a page linking to all VOS documentation, including this manual, Creating Interreality, which includes a chapter introducing VOS concepts and the library API. The website and source code package contains full API documentation as well. Finally, feel free to join the vos-d mailing list to ask any question or to generally talk about VOS.

A: The VOS networking infrastructure was developed to address the need for a flexible networking basis on which to build a multiuser virtual reality system. Along the way we noticed that VOS might be useful for quite a lot of other applications as well. The first chapter discusses this in detail.

The focus of virtual reality development with VOS is A3DL, which is a specification for how to describe 3D objects in VOS, and Ter'Angreal, the user agent, client, or "browser" for virtual environments.

A: VRML and X3D are simply file formats and do not specify a standard network protocol for sharing the objects online in a world. VOS provides this network layer and could be used for multiuser VRML (and indeed we are working with the author of OpenVRML to do this just this).

A: BetaVerse is a alternate VOS-based 3D client being developed by Jason Moyers independently of the official interreality.org 3D client, Ter'Angreal.

A: The 3D geometry schema, A3DL, and our "browser" client Ter'Angleal, both currently support polygonal meshes, a set of primitive shapes (spheroids, boxes, cylinders, cones), billboards (a bitmap image positioned in space but which always faces the viewer). Geometry may also be simply stored in a common model format such as 3DS or Quake MDL and MD2 (including simple animation). Objects may have a solid color, or be textured with a bitmap image. Light sources are point lights of any color and sphere of influence; some objects have static lightmaps calculated with advanced shading which other, more dynamic objects, are lit more simply and dynamically.

Future plans include "portals" which interconnect spaces; different kinds of light sources; supporting shader programs for materials and geometry; simple special effects like particle systems or fire and water; curved or locally subdivided surfaces; hierarchical animation; and more.

A: VOS has some general purpose file formats (binary or text/XML) for storing the state of Vobjects. You can also import from the ASE file format, and more in the future, including VRML. Vobjects can also be stored "live" in a MySQL database, or as a set of individual files and directories in a filesystem.

A: Yes! This is what VOS is all about. There are several ways to do this, including adding extra type tags to an object, or by simply attaching your own Vobjects into any part of the Vobject structure.

A: The truth is that when we first started working on VOS we weren't familiar with CORBA. However, my impression of CORBA now is that has a steep learning curve, is cumbersome to use and generally suffers from the usual problems of being designed by committee.

A: VOS uses a general purpose messaging protocol, which is not strictly tied to the notion of RPC. CORBA is quite firmly rooted in the server/stub model where skeletons are built based on interfaces specified using the Interface Design Language (IDL). With this black-box approach, it becomes quite difficult to embed special client side logic (such as a caching policy) or change the network interface without changing the application interface. The usual solution is to write wrapper classes, but this is often inelegant.

CORBA mainly addresses the fairly uninteresting problem of translating the arguments of a method call into a message and processing the reply. There little or no support for embedding logic as to what to DO with these messages so as to present a more intellegent interface to the application.

A: Most systems define objects strictly by their interfaces. The set of types on a vobject may be used to imply nearly anything about an object. In addition to method interfaces, a frequent use is how to interpret the object's postition in a vobject structure.

Other object systems like CORBA do not have any structural object interlinking information.

A: Yes, CORBA also has the weight of industry support behind it and has been in development by many programmers for many years.

We are currently working on creating bindings to the C++ libraries for various languages. Our priority is to first support Python, then Perl, followed by Java, then Ruby, PHP and others. This is an area in which help is needed. There is also a lightweight implementation of VOS in native Java using the older VOP protocol, which could be updated if a native Java implementation is required.

A: If necessary, VOS could be tunneled over any of these transports, or an adapter or bridge service could connect a VOS system to another existing system. However, because we have our own object model, message format, and network transport protocol, these standards wouldn't buy VOS itself anything. In fact, a single-stream based system like HTTP (and therefore XML-RPC, SOAP, etc.) actually can prevent a VOS system from performing acceptably in an interactive multi-client environment.

A: That depends on whether you want a high level vobject-oriented API (which the C++ libary implements) or just want to acomplish some very specific actions. A trivial client can be pretty stupid, if it knows in advance what messages to send and to expect, and doesn't need to support VOS server features. The VOS libraries are also seperated such that, if you want, you can simply use the VOS network transport protocol (VIP) library directly.

A: No. It also has nothing to do with the Veritas-Oracle-Sun initialtive, the Virginia Orthopaedic Society, the Vos family, or parrots.

A: No. The term MetaObject has many meanings in software and computer science, and the VOS MetaObject class is only vaguely related to some of them. VOS' Metaobjects have nothing to do with QMetaObjects in QT (except that perhaps you could write software that used them together in a clever way).

A: No. Part of Microsoft .NET, the Common Language Runtime (CLR) contains a subsystem called the "virtual object system" but this is entirely unrelated to our work. We regret the name collision but when the VOS was conceived (spring of 2001) the .NET technology was not yet established.

A: Actually the VOS design has nothing to do with Snow Crash. It is an inspiration (along with various other works of science fiction involving computers and VR), and we generally worship Neil Stephenson because he is such a great geek writer :-) We should also take a nod to Gibson's classic Neuromancer.

A: We'd also like to thank "Bob" for his early inspiration and Eris (HE,AHD,KTC) for her grace.