[Xvrml-agents] on animation

[Miriam E. <mi...@we...>]

Hi Folks,

Here are some thoughts for your rumination:

We need to simplify animation.

Currently, in vrml and xvrml there are some fairly arcane animation 
capabilities (all the interpolator nodes), but for all their complexity 
and difficulty to use they are awfully limited. They owe more to 
traditional cartoon animation than computer simulation because they 
require foreknowledge of the start-point, end-point, start-time, and 
end-time of any movement. Usually they need you to set up a timer, 
associated routes, keyframes and keys to allow for 
acceleration/deceleration, and a fairly complex script too, but we'll 
ignore all that added overhead for the moment.

How many actions in simulations work that way?

Take for example the simplest action of dropping a ball. It is not 
terribly hard to calculate out beforehand the path it will take, so the 
vrml-style requirements don't seem unreasonable.

Now imagine that you are dropping the ball onto the top of a tree. The 
ball will bounce from branch to branch, possibly getting stuck at some 
point, or perhaps eventually making it to the ground under the tree, or 
even being knocked right away from the tree. Such situations can be 
difficult or even impossible to precalculate because miniscule 
differences in starting conditions can make for entirely different 
outcomes -- the so-called butterfly effect.

But even worse, precalculating the action becomes very wasteful. It 
means you effectively calculate the animation twice; once to 
precalculate and store all the movements, then the second time to 
actually perform the sequence.

This is very daunting if movements of great complexity need to be made. 
The apparently simple animation of making an avatar walk to a table to 
pick up a glass becomes horrendously complex. And forget the hope of 
building upon them to create slightly altered versions that can be used 
as parts of even more complex animations.

The only sensible way achieve simple, flexible animations is the use a 
different, simpler kind of movement: a move command consisting of a 
force operating upon an object's mass.

Luckily the pre-existing Open Dynamics Engine (ODE) lets us avoid most 
of the work here. (See http://sourceforge.net/projects/opende/ and 
http://ode.org/ ) We just need a couple of extensions to the (xvrml) 
language to take the new, simpler move command: a mass attribute for 
objects, and a force. Now we can simply send that data to ODE and let it 
run the animation, sending updated object data to the viewer program.

With a simplified method of animating objects, moving avatars in 
interesting and progressively more complex ways becomes much, much 
easier to do. Now, to specify movement of a hand to an object you don't 
need to give start-time, end-time, start-position, end-position, keys, 
and keyframe values to each of the hand, lower-arm, and upper-arm 
objects. All you need is to apply a force to the hand. ODE moves it, 
taking into account its mass and the IK links to lower- and upper-arm. 
No further work is required of the world author.

If a walk animation is constructed using a series of forces orchestrated 
in cascading fashion to operate on the limbs of an arbitrary avatar 
there are a few very nice consequences.
- One effect is that the walk animation applied to a dwarf will play 
differently when used on a giant. The user doesn't need to alter timings 
and many intricate aspects of the animation; it will just run 
differently because it is affected by mass. It isn't simply a matter of 
the giant walking more slowly than the dwarf. The force-mediated 
animation will do this correctly, whereas it is almost impossible to 
alter a traditional vrml animation to take account of the differences, 
because the same thing in vrml uses long, opaque lists of possibly 
thousands of numbers.
- Another result is that modifying the animation or adding to it becomes 
very simple. Changing a few of the forces, for instance lessening them 
on one leg, can easily turn a walk into a limp.
- Another side-benefit is that natural, lifelike acceleration and 
deceleration become the norm, unlike the unrealistic, sharp movements 
that are common in vrml. Smooth movements in vrml require the author to 
devise complex precalculations of timing for keys and keyvalues. A 
simple force/mass system requires just forces to be applied.

This has wider implications for end-use too. Rodney Brooks showed how to 
program robots using a kind of distributed intelligence, where each leg 
has its own "ganglion" coordinating only loosely with the others. This 
produces very flexible and adaptive behavior. Using a simplified 
force/mass model for animation in makes it possible to create simple, 
open-ended, cascading animations that are similarly flexible and 
adaptive. Such things are virtually impossible if you need both the 
start-point and end-point of all actions (let alone start-time and 
end-time, and keys and keyvalues!).

More later.

Best wishes,

	- Miriam