@internet - VRML: Still Not Ready for Prime Time



Home Articles STARK REALITIES About This Site My PGP Public Key


After Hours Ordinary Hero A Season in Methven Our Host Send Me Mail


Home Articles STARK REALITIES About This Site My PGP Public Key


After Hours Ordinary Hero A Season in Methven Our Host Send Me Mail


Home Articles STARK REALITIES About This Site My PGP Public Key


After Hours Ordinary Hero A Season in Methven Our Host Send Me Mail


Home Articles STARK REALITIES About This Site My PGP Public Key


After Hours Ordinary Hero A Season in Methven Our Host Send Me Mail


Home Articles STARK REALITIES About This Site My PGP Public Key


After Hours Ordinary Hero A Season in Methven Our Host Send Me Mail


Home Articles STARK REALITIES About This Site My PGP Public Key


After Hours Ordinary Hero A Season in Methven Our Host Send Me Mail


Home Articles STARK REALITIES About This Site My PGP Public Key


After Hours Ordinary Hero A Season in Methven Our Host Send Me Mail


Home Articles STARK REALITIES About This Site My PGP Public Key


After Hours Ordinary Hero A Season in Methven Our Host Send Me Mail



There was a time when I was enthusiastic about the potential of 3-D to revolutionize both the user interface to and the content of the Internet. Some two-and-a-half years ago (in another magazine), I wrote a column entitled: "Is Virtual Reality the Future of the Web?" Sadly, it's pretty clear that the answer is: "No, not yet--and perhaps not ever."

In part, that's because Virtual Reality Modeling Language (VRML) browsers are still ridiculously difficult to actually use. In part, it's a performance issue and in part it's because effective bandwidth on the Internet is still so constrained.

Mostly, though, it's because VRML is still a solution in search of a problem.

I'd Love to Change the World

In a very real sense, VRML grew out of a discussion on virtual reality interfaces to the Web, which was held during a Birds of a Feather session at the first World Wide Web Conference in Geneva, Switzerland in the spring of 1994. That discussion was sparked by "Cyberspace", a Web Conference presentation co-authored by Mark Pesce, Anthony Parisi and Peter Kennard--all then of the Labyrinth Group--and actually presented by Pesce.

In it, the authors put forth a proposal to implement the vision of novelists like William Gibson (author of Neuromancer and other science fiction works and coiner of the term "cyberspace") and Neal Stephenson (author of Snow Crash and The Diamond Age) for a three-dimensional data space to be superimposed on the Internet's IP address space and shared as what Pesce, et al, called a "collective hallucination."

Visionary as it was, that proposal bore no relationship to what virtual reality on the Internet evolved into over the next few years. Pesce and his fellow dreamers had envisioned a universal addressing scheme--a reinvention of the familiar URL--where every object in cyberspace would be represented by a 32-bit number that specified its "location" (independent of its IP address). What they got, instead, was an extended discussion with like-minded Internauts that eventually turned into the VRML language.

In May of 1995, Gavin Bell of Silicon Graphics, Parisi and Pesce co-authored the VRML 1.0 specification. The initial spec, which had been gestating in draft form since November of the previous year, was based on a subset of SGI's proprietary Open Inventor file format and incorporated many of its conventions directly into the .WRL file format.

The Inventor format consisted of ASCII text--an important lowest common denominator consideration--and already included most of what the nascent VRML community agreed a usable spec had to support: an object basis, a method for describing the properties of a collection of objects (both Inventor and VRML call this a "scene graph"), a hierarchy of object types (known as "nodes" in both languages), the idea of points of view (Inventor and VRML 1.0 called them "cameras") and different kinds of lighting (directional, pointsource and spotlighting) to display shadows and highlights. It also included a lot of other functions--far too many for a successful VRML language--which would have to be fairly compact in order to succeed in the low-bandwidth user environment of the rapidly-expanding Internet.

The shortcomings of the original spec became obvious within months of its adoption. In January 1996, an interim set of "clarifications" was issued to address the points of greatest confusion and/or unwieldiness. The major problem was that the spec was simply missing too much functionality--it was, in a word, still primitive.

We Can Work It Out

Various proposals to flesh out the 1.0 spec with a 1.1 interim release came to nothing, and on January 4, 1996, a Request for Proposals for VRML 2.0 was issued by the VRML Architecture Group (VAG), the eminences grise of the VRML community. It didn't allow much of a window for development, since the deadline for response was February 2--less than a month later.

The six respondents and their proposals were:

  1. Active VRML - Microsoft
  2. Dynamic Worlds - German National Research Center for IT
  3. HoloWeb - Sun
  4. Moving Worlds - Silicon Graphics
  5. Out of this World - Apple
  6. Reactive Virtual Environment - IBM Japan
From February 23 to March 18, 1996, the VAG conducted an online poll of the VRML community's reaction to the six proposals. One hundred and ninety one people responded with votes on one or more of the candidates. In the end, the SGI Moving Worlds' submission was the favorite by a significant margin--not a terribly surprising outcome, in view of the genesis of VRML 1.0.

With help from both Sony Corporation and from Mitra (a major presence in the VRML community who, like Cher, Madonna or Sting, chooses to affect a single name), the original Moving Worlds spec continued to evolve through three drafts. The third and final one was largely the work of Gavin Bell and Chris Marrin of SGI and of Rikk Carey. The final VRML 2.0 specification was released on August 4, 1996, at Siggraph 96 in New Orleans.

Version 2.0 added enhancements such as backdrops, fog, irregular terrain and sound to static VRML worlds. It also simplified the scene graph structure from the clunky and convoluted mechanism described in VRML 1.0.

Another step forward in VRML 2.0 was interactivity. To the 1.0 spec's 36 nodes (including nodes that describe shape, properties group characteristics, viewpoints, lighting and hyperlinks), 2.0 added terrain following (allowing viewers to "climb" steps or ramps, for instance), collision detection (eliminating the annoying tendency to walk through walls) and seven kinds of sensors. Sensors either trigger events as a consequence of user actions or track the passage of time, allowing clock-driven events.

Version 2.0 also added animation (via a set of objects known as "interpolators") and scripting (yet another new type of node), which is how input from sensors triggers events (such as animation) to the bag of tricks available to VRML authors. In a bow to the general consensus that VRML needed to be easily extensible without requiring the language itself to be further revised, provision was made to allow authors to create what are called "prototypes."

Prototypes are encapsulated groups of nodes that are treated as a unit. They may have defined variable fields (such as color, length, etc.) that allow a single prototype to be reused in multiple iterations, distinguished only by different values in their shared variable fields. In other words, by declaring an airplane prototype, a VRML 2.0 author can incorporate a fleet of airplanes of different colors into a world simply by defining multiple airplane nodes. Since all of the airplanes in the fleet are defined by the prototype, only the fact that each is an airplane node and the variable field value that determines its color need to be defined for each individual airplane iteration.

R-E-S-P-E-C-T

All this new functionality was badly needed and enthusiastically welcomed. However, one of the major problems with VRML was its status as a moving target. That issue was addressed on April 4, 1997, when a revised version of the VRML 2.0 spec was submitted to the International Standards Organization (ISO) as VRML 97 Draft International Standard (DIS) 14772. The VRML 97 DIS document included a few (mostly minor) technical revisions and a substantial number of editorial changes, which make it considerably clearer and more readable.

Since ISO rules forbid any changes to a DIS under consideration for adoption by its members as an International Standard, any further tinkering with the core standard came to a screeching halt. ISO and the International Electrotechnical Commission (IEC) solicited comments on the DIS for more than seven months before publishing it in December 1997. On January 26, 1998, in a joint press release, the VRML Consortium, the ISO and the IEC announced the acceptance of ISO/IEC 14772 to the world.

That gave VRML 97 the formal blessing of the international standards community, and it helped provide the leverage for the VRML Consortium--which was founded in December 1996--to persuade Sun Microsystems it was time to come on board as a voting member. Sun did so on February 18, 1998, during the VRML 98 Symposium. That was important, because the Consortium desperately needed to reach an accommodation between VRML and Sun's emerging Java 3D API. At the Symposium, Sun and the Consortium announced, in a joint press release, that the follow-on utility library for the forthcoming Java 3D API V1.0 Sample Implementation would include a VRML 97 browser tool and geometry loader.

A Town Without Pity

Unfortunately, all the standardization in the world hasn't solved the technical problems of slow, hard-to-use VRML browsers. The addition of textures, sound and animation to the VRML palette has resulted in a general increase, rather than a decrease, in the bandwidth it takes to browse even moderately complex VRML worlds. And the fundamental problem is still that of application.

Or, as an SGI technology evangelist privately expressed it to me, "Name one real problem that VRML solves."

It's not that there aren't any.

Instead, it's that there aren't nearly enough such problems to make VRML more than a curiosity for the foreseeable future.

In fact, a lot of the pioneer VRML sites are out of business. Virtual SOMA, a VRML 1.0 recreation of San Francisco's Multimedia Gulch is gone. The VRML from Hell page is Not Found. Macmillan Publishing's VRML Foundry is missing, and The Community Company's web site hasn't been updated since May 1996. In fact, there are an awful lot of broken links in the various collections of VRML site URLs around the Web. For instance, all of the links I cited in my September 1995 column on the subject return 404 errors now.

To be fair, there are still plenty of new and regularly updated VRML sites around, and there are a lot of cool tools available, too. If you're interested, start at the San Diego Supercomputer Center's VRML Repository. It includes links to browsers, authoring applications and software development resources, documentation and object, sound and texture libraries, as well as links to other VRML-oriented sites.

One such site is WebEarth, which maps a set of satellite weather maps onto a VRML globe to display a world-wide weather map that's updated every 60 minutes. (This, by the way, is a pretty good answer to that "Name one real problem that VRML solves" challenge.) You'll need a VRML 2.0 browser or browser plug-in to view it.

If that gets you excited, you'll probably also want to subscribe to www.comp.lang.vrml and its less formal twin, alt.lang.vrml, get on a VRML mailing list or two, and perhaps even consider joining one of the 19 VRML Working Groups.

Meanwhile, you might devote some time and energy to considering the question of just what it would take to make VRML, in particular, and 3-D, in general, so compelling that everyone and their little sister flocks to it like swallows flock to San Juan Capistrano in the spring. I haven't been able to come up with anything, and I've been thinking about it on and off ever since SGI rolled out their WebSpace viewer in 1995.

The Song Remains the Same

One thing seems safe to say: William Gibson's original vision of cyberspace won't be coming to an Internet near you any time in the near future. There are many reasons why that's so, but the one that's easiest to grasp is that what works extremely well as a novelistic device for writers such as Gibson and Stephenson, doesn't necessarily work the same way in the real world--or in the virtual one, for that matter. That's a big reason why cybermalls, as a marketing model, have completely failed to take off and that's also a major reason why VRML hasn't worked very well as a user interface.

In order to go shopping in the real world, for instance, we're forced to travel from one physical locale to another. That's why real-world malls are so successful, because they collect a bunch of otherwise-unrelated stores in a single physical location. A given mall may not include every one of the exact stores we'd prefer, but, if it offers enough of them, we'll gladly accept substitutes for our other selections in exchange for the convenience.

On the Internet, by contrast, we have no need of such a concentration of otherwise-unrelated entities at a single address. That's because distance, per se, is basically meaningless on the Net, and because search engines and other directories are a much more useful and flexible means of accessing disparate businesses than is massing them in a single virtual "location". Virtual malls are, thus, a solution in search of a problem.

The same thing is true of VRML. Since every "location" on the Web is, for all practical purposes, right next door to every other location on the Web, the need for a virtual Main Street simply doesn't exist. That metaphor, which works so beautifully in Neuromancer and Snow Crash, just doesn't apply to the Web or the rest of the Internet.

That's the main reason why VRML still isn't ready for prime time.

And why it may never be.

(Copyright© 1998 by Thom Stark--all rights reserved)