From: dstamp@watserv1.waterloo.edu (Dave Stampe-Psy+Eng)
Subject: TECH: REND386: adding motion
Date: Tue, 4 Feb 1992 00:01:05 GMT
Message-ID: <1992Feb4.000105.29555@watserv1.waterloo.edu>
Organization: University of Waterloo



I thought I'd put before you the next step in the REND386 saga before it's
begun, in the hopes of sparking some feedback and discussion.  Basically,
it involves moving and animating objects, either autonomously or under
direct user input.

REND386 uses a intermediate world representation of objects: polygon vertices
are converted into world coordinates when objects are placed or moved, then
the renderer uses these positions to compute visibility etc.  This is more
efficient when most objects are static, as compared to each object having
a unique transform matrix which must be recomputed (or multiplied by the 
viewpoint matrix) whenever the screen is redrawn, even if just because of
a viewpoint shift. 

However, this relies on having a fast method for moving an object (translating
from object to world coordinates).  This must be assemblyized for speed.
The basic operations to be performed are a rotate around the object's
origin (x=0,y=0,z=0) and a translation to its position in world coordinates.
This can be done in about 20-23 uS/vertex.

Now all this is OK, but Bernie and I would like to add some structure
to motion in the world, especially in terms of objects that can change
shape (walk, grasp, crawl etc)-- animated "actors", if you will.  The
method we are looking at could be called "armature animation".  Each
figure has a virtual framework with joints that can be set to any
angle-- by specifying joint angles, you can specify gestures across
a wide range of figure sizes and "topologies".  Joints can also slide
along the armature for other kinds of effects.

Of course, the "armature" doesn't actually exist, but is represented in
a tree data structure.  Say the root is the "body" object, next is the
upper torso object, the upper arm object, lower arm object, hand object,
and 3 levels of finger segment objects.  Moving a finger joint does not
affect the upper joints, while a gesture can be performed independantly of
the position of the rest of the arm.  This is a very compact and useful 
way to represent object motion relationships.

The proposed method for computing a new object position is to first
change joint angles as needed and mark as moved.  Then traverse the
tree of object segments, first positioning and moving the body from
object space to its proper place in the world.  As a result of this,
joint points that connect to other segments will be moved also.  And the
matrix that expresses the rotational "attitude" of the body can be carried
through to the rotation of the subsegments too.

For each subsegment, then, a rotation matrix is computed that is the product
of the joint's rotation angle matrix and the "parent" segment's rotation 
matrix.  The vertices of the object are then rotated by this matrix and 
translated to the proper position on the figure by adding to them the
world coordinates of the joint on the parent segment.  This minimizes the total calculations  done, as each vertex is translated and rotated once.

The "armature" of the segment then consists of a line joining the segment
object's origin to the next segment's joint position (which is part of
the segment object's definition, and is handled just like a polygon
vertex).  This puts the onus of armature design onto the object creator,
where it belongs.  A "mannequin" world be designed as a set of segment
objects with each in its rest (zero angle)  position and the object's
origin at the joint where it connects to the parent object.

I realize this may seem a bit unclear, but it's in "middle" planning
stages.  Not that difficult to program, but the demo must be done
from scratch.  However, the potential advantages are obvious, I think.
The problem of animated figures, bodies, Gloves, etc. become much
simpler once there's a standard to follow in terms of how to do it.
Eventually, this could lead to a complete set of interface guidelines
to network distant systems together in a shared VR world (This is
Bernie's hobbyhorse, and I've taken many a ride on it.)


--------------------------------------------------------------------------
| My life is Hardware,                    |                              | 
| my destiny is Software,                 |         Dave Stampe          |
| my CPU is Wetware...                    |                              | 
| Anybody got a SDB I can borrow?         | dstamp@watserv1.uwaterloo.ca |
__________________________________________________________________________