Once again, I find myself addressing you while wearing both of my hats; as
moderator of this list, and as a businessman engaged in developing
commercial VRML tools. I will be addressing the issue central to this list;
the adoption of a basic VRML specification, something we have been moving
toward for almost three months.
Brian and I established this list hoping to mine the intellectual resources
of the Internet community. Our goal, rather than to reinvent the wheel, was to
"kick the tires" of preexisting solutions to determine their fitness as
possible VRML specifications.
Before we began this search formally, I was told time and again that
Open Inventor, from Silicon Graphics, did *most* of what we needed, and
individuals compared our home-brewed Labyrinth VRML specification to it
repeatedly. As soon as we opened the list, subscribers began to suggest OI
as a basis for VRML.
All of this piqued my interest; although I resolved to remain neutral until
I could carefully weigh all the alternatives, I began an examination of OI,
and asked people who have a considerable background in graphics and/or
languages, parsers and compilers to evaluate OI, then report their findings.
The results came back *uniformly* positive; now that OI has "won" the
survey, I feel it is appropriate that we recommend, by acclamation, that OI
become the basic specification upon which VRML will be constructed.
I will present a number of compelling reasons why I feel strongly about
this; these arguments are divided into three categories: OI's "fitness", or
technical suitability; the commercial requirements for VRML; and a
discussion of an offer from SGI to "sweeten the pie" with source code and
other goodies.
*****
1) Open Inventor *is* a suitable VRML candidate
After an intensive review process by many of the VRML subscribers, the
general consensus appears to be that OI could serve quite adequately for
VRML's syntax and extensibility requirements. I feel that we should adopt an
existing solution, rather than creating one, because, no matter how
well-intentioned, it will take months to years to develop anything that
might hope to provide the same level of functionality as we get by using OI.
Reinventing wheels is both a pointless task and an exercise in
self-gratification; it is unclear that anyone's needs but our own would be
served by the creation of "yet another standard".
OI is already defined and developed. It has been through *two* major
iterations and perhaps 15 man-years of design work. This means that it has
encountered and solved problems that many of the other candidates haven't
yet addressed, solutions our own efforts would be hard-pressed to reproduce
in the next year or five, and foremost among these is the "problem" of
behaviors.
Behaviors have been discussed ad nauseum on the list and at our SIGGRAPH
meeting. They are important, but we have elected to defer their
implementation until a later date. This is dangerous, as a misdesigned
language might require a complete redesign to accommodate behaviors.
Not so with OI; we have the luxury of adopting those portions which would
go furthest to meeting our requirements, implementing the more comprehensive
features as our needs expand and our abilities increase. The behavior
mechanism and syntax in OI is *ready, tested, debugged and evolved*. The
blind alleys have already been traversed.
OI is *not* perfect. The folks from SGI are the first to admit this.
(What about sound? Keyframe animation? There's more, too.) But it's not
starting from ground zero; more like launching a cruise missle from 5 miles in
the air; saves you lots of fuel, but you still need to get the job done
yourself.
If we decide to use OI, we are freed from a series of bootless arguments and
flames about syntax. We can proceed directly to the "meat" of the matter;
what OI "nodes" do we add to accommodate the feature set as suggested by the
survey results? This is, I believe, a much more fruitful use of our time,
energy, and bandwidth.
There is plenty of work to be done, even with the adoption of a formal
syntax; anchors must be defined, level-of-detail constructs worked out
(although some of these already exist in OI), and we must make sure that the
major issues represented by the survey results are incorporated into a
baseline specification.
Nevertheless, we don't have much time at all. We will be presenting a
specification document at WWWF '94, just *six weeks* from now. We can have
a specification done by then, we can present it to the community; but if we
argue on whether to use BEGIN or {, it'll be the millennium before we get a
specification written.
*******
2) Commercial arguments for using OI
It should be a goal of this list to create an ecology of VRML development, and,
like any complex environment, it should have many strata. We are currently a
community of enthusiasts and technologists; to grow beyond those bounds
requires that we move into a mode which accepts that commerce is necessary
for VRML to succeed in the long term.
If we see ourselves in the center of a process, the first people we should
hope to "infect" with our ideas will have to be the hackers (good hackers,
that is), the educators, and the artists. Each of these groups will push
the envelope, technically, with content, or in unexpected creation; this has
been the focus of our efforts at Labyrinth Group. Compelling content and
interesting development will convince the Web community of the efficacy of
VRML, and we're seeding the ground in the hopes of reaping a harvest of
interesting projects.
Beyond this lies the Web community at large, who are used to all of the
current drawbacks of the Web and its immature tools. Soon, though,
commercial offerings will "raise the bar" on Web-based tools *and* content.
This is how the Web will be known to the bulk of Internet users who
still do not use it, or use it very little. We should hope that VRML
follows in the footsteps of HTML, from prototyping to rapid adoption into
commercial acceptance. It means that we have done our job well, and would
be something to be proud of, rather than fear. The commercial market is a
market which favors evolution and ecology; if we dive right into that,
rather than sealing ourselves off from it, VRML will grow robust quite
rapidly.
Finally, we must expect that that business community itself has a lot to
gain from Web-based visualization (shopping malls? visualized stock quotes?
the applications are endless), and business will **not** build a market
on public domain software or "hobbyist" standards. The credibility that
VRML would gain, if we adopt OI, is unbelievably immense. SGI is the
900-pound gorilla of computer graphics; this does not mean that we should
kowtow to its whims, but it does mean that a substantial aftermarket
infrastructure *already* exists to support the development of our nascent
creations.
Open Inventor is already supported, with a variety of tools, on its own
platform, as well as Windows NT and SunOS. Companies like Collosal Pictures
or Universal Studios would be able to leverage existing infrastructure to
create content; furthermore, VRML would not seems *alien* to them, and they
would be very likely to adopt it quickly.
A commercially accepted standard makes sense, technically AND economically.
*********
3) So what does SGI hope to gain? Why should we do this for them?
Now it's time to make an announcement - the list moderators (Brian and
myself) have been to SGI, to visit with the OI group. They wanted to see us
after the first mentions (by Gavin Bell at SGI) that there was some interest
in their group to help in the VRML standards effort. They wanted to talk to
us, to understand where we were in our process, what our goals were, how we
could work together to meet them. I think they're a great crew, and they do
believe that they've created something wonderful, something that they want
to see grow and spread. They clearly see that an OI-based VRML would be an
enormous win for OI, for SGI, and for the VRML community, and tried to
impress that fact upon us.
I, for one, was impressed.
I returned to SGI, a few weeks later, without Brian, to talk with the folks
down in Mountain View some more. By this time, I had made my decision; I
knew that I wanted OI to become the basis of VRML. In return for this, I
felt that the VRML community could ask for a quid pro quo. Because I feel
that our first obligation is to create a tools ecology, I asked them to
contribute a parser for OI/VRML (source code, VRML -> C++) into the public
domain, so that *everyone* could begin writing VRML-compliant tools without
having to write an OI parser. (This avoids multiple reinventions of a wheel
which SGI knows quite well.)
They have agreed to do this. By 17 October (WWWF '94), SGI will be ready to
release source to an OI-based VRML parser to the Web community. This means
that browsers, translators, and scripts are much *easier* to write, and will
probably appear from many different directions at once.
While it may seem that SGI is giving "something for nothing", remember that
the widespread acceptance of tools that use OI will only increase the market
demand for the machines natively designed to run OI, that is, SGI
workstations. SGI is a hardware company, and this will increase the demand
for SGI hardware, if it's anywhere near successful. If it's wildly
successful (which is not outside the realm of possibility), then SGI really
wins, establishing another standard which might someday rival GL in its
popularity.
***********
Final thoughts:
OI and VRML will not be quite the same thing, unless OI extends itself, by
definition, to include the new nodes which we must add to give it VRML
functionality. But today's SGI- and NT-based OI scene construction tools could
be used to create VRML documents, *without* modification. This is a powerful
argument, to the rest of the Web community, that we mean business. By the
time of the fall Web conference, it is possible that our editors and tools
will have evolved *beyond* the sophistication of HTML's editors and tools,
because we were smart enough to leverage an existing infrastructure of
standards and tools to jump start our own work.
Time is of the essence; I have committed to presenting a VRML specification
on 18 October 1994, in Chicago, at WWWF '94. I would like it to be as close
to complete as possible, so that we can get this necessary feedback from the
Web community at large, and begin the process of evolution within the
ecology of the greater Web environment.
We have a fantastic opportunity here, and a great offer from an outstanding
group of people at SGI. My advice is that we quickly move to adopt OI as
the basis for VRML, and begin the *real* work of implementing the tools and
technologies to concretize our visions.
Thanks.
Mark Pesce
VRML List Moderator
President
Labyrinth Group