I collected the survey results together, threw out the submissions
which were apparently just tests (i.e., every option was "now" and no
proposals were voted on, this being the default setup). I arranged the
results in order of "now" ranking. (Refer to
http://www.wired.com/vrml/vrml-survey.html for what the survey looked
like)
Attribute: now later never no opinion
----------------------------------------------------------
Caching of objects: 50 3 1 1
Level of Detail: 48 5 1 2
Geometric Primitives: 48 7 0 1
Object-Oriented: 44 4 4 3
Texture mapping: 44 11 0 1
Standardized metrics: 40 3 6 7
Engines: 40 13 0 3
"Recommended" views: 39 9 5 3
Matrix Representations: 39 11 1 1
Hooks/API: 39 15 1 1
Transparancy rendering: 39 15 0 2
Obj desc./scene layout: 38 2 7 9
Scripting language: 29 19 3 5
Environmental Physics: 28 23 2 3
Inlined Sound support: 25 27 1 3
Typing Reps for links: 23 6 19 2
Bezier Curves: 20 34 0 2
NURBS support: 18 29 0 9
Fractal Geometry: 14 35 6 1
CORBA support: 8 8 1 39
OLE: 5 18 4 29
Hytime support: 4 3 4 45
Discussion:
As has been pointed out after I put out the survey, we don't
have to worry about caching of objects - as long as we allow for URL's
and their sister URI's, we're fine, as there are other workgroups
dedicated to solving this very problem.
A large number of people indicated that they weren't
knowlegeable enough about CORBA, OLE, and Hytime to decide whether or
not they should be included in any specification. I suppose we should
deal with this in the form of, let's try and leave a right-sized hole
in the code for what these technologies are supposed to provide. My
guess is that if these protocols are well designed, we don't have to
worry explicitely about incorporating them into the language.
Hopefully people knowlegeable about these can offer suggestions when
we come up with the spec as to what we're doing right or wrong.
The most contested issue was "Typing Representations for
links", which I described as "should a VRML link be represented as a
door, while an image link could be represented as a painting, etc.
User-definable." I realize now that this was misleading - I wasn't
suggesting that all links to other vrml spaces be represented as
doors, or images as paintings, etc. Furthermore, this is almost
exclusively a client issue - how they want to represent links that
aren't fully described it totally up to them (just like the NCSA logo
that appears when inlined image loads fails). Thus, the question
doesn't have much bearing on the language.
One last potential blunder was in asking about a two-tiered
object description/scene layout system, whereby we make a distinction
between files that simple describe arbitrary documents, and files that
describe entire scenes (lighting, etc.). However, I now realize that
this is also a browser issue; what I was trying to avoid were
situations where one scene #includes another scene, and their lighting
and camera layout descriptions might collide. If we accept that
there's no minimal required elements for a VRML file, and that
duplicate elements like lighting can be handled by the browser, then
including one file in another file is fine.
That leaves:
Level of Detail: 48 5 1 2
Geometric Primitives: 48 7 0 1
Object-Oriented: 44 4 4 3
Texture mapping: 44 11 0 1
Standardized metrics: 40 3 6 7
Engines: 40 13 0 3
"Recommended" views: 39 9 5 3
Matrix Representations: 39 11 1 1
Hooks/API: 39 15 1 1
Transparancy rendering: 39 15 0 2
Scripting language: 29 19 3 5
Environmental Physics: 28 23 2 3
Inlined Sound support: 25 27 1 3
Bezier Curves: 20 34 0 2
NURBS support: 18 29 0 9
Fractal Geometry: 14 35 6 1
There appears to be a good break in between the transparency
rendering support and the full scripting language. In previous
conversations on the list, we had sort of agreed that language
construction is a very thorny problem, a very big wheel to reinvent.
The concensus seemed to be to leave it to the next rev of the VRML
spec, or simply leave a hole big enough for any arbitrary scripting
language to take its place. (I.e., Perl, TCL, Lisp, etc.) I
personally prefer the latter.
So anyways, it looks like we have our requirements for the
baseline spec for VRML 0.1 (to become 1.0 when we hash it out and have
working clients). The survey form stated (without objection) that we
can take these requirements as basic:
Platform independence
True 3-d information (not pre-rendered texture maps a la DOOM)
PHIGS-ish lighting and view model
Unrecognized data types are ignored (to leave open future development)
Hierarchical data structure
Lightweight Design
Convex and Concave objects allowed
Fill-in-the-details support (pictures in a museum)
The file format is public domain
to which we add:
Level of Detail support
Allow authors to specify what level of detail
corresponds to their object representations.
Geometric Primitives
Having a set of standard definitions for things like
spheres, cones, cylinders, etc, so that they don't need to be
defined with hundreds of polygons.
Object-Oriented
Being able to define classes and instances of objects.
Texture mapping
Map bitmaps onto specified geometries.
Standardized metrics
Enforcing some standard for real-world measurement,
when desired. I.e., basing things on meters - basically an
object defined as a 5x5x5 cube from one file has no problem
fitting inside a 6x6x6 cube in another file.
Engines
Simple well-defined engines to base variables on, like
"time" or "door opening" or linking to an event.
"Recommended" views
Ability to define camera positions and angles for
people entering the scene.
Matrix Representations
Allow 4x4 matrices to represent object transformations.
Standard "rotate" and "translate" commands should be supported too.
Hooks/API
Provide the ability to "export" variables for control
by outside programs.
Transparancy rendering
Have one attribute of surfaces be transparancy.
What can wait until later is:
Full scripting language
Again, we might not need this.
Environmental Physics
Specifying scene-specific characteristics like gravity,
ambient temperature, etc. This would define a small set of
these characteristics that would be common to all objects in a
scene.
Inlined Sound support
I.e., the radio gets louder as you walk towards it.
This was probably shelved just as a complexity issue.
Bezier Curves
NURBS support
Fractal Geometry
These are advanced modeling and rendering techniques
we should see (or at least allow for) in VRML, but also require
more complex rendering algorithms.
Proposal Popularity
Before I go into the politically touchy subject of proposal
comparison, I should state that when you have 8 proposals that you
have to narrow down to a few, and then to one on which to base the
language, you're going to end up stepping on toes and getting on
people's bad side. What I hope language proposal authors realize is
that, at the root of things, these languages describe basically the
same thing, a 3-d space. Not having your specific proposal selected
doesn't exclude you from working with VRML; in fact, what I'm hoping
is that the standardized version of VRML we select is something for
which translators from the various other languages can be written,
perhaps written easily. To my eye, the construct (at some points even
grammar) of several of the languages seems isomorphic. The whole
point of a common format is to stop the reinventing of a language
every time someone wants to describe *space*. In this spirit, I ask
that we all have a little understanding of this issue and continue to
work together even after the chips are down - because it's after the
language is resolved that the real fun (writing clients) begins. :)
At the end of the survey you were asked to give 4 votes on
which browsers you thought had the most potential. I removed
duplicate votes (cases where someone voted for a proposal 4 times
counted only as 1 vote) and got these results:
Inventor: 26
OOGL: 20
Labyrinth: 15
CDF: 14
Manchester: 12
FFIVW: 8
Meme: 4
TSIPP: 1
It seems safe to say from this that we can narrow out FFIVW,
Meme, and TSIPP. Meme is more expansive than just a language, it
specifies a communications stream as well, so there might be something
from Meme we can still use later. "File Format for the Interchange of
Virtual Worlds" is good, but it seemed very similar to Manchester
Scene Description Language already. TSIPP I unfortunately never got
to experiment with so I can't explain its showing. Additionally, Mark
Pesce and the Labyrinth group has claimed that they have no love for
their language - it was only something they came up with in a few
hours to do the job they needed done. Finally, I've looked over the
Machester Scene Description Language spec and it seems very similar to
CDF; similar enough that I think they could be judged on the same
grounds. Which leaves:
Inventor: 26
OOGL: 20
CDF: 14
I'd like to at this point declare these 3 as the remaining
valid candidates for basing the VRML spec upon. What I think should
happen now is this: the people responsible for these proposals (or
others who use these languages) should come up with a short
declaration of what subset of their language (or what additions to
their language) would define VRML 0.1. Ideally they'd put this up on
the web and open it to review (some space on the vrml home pages can
definitely be provided for this). Working clients available for
downloading and testing that implement the spec with the language
would be even better, or perhaps a WWW interface to a virtual browser
(though it's the feel of the language and their capacities that are
the important part). Members of the list can debate the proposals for
a couple of weeks, and then we'll have another vote. Since the
fleshing out of the language will occur when the teams have submitted
their final spec-conforming proposal, we will then have our standard
spec-conforming language, and can begin work on writing clients and
modifying the parsers on existing clients.
The OOGL supporters already has a lead in making their
proposal available on the WWW, though the Inventor crew has laid out
some ways for Iv. to conform to a minimalist spec (though they might
want to revise it now). The CDF crew have a couple documents on the
web server here describing their language. We on the outside can
spend out time going over these proposals with a fine-toothed comb,
declaring what we like or don't like about each of them, debating their
features, etc. I expect this part to be busy, but hopefully we can
remain flame-free.
Let's get to work :)
Finally, I suggest changing the "M" in "VRML" from "Markup" to
"Modeling". It was originally termed VRML to signify its conceptual
relationship to HTML - but we now see it's much more a modeling language
than a markup language. Unless I get a storm of protest, I'll implement
this change.
My analysis of the survey results is open to comment, but I
feel fairly confident in it, and revising it isn't something I'll do
lightly, as it's mostly based on the expressed opinion of the group
anyways. Commentary is fine - it's what makes us a community. :)
Brian