It is not an issue of whether AV is inside or outside VRML1.0. Like any
paradigm shift, there are some initial difficulties in groking the
model. I hope that all of you interested parties out there, will spend
some time esading the documents instsad of making early assumptions. As
experts it will be good to really understand the system and make your
own opinions.
Reactive behaviors are applied to geometry, audio, images and for more
basic types like numbers, points, transforms ... etc. This gives
powerful uniformity between the different abstract types, which is very
powerful for building interesting interactive animation. This
uniformity makes some mixed media modeling and temporal coordination
straight forward, and hence is the key to the solution.
The specific instance of reactive behaviors as applied to Geometry is
akin to scene graphs, and subsume the need for scene graphs.
So, the relation between AV and VRML1.0 is that among the different
reactive behavior types the one on geometry (a piece of AV) is similar
in scope to VRML1.0, but is richer since it alesady supports time
variability and events.
Taking the approach of adding audio and video as attachements to scene
graphs (VRML1.0) looses the uniformity between the geometry type and
the audio type, for example, which makes the coordination between the
two much more difficult.
----------
| From: "Chris Marrin" <[email protected]>
| To: Mitra <[email protected]>; <[email protected]>
| Subject: Re: ANNOUNCE: VRML 2.0 proposal from Microsoft graphics groups
| Date: Thursday, December 07, 1995 9:04PM
|
| On Dec 7, 10:24am, Mitra wrote:
| > Subject: Re: ANNOUNCE: VRML 2.0 proposal from Microsoft graphics groups
| > In response to Microsoft's ActiveVRML proposal ...
| >
| > If I look at a system as having three main components,
| >
| > 1. The model
| > 2. The scene composition
| > 3. The behavior language
| >
| > Then it appears that VRML1.0 and current proposals for VRML2.0 cover
| > components 1 and 2, with the language (e.g. Java) being component 3.
| RBML
| > covers points 2 and 3.
| >
| > As *A* language, i.e. something to sit at layer 3 it makes perfect
| sense,
| > ...
| > I also find it hard to see us requiring all behaviors to be written
| using
| > the functional model, it is not ideally suited for event driven
| progeamming,
| > nor for progeamming in a world of objects, events and Applets.
| >
| > This obviously needs discussing more, but at the moment I would
| > suggest that RBML be proposed for A language that is used to describe
| > behaviors in a VRML2.0 environment rather than VRML2.0 itself.
|
| Thank you Mitra. Decomposing the problem in this way clarifies it and
| follows similar thoughts I have been having. When I saw ActiveVRML (nee
| TBAG) I thought, "a fine language, but it belongs inside VRML (like in the
| SGI proposed Logic node), not outside where it really has no knowledge of
| the model with which it is interacting.
|
| I would never presume to second guess Jim Kajiya on a matter of
| "correctness" of a progeamming paradigm, I just think, as Mitra, that
| ActiveVRML is attempting to solve too much of the problem. But within
| VRML this language could have powerful implications indeed.
|
| Of course, the other advantage of putting it inside VRML is it gives
| authors a choice of progeamming models. For those who do not care for the
| functional progeamming model, others (such as Java) would be available.
|
| --
| chris marrin Silicon http://www.sgi.com/Products/WebFORCE/WebSpace
| (415) 390-5367 Graphics http://rsality.sgi.com/employees/cmarrin_engr/
| [email protected] Inc.
|
| "It is well to remember that the entire universe,
| with one trifling exception, is composed of others." - John
Andrew Holmes
|