VRML 2.0:
For Living, Breathing, Moving Worlds
by Mark Pesce
Almost 18 months have passed since the Virtual Reality Modeling Language (VRML) was introduced at the Second International World Wide Web Conference. Since that time, we've seen an explosive growth in the number of organizations that have adopted the technology, including Netscape, Microsoft, Sun, and Silicon Graphics.
VRML is now considered a core Web technology, along the lines of HTML or Java--but even as developers rush to create browsers and authoring tools, a new generation of VRML is in preparation, designed to address the shortcomings of the initial version.
During the initial design phase of VRML, which took place during the summer of 1994, the VRML community confronted a number of design tradeoffs. The most important of these concerned the question of interactivity. While it was possible to create interactive virtual worlds using Open Inventor, the ancestor of VRML, these worlds weren't cross-platform-compatible--that is, a world created on an SGI machine wouldn't run on a SparcStation. And nothing ran on Macs or PCs. This was a show-stopper; either we had to invent a new programming language and put it on every platform, or we had to settle on a VRML that wasn't interactive. In the end we looked to the Web--which wasn't interactive--and figured that if static pages were effective, static worlds would be too.
But there was a small flaw in our logic: We don't expect books to be interactive, but we do expect to interact with our world. This became the biggest complaint about VRML, and one we couldn't begin to address. Of course, that was before Java.
If any two technologies seemed destined for each other, they'd have to be VRML and Java. From the moment that the communities met at the Third International WWW Conference, discussions began on the feasibility of a combination of the two technologies, a combination that would provided 3D capabilities for Java and interactive capabilities for VRML.
Over the summer of 1995, the VRML Architecture Group (VAG) began to draft a set of specifications for a new generation of the language, with new syntax to support integration with Java. While the VAG abandoned its engineering efforts, preferring to trust the collective intelligence of an open marketplace, its work greatly influenced researchers at Silicon Graphics and Worlds Inc. It led directly to a VRML 2.0 proposal now known as "Moving Worlds."
VRML 1.1
The VAG, working in concert with the VRML community, drafted a set of simple extensions to VRML 1.0 intended to cover a range of functionality absent from the original specification. These extensions were originally known as VRML 1.1, and were supposed to have been released in November 1995; the rapid development of the VRML 2.0 specification led to the abandonment of version 1.1. These extensions are now a part of VRML 2.0. Among the proposed extensions are support for sound, enhancements to geometry, multi-lingual text, and environmental settings.
VRML 1.0 worlds are deathly silent; that's because there's no support for sound, or any synchronization of sound with external events. VAG member Dr. William Martens (one of the pioneers in three-dimensional, or "spatialized" audio) defined two nodes, DirectedSound and PointSound, that act as "emitters" of sound in the VRML environment and are analogous to SpotLight, and PointLight.
It's possible to define "ambient" or continuous sounds, sounds that begin at a certain distance from the emitter, and sounds that increase in volume as the camera approaches them. These sounds are fully spatialized; that is, they have different timbre characteristics based on their position relative to the camera.
It is expected that browsers will provide built-in support for spatialized audio. (As of this writing, both Intel and CreativeLabs have developed libraries to support the development of applications using spatialized audio.) Unless sounds are continuous--defining a cyberspace equivalent of "elevator music"--they must be turned on and off by a VRML 2.0 Script node, which will be explained in a moment.
A broad set of basic geometric forms have been defined or refined. To facilitate the creation of complex landscapes, the TerrainGrid node was added. Its syntax provides an efficient way to define a ground plane that can accurately reflect a real-world environment. The GeneralCylinder node provides a powerful way to define extruded objects, or create parametrically defined curved surfaces often associated with high-end CAD programs.
Originally, VRML was entirely ASCII-oriented, restricted to 127 symbols and control characters. It soon became clear that this was unacceptable, particularly for users of non-Roman scripts such as Japanese and Chinese. Each of these languages uses thousands of different characters, encoded as multi-byte or Unicode values. For this reason, VRML 2.0 will shift from ASCII encoding to UTF-8; most operating systems already include support for UTF-8. The AsciiText node will be removed from VRML 2.0, to be replaced with the more flexible Text node; the new node includes parameters for text direction and language encoding. As a result, the string #VRML V2.0 utf8 will become the new VRML 2.0 file header.
In response to user requests for richer worlds, support for so- called environmental nodes has been added. These include the Background node, which applies a texture map against the horizon of the world, together with default ground-plane coloring. This makes it possible to create a world where ground and sky meet in a realistic-looking transition. Support for default or background lighting and light attenuation due to atmospheric conditions can now be simulated using the Fog node.
One of the trouble spots in VRML 1.0 concerned the browser's handling of avatars (virtual selves). Some browsers assumed a uniform avatar size and speed, while others varied it by calculating the size and scale of the world. This led to very different user experiences from browser to browser. The NavigationInfo node defines this information in a a nonambiguous way, so that the world's creator can be assured of a consistent user experience.
VRML 2.0
VRML 2.0 is all about interactivity--that is, how objects in VRML worlds can affect and be affected by other objects or external applications. In order to understand how it works, it's important to understand the event model for VRML 2.0. Events are actions that can be performed upon a node in a VRML world, or can be generated by a node in that world. For example, it's possible to change the position of an object in a world by sending a set_translation event to the Translation node associated with that object. Conversely, certain nodes (in particular, sensors and Script nodes) can generate events when certain conditions are fulfilled.
One way to think about the VRML 2.0 event model is as a series of components that get wired together to create a virtual machine. Each of the components are in their own "black box"; it's not necessary to know what's going on inside each box, but each one presents a set of interfaces--points where they can be wired into other boxes. The components themselves are either built-in (these are predefined VRML nodes) or can be defined by the world's author, using the new PROTO node.
The PROTO node touches at the heart of Moving Worlds' features. Using the node, it's possible to define new nodes with defined interfaces (wiring points, according to our metaphor). These interfaces can be connected together using a ROUTE. A ROUTE is a field (fields are values contained within a node) that "wires" interfaces--that is, logically connects them to each other. The interfaces come in two varieties: eventIn and eventOut. As with the logic of electronic circuits, you can only wire outputs to inputs.
What kinds of nodes generate events? In general, the sensor nodes and SCRIPT node are the two most likely candidates. Sensors are triggers that fire off a message in response to some activity. TimeSensor acts like a ticking clock, firing off events at regular intervals, or as an alarm clock, ringing at a specific point in time. BoxProximitySensor acts like the sensor in front of an automatic door: when you enter the sensor's region (defined by a box), it sends a message from isActive, defined as the node's eventOut interface. If the sensor has been wired to an eventIn of another node, that node receives the message. SphereProximitySensor works like its counterpart, but the region defined is spherical. ClickSensor and DragSensor translate user-initiated mouse events into events that can effect the environment; for example, a ClickSensor could be used as a light switch and a DragSensor as a dimmer control.
To create very complex behaviors--such as a networked, multi-participant environment, or a simulation that might model a complex mathematical process--it's necessary to create an interface between the closed world of VRML and the world at large. The SCRIPT node has been defined to provide an interface between VRML and any programming language. As is common with Moving Worlds nodes, the SCRIPT node defines a set of eventIn and eventOut interfaces; beyond this, it provides all of the definition information to bind to an external program or script. Thus a script can send messages to nodes inside a VRML world and can receive messages from them. While Moving Worlds has been designed to work well with Java, the language's designers have taken great care to ensure that it remains open to other languages, such as C++, Perl, Tcl, Visual Basic, OLE, etc.
To facilitate the development of scripts and interfaces to VRML worlds, an Application Program Interface (API) has been defined for the VRML browser; it defines a standard interface between the browser and external scripts--so the syntax and implementation of VRML scripting have been standardized under Moving Worlds, creating a consistent environment for the exploration of interactive virtual worlds.
VRML 2.0 will be in widespread release by midsummer, and you can expect that the two browser heavies, Netscape and Microsoft, will incorporate it into their browsers. No more configuration headaches with helper apps and inconsistent behavior; it'll be as well defined and ubiquitous as HTML. As we exit the specification process, the time for tool-building begins; by this fall (and mostly likely by SIGGRAPH), expect some incredible world-authoring tools. We're opening a porthole into cyberspace--but instead of black silence, we're greeted by a rush of newborn stars.
Reprinted from Web Developer® magazine, Vol. 2 No. 2 May/June 1996 (c) 1996 internet.com Corporation. All rights reserved.
Web Developer® Site Feedback
Web Developer®
Copyright © 2000 internet.com Corporation. All rights reserved.
Database Journal: The Knowledge Center for Database Professionals
