Re: [Quake-devel] Skeletal Animation

[Seth G. <sga...@li...>]

On Wed, 3 May 2000, Michael Mol wrote:

> > Bones are animated.  Each bone animation frame has position and angle
> > information.  This could be stored as two vectors (a 3d coordinate, and
> > euler angles) or as a transformation matrix, or as quarternions or some
> > other form.
> 
> I think this is where interpolation should be focoused, as the vertices
> would follow along with each bone movement.

Of course.

> > Bones are hierarchial.  Each bone except for the "root" bone has a
> > "parent" bone.  When you position a bone you combine it's rotation and
> > position with it's parent's rotation and position, and it's parent's
> > parent's position, and so on.
> 
> That raises a question...What if somebody were to want to create a
> toroidal model, and have a loop of bones?  I would think that the
> below-mentioned differential (Is that a better word than 'wieghted'?)
> system could potentially be used to eliminate the loop by relating model
> points to  the separated bone ends.

1. You should not make this kind of loop in a hierarchial system (My
boss's boss is my peon or I am my own grandpa :-) Typically an animated
donut (!?) would have seperate bones that do not have a child/parent
relationship.

> > Bones move vertices.  Each bone has a list of vertices it is
> > attatched to.  Before rendering the model, the bone's rotation and
> > position (combined with it's parents and so on) is applied to those
> > vertices which are attatched to it.
> 
> This raises the question of skeletal modelers...I think poorly of the
> idea of making everybody go out and buy something like 3D Studio Max or
> some other expensive and/or user-hostile system.  Mongoose?

I am always looking for cheap, free, or open source modeling programs.
If you know of any please let me know.  Here are some that I use or am
keeping an eye on:

qME - a $25 shareware Windows skeletal animation based Quake modeling and
animation program. I've been using it for years.  The biggest problem is
it's lack of source and model format specs.  It is also no longer in
development.

MilkShape3D - $20 shareware Windows skeletal animation based modeling and
animation program.  It supports Half Life and Quake 2 model formats
(among others.) This one is fairly popular right now and being actively
developed.  It is also sourceless and without native format specs.

Blender - Nasty, complex, (three buttons required) interface, but it
supports Windows, BeOS and most Unixoid platforms, it's sort of free
(current version has a seperate free and "C-Key" version, but next version
is supposed to be all free, as in no charge.  They seem to be considering
GPL eventually.)

Quake Army Knife (QuArK) - It had a model editor way back in version 4.07,
but version 5.x introduced a complete redesign, and now the model editor
isn't really an "editor", but more of a viewer, simply because the editing
features like moving and creating vertices haven't been added back in.

I was going to work on QuArK's model editor, but then I got a job that
wastes too much of my time for me to work on all of these projects at
once.

QuArK is GPL and it has active user and developer communities (It's Quake
engine map editor is fairly popular and much more powerful and easy to use
than anything else out there - I'm talking about fundamentally superior
from high level design philosophy to user interface paradigms.)

On the downside QuArK is written in Delphi, which means it can't be
compiled with free software (although most of the program is controlled by
python scripts so most features don't require Delphi coding.) and it is
only available on Windows (although supposedly it works with Wine and
Borland supposedly has a Linux port of Delphi on their agenda.)

Such is the world of inexpensive 3D modeling and animation software.  Lots
of promises and precious little substance.

> > In a primitive skeletal animation system like Quake 3, whole models
> > are attatched to bones instead of individual vertices.  
> 
> How do you attach a whole model to a skeleton?  Wouldn't you have to
> have reference points within the model that would be pinned to the
> skeleton?

Well, in the simple case of a gun, the player holding the gun has a bone
called "hand" in his skeleton.  The gun is then placed in the player's
hand and the "hand" bone controls it's position and orientation.  The gun
can be designed so that it's origin corresponds to the location of players
"hand" bone.

(Of course you could also have a "handle" bone in the gun and use that to
position the gun if you find it more convenient.)

> > In an advanced animation system individual vertices are 
> > "weighted" to bones, so a vertex might be "67%" 
> > attatched to one bone and "33%" attatched to another.
> 
> This would work extremely well with detailed player models...You could
> potentially see a person's muscle move in conjunction with the parts it
> attaches to.
> 
> Obviously, this incorperates additional computations which could in turn
> affect framerate.  (unless the computations are made independant of
> frame rendering...something like page-flipping, but for data.)

You could do the calculations every 0.1 seconds and then interpolate
linearly if it turns out to be that slow.  But we really need to have some
kind of performance estimate before we commit to a system like that.

> I see two possible ways to incorperate it: Perform the computations on
> the client, thereby giving the server time to think about the other
> parts of the game, or perform the computations on the server, saving
> the CPU cycles of lower-end computers, thereby helping them to support
> the client.

Using the server for per-vertex computations is simply not an option :-)

> > The common practise today seems to be a middle ground, like Half Life,
> > where each vertex is attatched 100% to a bone.  There are two ways to
> > represent this relationship:
> > 
> > 1. Each vertex has a bone index.
> > 2. Each bone has a list of vertices.
> > 
> > The first system is attractive because it is simple and predictable - it
> > adds a certain amount of memory for each vertex.
> 
> Certainly.  However, wouldn't it also be a good idea to pre-calculate
> the angle-change relationships between vertex and the bone its connected
> to?  (Think of each vertex as the end of another bone, which is in turn
> connected to the vertex's 'boss.')

I'm confused.  What is the "angle-change relationship" between a vertex
and it's bone?

> I don't know about 'better', but it would certainly be useful for
> backwards-compatability.  If a person were to want to improve some
> models in the game, he could simply place a file defining the skeleton
> with the same name as the model file, but with an additional
> extension.

Right, or they could have a different name and be combined by Quake C.
For example you could have a generic soldier skeleton and several
different soldier models.

> All three of the methods listed have advantages, but it would probably
> be best to incorperate only one (to lower operational complexity and
> thereby increasing FPS) of them.  Which should it be?

I think the best approach is the superset of all of the features that can
be used without killing framerates.  (i.e. combine the best elements of
Quake 3 and Half Life, add "weighted" or "differential" vertex anchoring
IF it doesn't slow things down badly.)

> The skeleton add-ins could be incorperated into the differential
> rendering method, combining both of them, but that slightly increases
> overhead.  The skeleton add-ins could be used with the existing model
> formats, but then you don't have the smoothness that the differential
> format gives.  With the verteces having bone indexes, it would make it
> easier to eventually step up to a differential system, but it would
> shoot the older-model upgrading possibility so full of holes that you
> could reach your hand through it without touching it.

I don't see how either approach is better for the "differential" or
"weighted" vertex type of animation:

1. modified vertex structure using the first approach:

	b. bone index
	c. bone "weight"

2. modified bone structure using the second approach:

	b. list of vertex indices attatched to this bone
	c. list of "weights" of vertices attatched to this bone
  __    __    _                                    _    __    __
_/  \__/  \__/  Seth Galbraith  "The Serpent Lord"  \__/  \__/  \_
 \__/  \__/  \_ sga...@kr...  #2244199 on ICQ  _/  \__/  \__/
_/  \__/  \__/  http://www.planetquake.com/simitar  \__/  \__/  \_