1998 Gamasutra Article Companion
This material is copyright 1998 Darwin 3D, LLC. All rights reserved.
Who doesn't love a game that incorporates cool real-time 3D characters? You do, right?
Everyone wants the most amazing characters possible for their game. So why doesn't
everyone have them? Because, it's not that easy. There are so many options available
for the artist and programmer that it can be truly overwhelming. On that account, here is
a guide to help you plow through these choices.
Now as far as which decisions you should make, well that really is up to your production
team. I assure you that while the information included is not all-encompassing, you will
be able to make well-educated decisions. There is no definitive "right" answer because
so much depends upon budget, time, manpower, target platform etc. But, do allow me to
step on my soapbox for my two cent(ence)s worth. Early planning must be done! These
decisions need to be carried through the entire production because once you head down
any of the paths, the time and money spent to change is most likely just not worth it.
(Yeah, so I do preach a bit.)
Mesh construction techniques:
The first and largest fork in the road comes early on. How am I going to handle the
character mesh? While there are many ways of designing 3D real-time character
engines, the character meshes themselves are usually one of two types:
- a hierarchy of separate objects
- single mesh characters
Hierarchy of Separate objects
Characters of this type have a separate object for each body part in the character.
These separate objects are connected together in some form of hierarchy. Then,
by applying rotations and translations to each body part, you can create fluid
motion. You see this type of character in many games, but some classic examples
of this techique include Virtua Fighter and Tomb Raider.
Frame 1: A character created from separate objects
Benefits of this method:
- Characters that are created from a hierarchy of separate objects are very
- You only need to store a transformation for each object and the vertex
information once, thus the animation file is very small.
- By having the character in a hierarchy, it is fairly easy to create new
animations. If your engine supports an Inverse Kinematic (IK) or Dynamic
system, you can actually generate new animations on the fly. This is the
key benefit of creating your characters this way.
Drawbacks of this method:
- Since the actual position of each vertex in the model is determined by
the hierarchy, you need to do some extra work to get the mesh to the
screen. Each object in the mesh must be transformed by the complete
hierarchy above it. This makes for quite a bit more math per vertex. For
example, if your hierarchy looks like figure 2, the mesh of the left hand must
be transformed by the hips, chest, chest2, left collar, left upper arm, left
lower arm, and finally the left hand.
- Where the objects in the character connect, you get gaps. Since the
objects in the character are separate, you need to consider how they go
together. By clever modeling, you can hide these seams, but this is not always
possible. You may notice that many characters of this type wear armor or
clothing that hides these seams.
Figure 2: A sample character hierarchy
Single Mesh Characters
A single mesh character is not made of separate parts. As the name implies, the
character is one single mesh. The character is animated by changing the position
of the vertices in the mesh directly. This can be done by having a table of
positions or offsets for each frame or just by switching meshes as the character
animates. Quake characters are the classic single mesh characters.
(PICTURE OF SINGLE MESH CHARACTER)
Frame 1: A character created from a single mesh
Benefits of this method:
- Single mesh characters look better, especially when modeled with low
polygons counts. There are no seams in the character and the mesh
- The characters are fast. Since there is no need to transform each vertex
through a hierarchy, there is a lot less math required to display these
Drawbacks of this method:
- The characters are not as adaptable. Since the character must be
animated by an external system, it is not as easy to come up with
- The animation files are larger. Since you need to store a position or
at least a delta for every vertex for every frame, much more data
must be stored. While you can compress this a great deal, it is a
limiting factor in the length of the animation.
"Okay, but what is lurking further along the path?" you say. As you have journeyed
thus far and acquired the foundation, you are ready to embark with me to a greater horizen; the future.
Could it be possible to incorporate the flexibility of a hierarchy of objects with the
good looks of a single mesh? As always, we want more! And much to our delight
and fancy, we can have more. With 3D hardware becoming more common and
ripping processors' speed, the sky is the limit (well, at least until we think of something
else we want). Thus we get:
Deformation and realtime skinning of skeletons
To demonstrate, let us take a look at a character's arm...
|Separate objects in a hierarchy look like this:|
(Keep in mind the gap has been exaggerated to make it clear.)
|The simplest method to make this
arm look better would be to cover the gap by connecting vertices at the end
with a few extra polygons.|
While this looks better, it tends to stretch badly and look a bit deformed as
the arm moves.
|The real key to making things look
better is to add a series of vertices that are influenced by the rotation of both
bones. If we add a single set of vertices and weight them so they are
influenced 50/50 between the two bones, the look is improved.|
|This helps with the stretching problem,
but the pinching at the joint is still pretty noticable. By allowing the bones to
influence the end vertices of the objects, the character looks much better. In
this image, the vertices are weighted 33%/66%, 50%/50%, and 66%/33%,
around the joint.
Level of detail (LOD) management and realtime tesselationa. Collision detection
Physical engine properties
b. Realtime inverse kinematics (IK)
c. Dynamics including physical interaction with the world (e.g. gravity)