Sorry if there's been any misunderstanding. I only meant to emphasize
my points of contention, not to offend. I'll try to tone it down a bit.
> Let me explain. I started out using the word "dynamic" and had it pointed
> out to me that a space can be "static" and still be animated. So now I
> have you misunderstanding the word "animated". By animation, I mean
> something in the space changes, either because the server siad it had to
> change, or the next line in a file being read by the browser says that
> something is being changed. I was using the word to define a .wrl that is
> "changing", but not neccessarily because of some external inluence. In my
> parlance, I was using "static" to refer to position. This means that all
> the objects are not moving. Now, you tell me what word I should use,
> which does not also imply that a server has to be used. Delta-ing?
> Changing? What?
Your term "live", below, sounds like a good one for this concept.
> Also: Because I say "animation" does not imply that I expect the server
> to render all the frames. Where did I say anything resembling that? My
I didn't mean to imply that the server would be rendering each frame.
I only meant that, without an encoded-in-the-scene animation or some
kind of interpreted language on the client side, animation could only be
supported by server updates, one per frame. The last sentence of the
paragraph I was reacting to with "No, I disagree completely" used to
read:
> The way animation frames (possibly time-based) need to be transported
> to the client will determine how the transportation spec needs to
> work.
I can see that perhaps I was misinterpreting this out of context, but
it seemed to say that frame-by-frame updates would doled out by the
server.
> whole point of view is to create something that can be used WITH OR
> WITHOUT transportation, so if I want to read a "changing" .wrl file off a
> CD-ROM, I can, and it loads, and it moves, and stuff changes while I view
> it. The server may be useful, but it is not essential to the idea of
> changing spaces. See Doom.
>
> Maybe we should use the terms "live" and "dead". "Dead" means the space is
> just the current VRML. A snapshot of a 3D space. It doesn't move at all.
> "Live" means the space may move, change, or have objects appear and
> disappear. Something as simple as a clock which has moving hands, getting
> its time from the user's system clock, is all that is needed to make the
> space "live". Not a server update, necessarily.
Ok, but I think there are more fine distinctions we can make. I think
there are different types of "liveness". I think our misunderstanding
has its source here. You were trying to lump two concepts together under
"animation", "dynamic", or "liveness" (changes from within the browser
and changes from outside the browser), while I was trying to lump two
concepts under the term "static" (no changes or changes from within the
browser). Your terms were probably more logical, if any lumping is
to be done, but how about the following for a definition of terms:
Dead: A completely non-animated, non-updated scene. Can be completely
described under the current spec.
Animated: A scene graph that contains some kind of engine or interpreted
scripting mechanism to provide motion in the scene. Does not
require external IPC.
Dynamic: A scene graph which is updated periodically by a server or some
other process external to the browser.
In the above terms, "Dynamic" and "Animated" are orthogonal concepts, and
you can have one without the other.
> > > 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
> >
> > No, this is wrong.
>
> Uh, may I politely point out that you have misunderstood me?
Certainly. Sorry if I have.
-- Pete McCann [email protected] Department of Computer Science http://swarm.wustl.edu/~mccap/ Washington University in St. Louis