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.

Advantage:

• 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 increases.
• 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 be present.
• Animation flexibility. For involuntary movements (response to blast, being hit), an infinitely large set of postures is possible.
• 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 removed.
• 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.

Disadvantage:

• 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 animation anymore.
• Copyright issues with recombining proprietary (id) components (collage legaislation).

Implementation:

The is a bulk of literature and sample implementations on this. The statements below just sketch certain aspects and alternatives.

• 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 the client.
• 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 simplify implementation
• 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 the current 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 (very restrictive).

Related Proposals

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 bk@gamers.org.