On the VRML 1.0 spec, and VRML in general

James C Deikun ([email protected])
Tue, 6 Dec 1994 19:19:42 -0500 (EST)


First of all, I don't think there's any good reason not to include
TriStrips and QuadMeshes. They save bandwidth, and since the shapes they
describe are a subset of the domain of IndexedFaceSet they should be
trivial to add to any viewer conforming to the current draft
(optimizations would be a quality-of-browser issue).

The use of 'name' as the fieldname specifying a URL is potentially
confusing. I'd suggest 'href', simply because it's used for the same
purpose in HTML (though this wouldn't necessarily be a good reason for
just anything).

I'm not at all sure exactly why a person would be specifying cameras in a
VRML scene. Since these things are supposed to be interactive, etc, it
wouldn't seem like a plus to have everyone looking at a scene from the
same predetermined spot. They would really only be useful in a future
version which allowed interaction with a server to allow a dynamically
changing camera description.

This brings me to another several points:

o Is the primary use of VRML ever going to be as static .wrl files?
I don't see how this could possibly be; it would be a good idea to
figure out some standard for doing dynamic modification of a scene
over the network to allow for non-predetermined dynamism.

o Are the goals being set for the future versions of VRML actually
realistic or desirable? I can see some limited path-based
movement and so on as a useful optimization for smoothing things
when running over a possibly laggy net, but I really am not so
sure about the merits of including a special-purpose programming
language with general computing capability in VRML. About the
last thing the world needs is another Postscript. Programming
should be separated from scene description (a separate language
and document) and in fact it should be possible to use VRML as
a scene-description language for all sorts of VR simulation
engines.

--
James Deikun, University of Pittsburgh
#include <std_disclaimer.h>