The first version of the WebOOGL/Geomview 3D browser started as a proof of concept for the WebOOGL proposal for the VRML draft specification in 1994. (The proposal finished second, behind the winning Open Inventor file format proposal). WebOOGL 2.0 is faster, more robust, and is a ``quasi-compliant'' VRML browser. The parts of the VRML specification that aren't implemented in Geomview (most notably texture mapping) are silently ignored.
The WebOOGL software system is built on top of Geomview, a free 3D viewer which runs on SGI, X, and NeXTStep workstations. In addition to interactive end-user control, it can be controlled through a command language and used as a display for other programs (known as external modules). WebOOGL is the name of both a software package (a family of these external modules) and a file format (an extension of the OOGL file format read by Geomview to include URLs). The WebOOGL module accepts both the VRML and WebOOGL file formats as input, and interprets mouse clicks on 3D objects with embedded URLs by either display information about the object or following the link. The information displayed is the URL if the object contains a hyperlink, and a title if it is a graphical representation of an HTML document. If the URL is another 3D object in VRML or WebOOGL format, it appears in the 3D browser when the link is followed. All other URLs are passed off to the 2D browser.
The original WebOOGL system demoed in 1994 had a very different structure than the current WebOOGL 2.0 configuration described here. The WebOOGL system currently works with the XWindows versions of the Mosaic and Netscape browsers, which have remote control capability. With Netscape we use the X remote control command-line options, and with XMosaic we use the old-style message passing with temporary files and signals. We have not yet implemented a CCI interface, we are waiting until widespread adoption by multiple browsers convinces us that it is a true standard.
The WebOOGL system is actually a family of programs as shown in the figure which communicate with each other through the Geomview command langugage (GCL). A description of the entire command language is beyond the scope of this paper, the important GCL commands used in the system are for loading geometry, starting up a new external module, transmitting a message to an already running external modules, and associating geometric data with a ``handle'' (similar to a variable).
The weboogl.perl script is the backbone of the system and its main switchboard. When it receives a requests for URLs, it sends a command to Geomview to start up a new copy of the gvgeturl script. When Geomview starts up an external module, it is forked as a child process, so the URL fetching happens asynchronously and does not interfere with the interactive response of the rest of the system. The gvgeturl perl script is linked with the libwww-perl library, which actually downloads the contents of the URL into a local temporary file. If the URL content type is VRML or WebOOGL, a filter program is invoked to convert the file into the OOGL format read by Geomview. In the case of VRML, first the vrml2oogl filter program converts the data into WebOOGL format. The vrml2oogl C++ program is built around the QvLib parser. WebOOGL files are handled by another converter, woogl2oogl, a relatively simple C program that transmits the geometric data to Geomview after dealing with the URL references. Below we use ``anchor'' and ``inline'' in the same sense as the VRML specification. Anchor URLs are stored in OOGL COMMENT objects in the form expected by the weboogl.perl script, which is the part of the system that determines the response to user mouse clicks. Inline URL references are converted into OOGL handles (similar to variables), and Geomview is told to transmit to weboogl.perl script a request to instantiate the URL as a handle. Although there are many incarnations of the scripts to get and process URLs, every URL request is funnelled through the single copy of weboogl.perl that keeps track of which URLs have been cached as local files. If the URL hasn't already been encountered, the process described in this paragraph begins again recursively.
Finally, the to-weboogl.perl script is an intermediary between the 2D Web browser and the rest of the system. It keeps track of whether to spawn a new 3D viewer or simply send a message to the currently running one.
Created: Apr 26 1996 --- Last modified: Thu Jul 11 11:23:14 1996