Jim Purtilo, PI, Univ. of Maryland David Stotts, PI, Univ. of North Carolina at Chapel Hill Project supported by contracts with the Office of Naval Research
We seek principles and guidelines by which VE designers can create virtual systems that will interoperate. New VEs will be built from existing one by combination and interconnection rather than with a preponderance of new coding, as is currently done. We will embody the understanding we gain in a VE development support system.
Our methods include de-engineering and interconnecting the VE systems developed over the past 7 years in the graphics labs at the Univ. of North Carolina at Chapel Hill Computer Science Department .
Interconnection of VE processes is via the Polylith Toolbus, produced by Jim Purtilo at the Univ. of Maryland Computer Science Department . Polylith serves as a general message bus for process communication.
The building walkthrough we are currently using was written by Fred Brooks' graphics group at UNC, and is called xfront in the literature. This VE uses dual joysticks to interact with a 3D model, and renders the visible scene on a single graphics screen.
In the original xfront a single user can move through a 3D architectural model in all directions (i.e., the viewer is not constrained to a simulation of ``walking'' with gravity). In our prototypes, to facilitate interaction of viewers, we have limited z-direction movement to keep all participants ``on the floor''. The multi-user versions draw a representation of other viewers, centered on their eyepoints, and indicate locations as well as directions of their views.
The interoperating processes functions with little alteration over the original application. We naturally have added a code module to communicate with the bus, and we have added an object (``other viewer'') that was not present in the original xfront, but in general alterations are minimal. Position location and transformation matrices are sent as messages over the Polylith Toolbus from one process to the other.
Our current prototypes use the Pixel Planes 5 system at UNC for rendering the scenes. Each copy of xfront runs on a Sparc 5 front-end to Pixel Planes, and the Sparc processes communicate with the bus components (also running on each Sparc). The three processors (Pixel Planes is actually 64 processors) are connected via local Ethernet. In our early work, no special attention has been paid to synchronization, and the latency between the two views of a scene that we are experiencing over the local net is acceptably small -- approximately 175 milliseconds.
Comments and questions to David Stotts, stotts@cs.unc.edu Last update 2/28/95