The Pavane visualization system
(more info available at
http://swarm.cs.wustl.edu:80/~jyp/docs/PSRM.html#Graphical Objects
)
lets you write code like the following:
<Query>
=>
_sphere (
_radius := _ramp(0, 1, 5, 0),
_center := [i*2+1, j*2+1, 0],
_color := [255,255,0] );
where "_ramp" is one of the predefined animation functions. The one
above takes the _radius attribute from 1 to 0 with smooth interpolation
between frame 0 and frame 5. Any attribute can be animated by a _ramp or
one of the other 3 time-dependent functions. 3-vectors are interpolated
element-by-element.
This is a very general approach to the (built into the scene) animation
problem that does not require specialized node types. It is analagous
to an Inventor engine, except that we restrict the class of engines to
a limited set of frame-number dependent functions. In fact, these
animation functions are currently implemented by a set of customized
OpenInventor engine types.
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."
I don't think the animation functions completely solve the dynamic
update problem, which is essentially a transport issue. However, I
disagree with your statement that the encoded-in-the-scene behaviors
should not be part of the 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.
-- Pete McCann [email protected] Department of Computer Science http://swarm.wustl.edu/~mccap/ Washington University in St. Louis