First, let me say that the 1.0 spec for VRML looks really good. I have a
wishlist for version 1.1, which I'll send separately, but I think that 1.0
is a really solid foundation.
However...
There are a couple of aspects of the spec which may possibly hinder its
widespread implementation. These may seem like minor points at first, but
I feel that they're worth discussing.
I believe that we want VRML to be portable to a wide variety of
platforms, including many that don't have Open Inventor or even OpenGL.
Ideally, we want people (like me) to be able to write VRML browsers and give
them away, with source code, to encourage widespread adoption of the standard.
Obviously, browser-writers don't want to have to write their own rendering
engines; they want to use whatever renderers exist for the platform they're
working on. And that brings me to my point: there are three aspects of the
1.0 specification that may be a source of problems.
Problem 1: Non-convex faces
The vast majority of all renderers do not support non-convex faces. In fact,
many of them only support triangles (which are guaranteed to be both planar
and convex). Of particular importance is Microsoft's 3D-DDI spec; it only
accepts triangles and quads, and explicitly states that the quads must be
convex (or else the results of rendering them are "undefined").
Now, the triangles-only limitation isn't a big deal; clearly, any convex
polygon can be trivially decomposed into triangles. This is not the case for
non-convex polygons.
I'm glad to see that the spec has a default faceType (in the ShapeHints
node) of CONVEX, but I would like to see us go further. Ideally, we would
simply state that "faces are assumed to be planar and convex".
The alternative is to give the people who are implementing browsers the added
burden of decomposing non-convex faces into convex ones; I would say that
the fewer hurdles we put in the path of a potential implementor, the better.
Note that this change would not affect any existing or upcoming browsers;
if they do support non-convex faces, that's okay (after all, many of the
browsers seem to support a superset of the VRML spec anyway!). By dropping
the *requirement* that browsers deal with non-convex faces, we're making
life easier for the people we need most -- the ones doing the actual
implementations.
Problem #2: 4x4 modeling transforms
I like the Transform node. I like it a lot. In fact, I like it so much
that I think we should keep it, and get rid of the MatrixTransform node.
The nice thing about Transform is that the scaling, rotation and translation
are all nicely broken-out; they get applied in a specified order,
and it's easy to modify them to account for different coordinate system
orientations. They're cool.
MatrixTransform nodes, on the other hand, are yucky.
If your coordinate system doesn't happen to match Inventor's,
you have to decompose the matrix and recompute it. Worse yet, that pesky
fourth row (or column, depending on whether you're using row or column
vectors) doesn't map well onto systems that use 3x4 modeling transforms
(which many do). Scaling, rotation and translation can all be handled
by nice, efficient 3x4 matrices; you don't *need* 4x4's.
Anything you can do with a MatrixTransform you can do with a Transform,
unless you're planning on using that fourth row (which I would argue
shouldn't be used). Some systems use 4x4 for the perspective transform,
but the majority of the ones I'm familiar with use 3x4 for the modeling
transform, which gives them a performance benefit. Goodness knows that
VRML browsers need all the performance help they can get!
Therefore I would recommend dropping the MatrixTranform node. Again,
this has zero impact on existing or upcoming browsers; if they do support
MatrixTransform, that's fine. I'm just saying it shouldn't be a
*requirement* of the spec.
Problem #3: Scene graphs
This one isn't really a problem, but it may turn out to be a problem
at some point in the future.
Almost all the renderers out there have some notion of hierachical
collections of objects; in fact, I suspect many of them do it in remarkably
similar ways. However, so far as I know, *none* of them implement a
"scene graph" in the same way that Inventor does.
Right now, that's a non-issue; people can implement browsers that traverse
the scene graph once, doing things like tesselating the cones, spheres and
cylinders and building renderer-specific data structures from IndexedFaceSets.
That's fine, since the VRML spec does not explictly require that you be
using OpenInventor or mimicking its internal data structures.
However, doing this effectively discards the original scene graph
information, replacing it with the natural data structures of the renderer
being used. In some cases, its those data structures that help give the
renderers such a speed advantage over (for example) OpenGL.
The (potential) problem arises when we start discussing behaviours.
A lot of the discussion of behaviours has centered around
"modifying the scene graph"; the problem is that there's absolutely
no guarantee that there *is* a "scene graph" as such. For example,
individual transform nodes will probably have been accumulated into a single
matrix for each object; if a behaviour tries to update just one transform
node, it won't be able to (the information isn't independently available).
I do *not* believe we should mandate that the Inventor scene graph be
preserved; quite the opposite, in fact. I think we should design our
behaviours in such a way as to make very, very few assumptions about the
particular data structures of any particular browser implementation.
Again, this is mostly a consideration for the future. The existing spec
doesn't pose any serious problems, though the inclusion of the Switch node
is (I think) taking us in the wrong direction.
Anyway, sorry to have raised so many thorny issues. I also apologize for
coming to this party so late; I'm one of the unfortunate ".ca" people
who got lost in the shuffle some months back. I've spent most of this
week reading through the massive hypermail archive, and my brain's still
spinning a bit.
Looking forward to hearing peoples' comments...
-- Bernie Roehl University of Waterloo Dept of Electrical and Computer Engineering Mail: [email protected] Voice: (519) 888-4567 x 2607 [work] URL: http://sunee.uwaterloo.ca/~broehl