Re: On the VRML 1.0 spec, and VRML in general

Gavin Bell (gavin@krypton.engr.sgi.com)
Tue, 6 Dec 1994 19:19:50 -0800


On Dec 6, 7:19pm, James C Deikun wrote:
> 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.

I believe the idea is that the camera defines the initial view when you
follow a hyperlink to that world. The browser then lets you move from that
initial view.

> 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.

HTML is extremely useful even though it is a static description of a page.
Why do you think 3D scenes are different?

> 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.

I agree that a non-editable format like PostScript should be avoided. But I
believe that you can describe interesting, useful "behavior" in a static way,
just as you don't need a programming language to describe 3D geometry
(although you might be constrained in the kinds of 3D geometry you can
describe).

For example, a keyframe animation is easily described by a static description
of the keyframes and values, with the output of the animation feeding into a
transformation somewhere in the scene. No need for programming there.

I can imagine a Button object that appeared as an object in the scene and
somehow caused the keyframe animation to start when the user pressed the
button. Again, no need for a full-fledged programming language, and I can
imagine an API that makes it fairly easy for an authoring program to
understand keyframe animations and buttons, and allow users to graphically
modify them.