[snip ...]
> >Another conceptual trauma, even more basic: Are VRML spaces static, or
> >dynamic? Obviously there is some dynamism in the use of a link, but does
> >that mean that each link simply takes you to another static space? I
> >think the answer is "No".
>
> Agreed ..
I don't quite agree with this, but maybe it's just a question of terms. I
don't call a scene with animation or even interaction information "dynamic".
To me, a "dynamic" scene is one that can be reconfigured by external
influences. Right now, VRML is a spec for static scene descriptions, and
the improvements people are talking about adding to the next release will
just encode animation and interaction information in the scene graph.
This is not to say that I think VRML should be extended to include "dynamic"
features (as defined above). Doing this *would* require some kind of
networking, transport-layer specification. I guess your opinion on this
would depend on whether or not you buy into Mark's view of VRML as a
networking technology.
VRML as networking technology is a very interesting idea, but right now
it is simply not the case, either in the 1.0 draft or in the near-term
improvements that are being discussed. Even so, I want to talk about my
ideas for what the transport-level mechanisms should be (see below). I
do think they might conceivably impact the standards process at least by
providing motivation for static features, so I don't feel out of place
discussing them here.
> >This brings us to the question of how interaction is defined (is it part
> >of the VRML language?). The reaction some folks had recently to simple
> >"rotating" objects leads me to think that such things are not intended to
> >be part of VRML.
>
> Why ... v1.0 handles static worlds but v4.0 .. ? we've started now .. why
> not extend VRML instead of going off with something different .
>
> >Do we need to limit VRML to the simple process of "marking up" a static
> >scene?
>
> Is markup _the_ important feature or just one of many ?
Certainly the 1.0 spec should not be expected to do any more than this. Maybe
the 2.0 spec will just be a "behavior markup" language, but still a "static"
model of underlying information.
> > Should we then define another language for interaction and motion
> >("what to do when the user does something"), to add the dynamism of an
> >interactive environment?
>
> It depend what you mean by, dynamic, interactive, and motion .. I would say
> interactive means to be able to pick up objects, press buttons, move around.
> Motion means independent movement that objects possess whether you interact
> with them or not (like spinning objects) and Dynamic means events that occur
> from external stimuli (perhaps an mpeg stream being played on the screen of
> a TV in your world, or another user walking around).
These definitions sound good to me.
> Motion and interaction can be modelled with in VRML as parameters of the
> objects : splines and time parameters can be attached to objects to model
> motion, and interaction could be defined by bounding boxes, splines etc.
>
> Its' dynamic objects that cause a problem .. you need to be in touch with
> the 'server' to update the client view
Yes. Exactly.
> >This leads me to my last question: Since the dynamic part of VRML is at
> >the client, don't we now need yet another language and transport system
> >for the servers to run which distributes the changes to the space that
> >one user makes, to all the other users who are in that same (multi-user
> >interactive) space? Do we need a VR Interaction Protocol (VRIP)?
The dynamic part of VRML would come from an interaction between the client
and server. As such, I don't think we want an "Interaction" protocol (which
connotes a protocol between users and objects). Rather, I think we need
a transport protocol: VRTP.
> I would agree that a dynamic transport or protocol is needed ... the dynamic
> objects are still VRML objects though except they change with time from an
> external source .. the protocol or transport system needs to be able to
> update the client with new objects .. this opens a bit of a can of worms :-o
Since when have we been afraid of a few squirming dirt-eaters? :)
Let's think about what would have to happen under VRTP:
1) a browser downloads a document.
2) the browser subscribes to an "update service" provided by the server.
3) the server periodically sends new objects to the browser as the
document is changed.
The server must provide the subscription service. It must also consult a
table of subscribers every time a document is changed. I think it would
be interesting if the table could be more complex than a simple list of
subscribers. Each subscriber could register not just a document, but also
a specific type of VRML object or scene structure pattern that the subscriber
was interested in. This would allow the publisher (server) to prefilter
the information before sending it along to the browser, which would help
reduce network traffic.
There might be more interesting implications of allowing the registration
of arbitrary patterns. There is no reason that the destination subscriber
has to be a browser. It might be another pattern registered with another
server somewhere else on the net, that is only triggered when the right
input arrives from somewhere else.
You might say, "all this might be nice, but it will introduce so much
new traffic on the net that it will become completely unusable."
I claim that this is not the case. Such a system would be an
interrupt-driven distributed event filter. What we have today is the
alternative: polling. If people want this kind of service using today's
web, they must download it repeatedly.
If you find these ideas interesting, you might try reading about the Rete
algorithm, keeping in mind the distributed event filter setting. I would
suggest the seminal paper:
Forgy, Charles L., "Rete: A Fast Algorithm for the Many Pattern/
Many Object Pattern Matching Problem", in _Artificial_Intellgence_
vol. 19 (1982), pp. 17-37.
> But hey .. it's all possible ... I want to be able to 'jack in' to my VRML
> deck and meet the 'matrix'
>
> :-)
Ooh, ooh, count me in...
-pete
-- Pete McCann [email protected] Department of Computer Science http://swarm.wustl.edu/~mccap/ Washington University in St. Louis