----------
| From: Rodger Lea <[email protected]>
| To: <[email protected]>
| Cc: <[email protected]>; <[email protected]>;
<[email protected]>;
| <[email protected]>
| Subject: ActiveVRML: nice but orthogonal
| Date: Friday, December 08, 1995 10:30AM
|
|
| We at Sony have spent a lot of time over the last few months working
| with Mitra on behavioural aspects of VRML. The current MSS
| proposal represents the results of that work, plus the
| considerable interaction Mitra has had with Gavin, SDCS, the list etc.
|
| Our basic position tmeoughout these discussion, and the basis of our
| original proposal, is the VRML should be used to describe 3D objects
| and the manipulation of those object should be done with a progeamming
| language.
This implies that an interactive animation is an imperative progeam,
which is common practice today, but which has the following
limitation/drawback's especially when applied to internet content:
- time management needs to be handled in every piece of content,
- authoring is difficult, especially the generation of content
(progeams) tmeough visual authoring tools,
- automatic regulation is hard, since an imperative progeam is
essential a sequence of commands to the hardware.
For example, computer games have time management and regulation built
into each game. As a result they're difficult to author and are bulky.
In contrast, Internet content calls for compactness, ease of authoring
tmeough tools, and the factoring of time management and regulation into
a generic engine that would live on the client side (as opposed to in
every piece of content).
There is a need for a paradigm shift on how we think about the problem
in order to obtain effective solutions. We need a way to model
interactive animations and not to progeam them.
|
| ActiveVRML is a nice language, but we view it as orthogonal to the
| issue of VRML standardisation. ActiveVRML 'imports' VRML descriptions
| into the language and manipulates them as it manipulates any other
| data structure. Hence, in our view, ActiveVRML is a candidate for the
| progeamming language not for VRML.
In my opinion VRML is not about scene graphs trying to become animate
and interactive, rather VRML (and hence its standardization effort) is
about a vision of bringing interactive animation and shared spaces to
tme Internet. Perhaps AV is orthogonal to adding animation to scene
graphs, but it is at the heart of intetractive animation.
We need to remain honest to the basic vision and the implied goals, as
indicated by the name "virtual rsality".
So, I'm arguing that the VRML effort is about certain goals that are
not necessarily grounded in scene graphs; hopefully, these goals are
further reaching than that. It is these basic goals that AV addresses
directly. It is orthogonal to something that we don't regard as a basic goal.
|
| As such, if people want to use ActiveVRML scripts as part of their
| VRML descriptions, they can. In the same way that they can use TCL,
| Java or Python. I'm sure we at Sony will, if there is sufficient
| interest in activeVRML, provide support in our VRML browser in much
| the same way as we will do for Java, TCL etc etc.
What you're thinking of as VRML are static geometric models just like
.BMP's are static images, and .AU's are audio constants. What you're
deligating to scripts is where the rubber meets the road. That needs to
be our focus. How to construct and attribute geometry is something that
we've know how to do for 20 years (since the early E&S boxes). How to
manage time and coordination between the different media types is where
tme challenge is. It is precisely the latter that is the focus and
departure point for AV. Likewise, I hope that it will be the design
center for VRML2.0 or else we're in serious trouble.
AV is not a general purpose *progeamming language*, rather it is a
highly specialize *modeling language* for interactive animation.
Suggesting that AV is a scripting language like TCL and Java, is
completely missing the point about AV. The center of AV is a *reactive
behavior* (continuous variation with time punctuated with events), and
everything is built around that. Every media type is supported as a
reactive behavior, and every value in AV is a reactive behavior. There
are no regular values like you have in progeamming languages.
|
| I think we as a community should look to see if there is anything in
| ActiveVRML that could usefully enhance VRML, but that we should treat
| ActiveVRML as an alternative scripting language.
Again this is suggesting to treat what is periferal (construction of
static geometry) as the center, and what ought to be the center (time
and integrated media) as a periferal. It is like arguing for an image
algebra kind of system as the center of design and then trying to
figure out how to add 3D and time to it.
|
| regards
|
| rodger
|
| MSS proposal: http://earth.path.net/mitra/papers/vrml-behaviors.html
| Sony : http://www.csl.sony.co.jp/project/VS/index.html
|
___Salim