Skeleton

This page is actively undergoing a major edit.
As a courtesy, please do not edit this while this message is displayed.
If this page has not been edited for at least several hours to a few days, please remove this template. This message is intended to help reduce edit conflicts; please remove it between editing sessions to allow others to edit the page.

The person who added this notice will be listed in its edit history should you wish to contact them.

A model's Skeleton is sometimes called the model's Rig or Bonetree. Every model in Source must have a Skeleton, even if it is just a single, invisible "bone". A Model's Skeleton is the reference framework for all of the model's vertex geometry, and it is the Skeleton's "rootbone" that locates the model's geometry to the Model Entity's position and orientation in the World.

A Model's Rendered Skin is projected over the Mesh which envelopes the Skeleton.

Every Skeleton must have:

• a rootbone.

shortcut

Skeleton Types

By far the most important distinction between types of Skeleton is whether they are Rigid or Jointed.

Rigid Skeleton

Most models in source have Rigid Skeletons, which means they may change position and orientation, but they have no moving parts. Happily, a Rigid Skeleton is so simple that most SMD compilers will include one by default, so the modeller doesn't have to do anything about it.

Jointed Skeleton

Only when the Skeleton has more than one bone can it have a joint to articulate. In Source, a joint can be caused to bend either by an animation sequence or by different Vphysics forces being applied to the respective bones. Both systems (currently) cannot be applied to a skeleton at the same time. Sequences are is used for active, purposeful entities (eg prop_dynamic) whereas Vphysics is used for articulation of passive, floppy entities (eg prop_ragdoll). The most sophisticated skeletons belong to Human NPC models, who all use the ValveBiped skeleton and the copious animation libraries built for it. Much simpler jointed skeletons can be found in the numerous "machine" models, which only require one extra bone for each moving part.

Movement hierarchy

Source's movement hierarchy system is used to attach different entities to one another, but the same logic can be used to understand how Skeletal bones are linked together.

By default, each object constrained in a movement hierarchy inherits its position and orientation form the position and orientation of its parent's attachment point. The $attachment point is part of the parent's geometry, usually part of its Skeleton. When the child-object attaches, its Origin and Angles are aligned to the position and orientation defined by the $attachment point.

If the parent-object moves the attached child-object moves (parallel) with it. If the parent object rotates (about its own origin), the child-object will orbit the parent's origin.

• WorldOrigin [worldspawn]
  • (Vehicle) WorldPosition : all entities' position and orientation are relative to WorldOrigin.
    • (Seat) Parent Entity Attachment point is offset from its WorldPosition
      • (NPC) Child Entity Model offset [$origin]
        • (Pelvis) Skeleton Root_bone_end offset
          • (Chest) Joint_bone1_end offset
            • (Torch) Attachment point offset
              • (Torchbeam) Sprite
            • (Arm) Joint_bone2_end offset
              • (Sleeve) Mesh vertex offset
              • (Muscle) Physbox vertex offset
              • (Hand) Attachment point offset
                • (Shotgun) Sub-model Root_bone_end offset
                  • (Muzzleflash) Sprite

• Entity : the entity's position and orientation in the World are "inherited" by the
  • Model Origin : is the reference point for ... offset with $origin ...?
    • rootbone : is any bone "parented" (directly) to the Origin. Usually only one root bone per model... offset with $root
      • bone_joint : where this bone connects to its parentbone
      • bone_name (see also SMD#nodes)
      • bone_attach : Has position and orientation properties, = the "origin" for this bone's children :
        • 'mesh : Render model vertices are enveloped to one or (weightmapped to) more than one bone.
        • 'physbox : Collision model vertices are enveloped to one bone.
        • sub-model : Detachable sub-models (eg w_weapons) are attached to one bone_attach.
          Todo: would it be better to say each collision convex is attached to skeleton, rather than enveloped to it ? ie enveloping implies weightmapping ?
        • childbone : the next named bone in the skeleton hierarchy

• nb sub-models include "rigged" weapons (w_weapon, $bonemerge) and movement hierarchy children ...
• LOD skeleton : bonetreecollapse, replacebone,
• IK chains

Joint & bone_names

• Intuitively, we think of each named bone as having two ends. The "head" of the bone is called its joint, and is always the end that connects with its parentbone. The other end is offset from the joint and seems to be called the "bone" or "bone-end". Because every joint is (by default) a ball-joint, the bone-end position can be described by the bone's radius (length) and spherical angle from the joint. (In code it's somewhat different!) The bone-end's orientation may also include rotation (about it's long axis).
• Envelope or attachment offsets (coordinates) refer to the bone-end coordinates rather than the bone-joint.
• Joints are referred to by the joint's bone_name; eg ankle = foot_bone, knee = shin_bone, etc. Sometimes bones are named after the joint, eg foot = ankle_bone, shin = knee_bone. However this can cause confusion: something attached to the knee_bone will be offset from the ankle joint rather than the knee joint.

A skeleton is comprised of "chains" of bones, joints, effectors, and a root. Some good things to know:

• Root: Where your skeleton starts. Moving the root moves the skeleton as one unit.
• Joint: Joins two bones, and is where bending and IK occur.
• Bone: This is the principle object in the skeleton and is what the mesh will be attached to.
• Effector: These move a bone system around. The end point of a bone chain.

Root

Root or rootbone is a special kind of bone. It is parented to the EntityOrigin, and therefore aligns all of the skelton's geometry to the Entity's World position and orientation.

A "default" skeleton has nothing but a rootbone, with zero length, all vertices enveloped to it are aligned to the Origin.

// eg: a "default" SMD skeleton :
version 1
nodes
  0 "root_bone" -1
end
skeleton
time 0
  0 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000   
end

• To offset part or all of the model from the Entity's position on the map, see $origin and $root.

Rigging

• Todo: clarify:
  rigged, rigging, rig ... if "rig" = the whole skinned, enveloped, jointed, etc model, ready and waiting for animations to be applied, then "rigged" means animation-ready or complete, and "rigging" is the process of attaching & tweaking the relationships (uvmap, weightmap, jointconstraints, etc) between all the elements. On the other hand, "rigging" might refer specifically to configuring all the bone properties for a given skeleton - jointconstraints, attachments, IKrules, etc - so "rig" = a NotRigid skeleton, and "rigged" still means "animation-ready".

• Todo: clarify:
  deformer = a bone, deforms the mesh, so the "deformation" would be applied to the mesh & skin, ... however if deformation = a bone movement, either animation or (ragdoll) vphysics applied to the bone, then bone = "deformee" !

• $weightlist defines the skeleton's bone weights, used for "cross-fading" when blend animations are combined.
• $jointconstraints are applied to ragdolls and do not affect animation (?).
• $ikchains are used by animation sequences as a kind of collision detection.
• $attachments are used by sub-models such as weapons.
  • See Rigging a weapon model and Attachments for attaching detachable sub-models to the Skeleton.
  • See Bodygroups for attaching additional sub-meshes to the Skeleton.
    • See Enveloping and Weightmapping for attaching a deformable Mesh to the skeleton.
      • See Skinning and UV mapping for attaching a Skin to the Mesh.

Vertex geometry

Todo: probably move this section out to its own page ?

An object's vertex geometry (also known as its envelope or simply geometry) defines the exact shape of the spatial volume enclosed by its surface. Vertex Geometry Data always includes 3D Vertex coordinates (XYZ axes) and sometimes Vertex normal vectors, UV map coordinates and Weight map values.

• Each Vertex coordinate (X Y Z) is defined as an offset from a specific, local Origin point. Each object's Origin represents a local coordinate system within a hierarchy; having its own position and orientation relative to its parent. Each objects Origin is used (1) to align different objects (ie relative position) and (2) as this object's center of rotation. Ultimately all local coordinate systems are translated into a position and orientation relative to the WorldOrigin .

• WorldOrigin : Often called the map origin, it is the worldspawn entity's position in the World (0,0,0). All World Brushes are part of the worldspawn entity, so their vertex coordinates are relative to the WorldOrigin.
• EntityOrigin : A Point Entity's WorldPosition or placementOrigin is its geographical offset from the WorldOrigin. Every Point entity also has an autocentric or geometric origin, which is aligned to its WorldPosition. Some Brush entities also require a geometric origin. As a brush is always convex, this is easily, automatically calculated. (see Template:Kv_origin)
• ModelOrigin : Each Studiomodel also has its own reference Origin, which is aligned to the EntityOrigin. (see $origin, $autocenter). The model's bones are aligned to its ModelOrigin via its Skeleton.
• BoneOrigin : Studiomodel vertex geometry and attachment points are enveloped to one or more Bones. Each bone has a place in the model's Skeletal movement hierarchy (or bonetree). The root bone is at the apex of the hierarchy, and connects to the ModelOrigin.

• Each Vertex Normal (vector)... see Vertex smoothing
• Each Vertex Skin (UV)... see UV map
• Each Vertex Weight (scale) ... : see Weightmap

Properties of vertex geometry

Objects use vertex geometry to define several spatial properties:

• Rendered geometry ... ie skinned vertex geometry (Opaque / Translucent / Invisible)
• Collision geometry ... bbox, cbox, hbox, or NotSolid ... cbox/physbox can be collision model or hull... (Solid / NotSolid)
• Skeletal geometry ... movement hierarchies ... attachment is offset from parent's origin & angles. (Rigid / NotRigid)
• Profile geometry ... non-collision raytrace tests; ie. Shadows & LOS. Usually derived automatically from Render model at runtime, but can use other geometry for greater efficiency. ($shadowlod, etc?)

Non-vertex geometry

• Some Entity Properties use non-vertex geometry:
  • sphere : eg light - radius = distance from EntityOrigin (note "falloff")
  • cone : eg light_spot - angles = direction, FOV = cone arc, ? = distance from EntityOrigin (note "falloff")
    • NPC viewcone (FOV & default distance = 2048 units)
  • PVS : potentially visible set (visleafs)
  • PAS : potentially audible set (visleafs?)

Vertex Editors

• Brush Vertices : Hammer Vertex Tool
• Mesh Vertices : (SMD#triangles), model editor
• Skin Vertices : see UV map
• Hull Vertices : C++ NPC_Hull, Player Hull
• Hitbox Vertices : QC $hbox
• Bounding box Vertices : QC $bbox