Jim Langston wrote:
> What format are these models in? I would imagine that they are
skeletons
> that can be animated with meat on them. That is, information about
bones
> and joints so you can programmically move them into any position. I
would
> like to do this in my own game. Right now we are using quake type
models
> and there are limited poses and it's a pain for the 3d artist to put
them in
> each pose.
The actual format isn't really im****tant, what is im****tant is how the
data is represented.
In PC shooter-land, it used to be that the models were posed and all of
the vertex locations ex****ted, and then at runtime you'd morph between
poses. This leads to an absolute crapload of data, but the end process
to get polys on the screen isn't too tough.
When Tomb Raider came out, it became clear that they didn't want to be
limited by this method, so their models had distinct pieces for each
body part. There was a torso model, a head model, and perhaps a neck
model in between if it wasn't part of the torso. What they then did was
hang each successive object off of its parent, creating a hierarchy that
looks a lot like a human skeleton. So, each pose has a hierarchy of
matrices, each describing the transformation from local space to parent
space, and the cascade of matrices all the way to the root (which was
"local to world") would yield the appropriate matrix to draw that
segment with.
Single-skin meshes came out of that. When I saw Tomb Raider (and it
utterly crushed my game that came out at the same time), I was a little
shocked that they didn't take it to the next level; there's no reason
why a character mesh couldn't be built with some number of matrices,
each vertex attached to a specific matrix. So it was just like a
segmented mesh, but now you got all of those connecting polygons at the
joints. It doesn't look very good in the naive implementation, but it
does the trick.
The next step was to have the vertices influenced by some number of
local bones. The math is the same, but now you have to blend together
several "result" vertices (the result of each matrix transform) to get
your final vertex position.
Does this make any sense? If not, imagine a cube. The four vertices on
the top are attached to the "hip" bone, and two vertices each on left
and right are attached to "leg" bones, so you've got a skeleton that can
walk. As the "leg bones" animate back and forth, the bottom vertices
move back and forth. You've got polygons stretching all over the place,
but it should demonstrate the idea. ...if you assume that the "hip"
bone is the "root," then you move the object around by its hips and
animate the legs to make it look right. (Although it can get far more
complicated than that, too.)
How you store the data is up to you, though. ...and how you get it out
of a modelling package is also up to you.
Good luck,
-tom!
--
|
