When - Monday 25 July 1994, 8:30 - 10:15 PM
Sheraton World Hotel, Orlando, FL
Presiding - Mark D. Pesce, VRML List Moderator
In attendance: 17 people from the WWW/VR/Visualization communities
Gavin Bell, SGI
Tamara Munsen, U of M, Geometry Center
Chris Goad, Besoft
Don Brutzman, Naval Research Center
D. Owen Rowley, Autodesk
Stephen Shapero, Husky Labs
Peter Kennard, Entek Design
Nick Williams,
Paolo Sabella, NetPower
(I apologize for those of you who attended by whose names
I do not remember...)
Agenda:
Introductions
VRML History - Status
Philosophical Issues in VRML
Appropriate base language(s) for VRML
VRML 1.0 ABSOLUTE Requirements
_________________________________
Introductions:
We went around the room (quite a bit into the meeting actually) and
introduced ourselves. Most everyone in the room is quite active on the
list, and there was a good cross-section of both highly technical people
(likely to write a VRML browser) and VRML end-users/artists.
VRML History - Status
Mark Pesce brought the group up to date on the history of VRML, how it began
as an outgrowth of WWW '94, but soon mushroomed in popularity beyond
anything anyone had expected; we now have over 1200 subscribers to both the
regular list and the digest version of the same.
Mark also outlined the fact that he and Brian, as list moderators, have been
carefully managing the list, right out in the open, without being secretive,
they'd been doing their utmost to keep the list tightly focused on achieving
results quickly, and that attitude necessitated the philosophy of "carry a big
stick and use it a lot." So far, the list members seem to appreciate that
we don't have 50 messages/day anymore, and seem to like the focused nature
of the discussion on the list. Mark discussed how he and Brian really
wanted to see if they could use a mailing list to leverage all the knowledge
and experience of the list contributors to produce a specification which
took advantage of the thousands of years of experience of the subscriber
base; so far this appears to have been successful. The first part of that
work, the generation of a list of candidates for a VRML base language, has
been extremely successful, with at least 8 contenders for the role, from
sources all around the world and throughout the industry.
Mark then discussed the future of the list; VRML will soon be codified into
a specification - then it will be up to the VRML community to develop tools
which could turn this specification into something palpable. The goal of
the list moderators is to have a basic specification by 1 September 1994;
this will allow us to present the work of the list at WWWF '94, in Chicago,
to the entire Web community. Labyrinth Group, Mark Pesce's company, has
committed to releasing a public-domain VRML browser to the Web community at
that event; others will also be ready to introduce VRML-based tools; all we
need to do is complete the 1.0 specification process.
Mark pointed out that he and Brian actually refer to this first pass as VRML
0.1, because we expect that the specification will evolve quite a bit at the
beginning, into a real 1.0 specification.
Appropriate base Languages for VRML
There was a brief discussion of the candidate "base languages" for VRML.
Gavin Bell from SGI talked about Open Inventor briefly, Tamara Monsen talked
about OOGL, and Owen Rowley talked about CDF/CDK. No one was familiar
enough with any of the other candidates to offer any commentary on them.
Philosophical Issues in VRML
The discussion then moved on to "higher" philosophical ground; which, as
list members are well aware, is the discussion of what actually goes into a
VRML 1.0 definition, specifically whether behaviors are included. This, as
list members are aware, is a BIG subject, one which we didn't think we'd
solve then in there, but we all believed was a fit subject for discussion.
At one point, someone suggested that we should draw up a list of the
"baseline" features which are MUSTS for VRML 1.0, rather similar to the poll
which is currently available at the VRML forum.
VRML 1.0 ABSOLUTE Requirements
The group then developed a list of requirements which where considered
absolutely essential for a VRML 1.0 candidate:
ASCII Format -
It was agreed that VRML had to be human-readable, even if that was only in
the most concise form, like OOGL, rather than OI's rather expressive form.
It was also acknowledged that most compression algorithms do a fine job at
squeezing the extra bits out of ASCII, so while brevity was important, it
wasn't essential.
It was hoped by the attendees that eventually VRML would also develop
companion binary formats.
Geometry -
The central feature of VRML is its ability to describe 3-dimensional
objects. These objects should be capable of containing the following
characterists:
Hierarchically-defined object definitions: That is, an object can be made up
of an arbitrarily nested list of sub-objects, each with its own
transformation matrix, and visible/active characteristics. This is quite
common in most graphics languages like PEX and GL.
Position and orientation: For each object and sub-object.
Material: material qualities (ks, ka, and kd, as they are normally called,
for specular reflection, ambient "glow" and shininess).
Color & Textures: Objects should have the ability to have texture maps
(disqualifies OOGL, at least in its current incarnation), and these
texture maps should be specified in a common format, which is (as determined
by those at the meeting) the Portable PixMap or PPM format, which is
supported by XV, among other applications.
Units of Scale & Orientation -
To avoid disorienting situations, like grabbing someone's "telephone" object
and finding out (the hard way) that it's two stories high in your view of
the world, it was agreed that a common unit of scale and orientation (how
big is big and where is up) would need to be defined. These are
conventions, in the sense that they need never be passed by VRML as a
message, but they need to be coded into the browser at a very basic level.
Level of Detail -
This is considered to be very important as a way to allow "cheap" computers
to have access to the same richness of VRML worlds as those who can access
VRML documents on SGI Reality engines. Now that tools like 3D Studio
include plug-ins like polygon decimators (which MultiGen and other high-end
simulator tools have used for years), it is possible to produce a model
which can have several different levels of detail. The implementation of
this construct is still undecided. Multiple URLs pointing to the different
descriptions? A hierarchical model description? Both?
URL "Anchorage" -
We should be able to attach a URL to any object or sub-object in a
hierarchy. Don Brutzman came up with a truly EXCELLENT idea, which gives us
some of the features of behaviors for free; attach MULTIPLE URLs to an
object and fire them off, in any order desired when an object is "opened".
Thus, clicking on an object could 1) reposition a camera, 2) play a sound,
3) bring up a web page, 4) whatever... The consensus was that this was a
_very_ good idea and should be part of a VRML 1.0 specification.
Cameras -
There needs to be a "camera" construct in VRML, perhaps multiple cameras
(which allow for stereo views of scenes, for those who have the rendering
speed and the output devices).
Lights -
There needs to be a full lighting model, similar to the ones found
in Inventor, RealityLab or RenderWare, so that any scene can have multiple
lighting sources with spots, ambient light, etc.
===================
At this point we drew a line and agreed that everything above the line HAD
to be in VRML 1.0, but everything below the line was less important.
Behaviors -
The most important question was not whether behaviors should go into VRML
1.0 (which everyone is agreed is too big a subject to handle in our
specified time frame) but rather, how to leave the properly shaped "whole"
in the specification to avoid later mishaps which would cause us to junk
most of or VRML design work as we retrofit the specification to handle
behaviors. This happened during the design of Open Inventor, the
Cyberspace Development Kit and OOGL, so it's something we need to be wary
of. Mark exhorted those who have traversed this design path before to lend
their support to the design of these issues in VRML, so as to leverage the
experience (and lessons learned) of these implementations into the VRML
specification.
Beyond that, no consensus on behavior implementation or specification
exists for the BOF attendees.
Messages -
Mark Pesce explained that Labyrinth, his VRML browser, could "listen"
to messages sent to it from other applications; in a manner similar to, but
more sophisticated than the "remote control" features of the Motif versions
of Mosaic. Thus, a "helper" application could direct or control Labyrinth's
behavior. This seems to be a natural way to get interaction between
applications on a user's desktop, so the group attempted to define some
messages which a VRML browser could choose to "receive" and act upon. The
three which seemed the most important were: 1) the ability to change the
position/orientation of a camera within a given scene; 2) the ability to add
a new instance of a given object within a scene; 3) the ability to remove an
instance of a given object within a scene. 2) and 3) are predicated on the
supposition that objects are "defined" in one stage, and "instanced" into a
scene in a separate process, rather like the OOP concept of a class
definition and an instance of an object of that class. Peter Kennard
noted that a simple, repeated Add/Delete sequence could give a very crude
animation capability to VRML 1.0 compliant browsers.
----------------------
At this point it was 10:15 PM; we'd been hard at it for almost two hours. We
left the meeting, satisfied about the definitions we'd come to about the
necessary features for VRML and VRML browsers.
Mark Pesce
VRML List Moderator
[email protected]