virtual reality transfer protocol (vrtp)

vrtp is being developed to provide client, server, multicast streaming & network-monitoring capabilities
in support of internetworked 3D graphics and large-scale virtual environments (LSVEs).


Status Software Charter Why Motivation What Components Details References

Status

This is a research working group in an early stage of development and experimentation. You have been warned!

Since 1995 we have actively collaborated with a number of researchers on the specifics of vrtp architectural design. Currently four Ph.D. students and several master's students are working on components expected to become part of vrtp.

We applied to become a Web 3D Consortium Working Group in January 1998, and our charter was approved in February 1998. We have established the vrtp mail list and hypermail archive at the www.web3D.org site.

Our primary motivation to open up participation in vrtp development is to execute vrtp implementation quickly and thoroughly. We want to to maximize the network abilities of shared 3D worlds. We will also want to keep pace with the subsequent explosion of network demand by large-scale interconnected 3D virtual environments.


Software

The following distributions are individually available. They are structured to be mutually compatible in the vrtp directory structure.

vrtp-related software
vrtp working group Web site
(this page)
Interim update page vrtp.zip, vrtp.tar.gz
DIS-Java-VRML Web site relative link (if installed locally) Interim update page Most recent download
Real-time Transport Protocol (RTP) Monitor Web site relative link (if installed locally) Interim update page Most recent downloads
rtpMonitor.zip, rtpMonitor.tar.gz
Dial a Behavior Protocol (DABP) Available soon
Recursive Ray Acoustics (RRA) Sonar Algorithm Web site relative link (if installed locally) No interim updates Most recent download

The Bamboo plugin architecture is not yet integrated in any way, but is our goal componentization architecture. Bamboo is available via the Bamboo web site.

Concurrent related work: Extensible 3D (X3D) Specification Task Group. It has delayed some of our efforts in vrtp, but promises even greater eventual impact. Both efforts are proceeding in parallel with excellent progress.


Charter

Our charter to start a virtual reality transfer protocol (vrtp) working group in the Web 3D Consortium has been approved. It remains available for comment. The VRML Review Board (VRB) had the following comments, which need to be integrated into our work plans.

Answering these important questions will first be addressed via vrtp mail list discussion.


Why vrtp?

The capabilities of the Virtual Reality Modeling Language (VRML) permit building large-scale virtual environments using the Internet and the World Wide Web. However the underlying network support provided by the hypertext transfer protocol (http) is insufficient for large-scale virtual environments. Additional capabilities for many-to-many peer-to-peer communications plus network monitoring need to be combined with the client-server capabilities of http. To accomplish this task, we present a detailed design rationale for the virtual reality transfer protocol (vrtp). vrtp is designed to support interlinked VRML worlds in the same manner as http was designed to support interlinked HTML pages. vrtp will be optimized in two ways: on individual desktops and across the Internet. vrtp appears to be a necessary next step in the deployment of all-encompassing interactive internetworked 3D worlds.


What does success look like?

vrtp will be public-domain software that will be available for all desktop computers. Installing vrtp will provide any machine with client, server, peer-to-peer and network monitoring capabilities. People will use vrtp with 3D browsers to navigate and join large, interactive, fully internetworked, VRML worlds. Because the scene graph paradigm is common across a number of Web-based 3D programming methodologies, vrtp interfaces will also be developed that are adaptable to other application programming interfaces (APIs) such as Java3D and VRML-NG.

Basically we are building network connectivity for cyberspace, optimized for live 3D and scalable with the Web.

Caveat surfer: many parts of this effort have a long way to go! There is a lot of heavy-duty detail and behind-the-scenes work going on. It is not a good project to join in order to do a little quick hacking (at least not yet). It is a good project to join if you are interested in contributing to a serious long-term effort that integrates 3D graphics with internetworking. You might take a look at the DIS-Java-VRML working group if you want to see how these efforts can grow.


Motivation

The following book chapter is an in-depth examination of the interrelated networking and 3D graphics forces which motivate this work.

     

Graphics Internetworking: Bottlenecks and Breakthroughs

Don Brutzman
Chapter four, Digital Illusions, Clark Dodsworth editor,
Addison-Wesley, Reading Massachusetts, August 1997.
www.stl.nps.navy.mil/~brutzman/vrml/breakthroughs.html
           
            Although networking is considered to be "different" than computer graphics, network considerations are integral to large-scale interactive three-dimensional (3D) graphics. Graphics and networks are now two interlocking halves of a greater whole: distributed virtual environments. New capabilities, new applications and new ideas abound in this rich intersection of critical technologies. Our ultimate goal is to use networked interactive 3D graphics to take full advantage of all computation, content and people resources available on the Internet.

Network breakthroughs repeatedly remove bottlenecks and provide new opportunities. A pattern appears as we attempt to scale up in capability and capacity without limit: every old bottleneck broken reveals another. Understanding the bottlenecks, the corresponding solutions and potential upper bounds to growth permits us to develop effective networked graphics. When we overcome current bottlenecks, "effectively networked graphics" will simply mean "applications."

Internetworked graphics can be examined from the perspectives of connectivity, content, interaction, economics, applications and personal impacts. Internetworking refers to the ability to seamlessly interconnect multiple dissimilar networks globally. Connectivity has numerous dimensions including capacity, bandwidth, protocols and the many-to-many capabilities of multicasting. Content equals the World Wide Web and includes any type of information, dataset or data stream that might be used in the graphics environment. Interaction implies minimal latency, a sense of presence, and the ability to both access and modify content. The economics of networked graphics environments is developing rapidly and principal forces can be identified. Applications drive infrastructure development and are the most exciting part of networked graphics. Finally, the personal impacts which accompany these developments range from trivial to profound as high-quality interactive internetworked computer graphics become the norm on all computers.

           


Where does vrtp live?

   
Just as the functionality of ftp, telnet and gopher were integrated in http to support HTML, we are integrating and optimizing protocols for client, server, peer-to-peer and network monitoring in vrtp to support VRML.

Combining and optimizing existing protocols is a well-understood challenge, not a leap of faith. It is also becoming clear that such functionality can be used for other 3D scene-graph APIs in addition to VRML.

   
diagram:  HTML needed http, now VRML needs vrtp
   

   
For a long time, many of our conversations with people about VE networking ended up in the same frustrating question: "are you discussing client-server OR peer-to-peer?

We now realize this is a false dichotomy. A full spectrum of functionality exists between client-server and peer-to-peer. vrtp must support this entire spectrum well.

   
diagram:  Spectrum of functionality between client and server
   


vrtp Components

We have done a lot of work implementing large-scale virtual environments over the network. Most people have huge laundry lists on what functionality is required for a scalable network architecture. The real challenge is squeezing down on all these issues and understanding the core requirements. The design rationale explains in detail why these key components are needed to support the full variety of network needs in virtual environments.

vrtp Components
Client looking at someone else's live 3D world diagram: vrtp components
Server showing other people your live 3D world
Peer-to-Peer for scalable behavior interactions
between numerous interacting worlds
Monitoring   so that everything just works. why? because  
  nobody really knows the state of the Internet  
Plugin Kernel Bamboo plugin architecture for
Java and C++ dynamic class loading


More details please...

Well, the best answer for technical details is an implementation, but we don't have one yet. Currently we are working on a variety of components. Initial implementation is planned for mid 1999. The design goal attributes for vrtp follow.

vrtp is: vrtp is not:
  • a framework for best-of-breed protocols
  • a combination of existing software
  • a way to give user scenes easy access
    to a full spectrum of network capabilities
  • support for multi-user and avatar interactions
  • vrtp:// URL & browser API extensions for
    client OR server OR multicast capability
  • easy to use (otherwise we're not done yet)
  • all about simplification & streamlining
  • possible using http
  • yet another transport protocol, or
    a reliable multicast protocol
  • a competitor to existing protocols
  • a multi-user or avatar specification
  • a step in an untested direction
  • hard for 3D-content authors to understand
  • about adding complexity


Here are a matched set of simple and detailed architecture diagrams which show how the various vrtp components fit together.

   
Primary paths for dataflow are mostly vertical, up & down the columns in the diagram.

3D client functionality is in the orange box for a variety of 3D scene graphs. Multicast streaming, server and monitoring components are in the yellow, green and blue box columns.

The light-blue "universal platform" box indicates that vrtp will be implemented in both Java and C++ (via Bamboo plugins), enabling interoperability with all platforms of interest.

   
(Larger diagrams can also be seen side by side.)
   
diagram:  bamboo vrtp components   diagram:  bamboo vrtp components


A major piece of work accomplished in 1998 was the design of the vrtp streaming behaviors component.

From the bottom up: behaviors arrive as multicast packets over the wire, are subscribed to via the Area of Interest Manager (AOIM), are buffered in a separate thread, have Real-time Transport Protocol headers examined for synchronization, packet contents are decoded using the XML-based dial-a-behavior protocol, then the entity dispatcher sends events to the 3D scene graph.

   
  simple diagram:  vrtp streaming behavior stack
   
detailed diagram:  vrtp streaming behavior stack
   

Prototype implementation of this functionality has been produced during implementation of the DIS-Java-VRML software distribution.


We intend to use Bamboo as the plugin architecture which will selectively load & dynamically connect vrtp components on the desktop at runtime.

   
bamboo
   
Bamboo is a collection of the core mechanisms common to networked VEs. It is an API toolkit for serious programmers. It has a dynamically extendible runtime environment. Bamboo is based on OpenGL++, which implies OpenGL, C++, and STL (standard template library). OpenGL++ is a multi-platform (SGI, PC, Macintosh, etc.) visualization toolkit that contains the best of Performer and Inventor. Bamboo sits along-side rather than on top of OpenGL++. Bamboo is designed based on plug-ins.

The Bamboo web site has additional detail, mailing list information and the latest set of distributions.

   


Annotated References


The Uniform Resource Locator (URL) for this home page is http://www.web3D.org/WorkingGroups/vrtp

Contact information: Don Brutzman (brutzman@nps.navy.mil)
(4 September 1999) (official NPS disclaimer)