Skeletal Animation/Composite Entities
Q3 models with much higher polygon count should (probably
will) not be done as fixed keyframes. Instead a
skeletal animation/inverse kinematics should be used,
as already implemented within the Q2 engine (Valve,
"Half Life"). Generalizes into mechanism for
attachment, inventory, visual weapons.
- Ease of design. Monster Building would became
an issue of plugging components into a
skeleton. Frames would be automatically
generated. This feature would greatly speed
authoring of the actual game, and also
greatly enhance the value of existent models,
which could be re-utilzed without great
amounts of time spent modeling new poses.
It allows for combinatorially large variation
on a base set.
- Disk space savings. Without preculaculated
frames as large vertex pools, requirements
go down even if per model polygon count
- Memory savings. If IK can be handled on the
fly, the same savings as on disk occur
in memory, as only two frames (the source
skeleton, and the current one) need to
- Animation flexibility. For involuntary
movements (response to blast, being hit),
an infinitely large set of postures is
- A proper
walking IK could actually resolve some
of the "moonwalking" artifacts at varying
speeds currently observed.
- New game modes are possible allowing for
composition and decomposition at runtime.
A Medic could collect gibs to assemble a
monster. Players could scavenge body ports
to recover faster. Monster could sneak in
as a pack, and attack as a composite.
- Homebrew model editing could be done on
three levels: re-combining existing components,
adding new components to existing skeletons,
and create new skeletons including components.
- A clean design removes all differences between
event, temporary, and permanent entities except
for the necessity of being allocated a slot in
the edict table for the latter. If the Game DLL
gets means to create network packets for
permanent entities the same way it does for
temporary entities, further redundancy could be
- Implementation of visible weapons, flags
carried, facehuggers will all be done
by applying the same mechanism.
- If a hierarchy of bounding boxes is used,
body specific damage could be implemented
in a straightforward way.
- custom skeletons would introduce a level
between custom skins and custom models.
- a separation of view and model orientation,
especially intuitive for use of VR helmets,
but also required by "mech-like" game mods,
would be visible to other observers, as
a head/upper torso could now rotate
while the lower body keeps the current
orientation while walking.
- This furthers the trend to "less, but more detailed
enemies" situations in game (DOOM vs. Quake).
Several entities (head, torso, leg) are used to
represent a single NPC/player.
- Increase of network traffic if IK/dynamics is
not handled client side, or interpolated between
server-side generated updates.
- The "moonwlaking" artifacts could get worse as the
artist does not have full control over the
- Copyright issues with recombining proprietary
(id) components (collage legaislation).
The is a bulk of literature and sample implementations
on this. The statements below just sketch certain
aspects and alternatives.
The implementation of skeletal animation is closely
related to the various entity types as used in Q2.
The current "reference by index" to another entity/edict
used in temp_entity_t/svc_temp_entity
should generalized. Further redundancy bc event_entity_t
could also be resolved (from the DLL sources:
all muzzle flashes really should be converted to events...).
There should be a single mechanism to implement skeletal
animation, attachments, gibbing, spawning with offsets,
item picking and dropping. In fact, the inventory should
be based on the same concept of "objects being attached
to objects", some of them "inside parent" instead of
attached to a joint.
- Some definitions:
- Components are separate entities.
- Joints connect components to each other.
They set constraints, parameters for IK/dynamics,
and can be destroyed or set at runtime.
- Roots are components that are visible to
- generic "skeletons" could be used to simplify,
e.g. a head+upper body+lower body+legs+arms
structure. This would restrict use of
other structures (spider, squid), but might
- if on-the-fly rendering is too expensive,
keyframes could be pre-calculated and
cached at loading the game, preserving the
editing freedom and disk space savings.
- regular IK usually does not allow for closed
loops in kinematic chains, only for tree-like
structures. This might have to be enforced.
- skeletons/articulated bodies could be used even with
Axis-Aligned Bounding Box collision detection.
With increasing CPU power, migration to sets
of AABB, OOBB's, sets of boundings spheres or
other alternatives might be easier.
- Checks within the tree/chain could be avoided
only if the IK parameters are set properly
This proposal was revised to include the New Model Format
and Model Skeleton ones. Contributors were, among
others, Dirus, Peter Hanley, Earthlink Mail, Nathan Lord,
and Jan Javorsek.
Submitted 980407, revised 980420, revised 980421
comments to email@example.com.