> Andrew C. Esh, quoting Glen Wheless, writes:
> >> What's needed is a language for *describing* movements, rather than
> >> explicitly drawing them. To explicitly draw each object at a point in
> >> time would be a step backwards from what VRML represents. It seems to
> >> me that VRML is about describing rather than drawing. So we need a
> >> behavior description language.
> >
> >Yes, and it does not need to be (and should not be) part of the VRML spec.
> >VRML (IMHO) is intended to be a method for representing static spaces.
> >Another language can be used to represent changes to those spaces.
> >Certainly you could load a .wrl file, make changes and save it, but that
> >is not what I mean by static. A dynamic space would be one which changes
> >due to external influences, like server updates. A movement file
> >containing statements written in the same language, along with a .wrl file
> >which represents a starting point, would be enough to run a 3D
> >non-interactive movie. Dynamic Data Exchange could also be used to build
> >the server setup.
>
> You seem to be lumping together the two different ways to make changes
> in a scene. I would call a scene "dynamic" *only* if some external
> server was making changes to it, and dynamically updating the browser.
> Therefore, a scene with animation coded into it is still "static."
Hmmm. I kind of see your point, but I argue that the word "dynamic" can
be stretched quite a bit, here. My definition was limited to the idea
that static was being applied to position, and so dynamic means that
object can change postion. No outside influence is needed to accomplish
this. I wanted to show that to animate a .wrl, server involvement is
possible, but not required.
On the other hand, applying the idea of "dynamic" to the datat file which
is sent to the browser, then, yes, without further server updates, the
.wrl would have to be static, given that there were no other external
influences. The same logic would define all video games as being static,
which goes against my original intention for the statement. I could get
into discussing various aspects of metaphysical determinism, and argue
the point that there really is no such thing as "dynamic", but I won't.
> I don't think the animation functions completely solve the dynamic
> update problem, which is essentially a transport issue.
Uh, yes, the animation functions are the atomic building blocks for making
a .wrl "animated". With just those we could build a static-animated .wrl
(using your defintiion of "static"). On top of the animation functions
there would have to be added a protocol which would take these snippets of
code which defines the deltas, and transport them from the server to the
client (or the peer to the peer). Transportation is not the same problem
as the specification and construction of what is to be transported. For
example: You could base your dynamic space updates on the current load
average of your host, or the level of local network traffic. This way, I
could build a gauge into the wall of my home .wrl which shows the current
load level of my server. No transportation involved.
> However, I
> disagree with your statement that the encoded-in-the-scene behaviors
> should not be part of the spec.
I would love to put them in the spec. Maybe in a later version. We want
at least the statis-non-animated (current) VRML spec to get out and
become popular, though. It's useful, as it is. In later spec versions, we
can add the animation code, if we want to. Since it's a separate problem,
though, it can be a separate spec. We can't lump everything into one spec.
> I think they belong in the spec even
> more than the dynamic update features. You seem to be saying that it
> is so easy to specify such static behavior that the spec shouldn't
> even bother with it. I say it's a very logical extension that can
> and should be put into the next version of the spec. Dynamic transport
> of objects is much farther in the future.
The main reason I wanted to keep the animation code out of the current
spec, (aside from wanting the current spec to get finished sooner), is
because I feel that the way the animation is going to be used most often
(server updates to client spaces) is going to cause the way the animation
code works to be driven, somewhat, by the way the updates are delivered.
This implies a connection between animation and transportation (but not a
requirement that they be the same spec). For this reason, I think the
current spec should be left alone, and allowed to become an atom we can
work with. The animation spec would be developed, along with (but not
lumped in with) the transportation spec. The way the transportation spec
develops will determine how the animation spec will refer to objects. The
way animation frames (possibly time-based) need to be transported to the
client will determine how the transportation spec needs to work.
If the animation spec is kept separate from transportation, then it also
becomes an atom we can use. The VRML atom and the animation atom, in
combination, can be used to build a stand alone animated space. The home
.wrl with a load average gauge on the wall is an example of this. Add
transportation, and you have the whole pie. Note: Transportation would
never be needed without Animation (we can use HTTP, to move VRML-only
.wrl files), but the reverse is not true. You can also use HTTP to move
VRML-Anim .wrl files that do not need a dynamic connection to the server.
These would be like movies. When you need the dynamic updates, then HTTP
falls apart, and we need our more robust Transportation atom.
Most of what is needed for animation is probably already in the VRML spec.
We can simply redefine an object in order to move it. New objects can be
added with pieces of VRML code. I feel there is a border area where named
objects will be used between hosts to refer to objects being changed.
Some work will have to be done to make sure we can do animation with
that. The transportation spec needs the most work, in my estimation. HTTP
can be used for the low level part, but we would need to add the same
sort of extensions to it that Netscape did to do their dynamic updates.
For a demonstration of a "continuously updating" Web page, see:
http://www1.netscape.com/fishcam/fish_refresh.html
It uses Server Push, and Client Pull to keep a .GIF image animated
(slowly, but surely). There is a link near the bottom of that page which
takes you to an explanation of how this is done.
If we can add Push-Pull to HTTP, make it move pieces of VRML code
containing named objects, and build a browser which can accept a
connection, grab the VRML pieces, and apply them to the space, we'll have
dynamic spaces.
(I realize this was long winded, but I have a very clear picture of this,
and I have yet to have anyone poke a hole in it. All I've seen is just
some misunderstanding. I felt I had to hose it down from all angles. :)
---
Andrew C. Esh mailto:[email protected]
Computer Network Technology [email protected] (finger for PGP key)
6500 Wedgwood Road 612.550.8000 (main)
Maple Grove MN 55311 612.550.8229 (direct)
<A HREF="http://www.mtn.org/~andrewes">ACE Home Page</A>