> > 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?
Not even HTML lives by the static alone--see forms, imagemaps, and cgi
scripts of all kinds. Clumsy, but they show the desire and need for
interaction beyond the pure static model. The demands for interactivity
in 3d scenes will be much greater.
Surely there will be some uses for static 3d scenes, but I don't see this
as being at all the most exciting application of VRML. The ultimate
future of VRML is likely to involve interactive spaces inhabited by
multiple persons, physics simulation, etc. Creating interactive spaces
in static VRML documents seems like a silly idea at best--there ought to
be some sort of server to coordinate the views of the various clients.
Similarly, with physics simulation, it is neither necessary nor even
likely desirable to have the physics server integrated fully into the
rendering engine. In keeping with the up-and-coming modular model of Web
browsers, I'd like to be able to use KZQ's Super Deluxe General Relativity
Simulator in one-person scenes rather than the XYZ Mini-Wonder Inverse
Square Gravity Engine that comes with the XYZ web browser. Because of
the computational requirements, I may even want to run it on a Cray Y-MP
I have a (hypothetical :( ) account on, but do the actual rendering on my
local (sadly, hypothetical again :I ) SGI box to save bandwidth. What
would I use to send the results across the pipe but the same sort of
VRML-based format a shared-space engine would use to keep me up to date?
> 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).
I believe I mentioned limited path-based animation in my first post...
> 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.
Agreed, however, it's quite far from general, and to include anything
very much more general would require complicating the language a lot for
little gain.
On the other hand, the idea of substituting things into attributes of
nodes is a very powerful idea that could be used for dynamic
scene-mutation such as is required for interactive use anyway.
> 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
Probably a WWWAnchor referring to the animation as a fragment would
work. To do this would simply require some way to define nodes without
necessarily using them in the main graph, and some way of starting the
animation at all.
> 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.
Me too. This idea is very good as far as it goes, it just doesn't go far
enough (nor can it).
-- James Deikun (University of Pittsburgh) ...and his boring .sig #include <std_disclaimer.h> "Utopia" means "nowhere"--and it always will.