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 NotRigid.

Rigid Skeleton

Most models in source have Rigid Skeletons, which means they may change position and orientation, but they may not "bend" in any way and 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.

NotRigid Skeleton

only when the Skeleton has more than one bone can it have a joint to articulate. ...

• prop_ragdoll : passive/physics ... $collisionjoints
• prop_dynamic : active/animated ... see skeletal animation
  • machine model (wheeled vehicle ?)
  • character model (rigid npc: npc_rollermine,...)
  • viewmodel

Movement hierarchy

By default, each object inherits its Origin and Angles (position and orientation) from its parent. An object's geometry may include an attachment point, offset from the object's origin. For the sake of brevity, we will say that the child's origin inherits its position and orientation from it's parent's attachment point. If each object's attachment is offset from its origin,

Each object's Origin is its center of rotation and its position relative to the World 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 and Collision 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) 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.
• $joincontstraints are applied to ragdolls and do not affect animation (?).
• $ikcahins 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 ?

• Vertex Geometry = 3D coordinates (XYZ axes) and sometimes vertex Normal vectors.
  • Vertex coordinates are measured on XYZ axes from either the WorldOrigin or an EntityOrigin.
    • WorldOrigin= worldspawn entity's position which is always the map origin (0,0)
    • EntityOrigin = the WorldPosition of that entity.
    • BoneOrigin = Studiomodel vertices are enveloped to one or more Bones in the model's Skeleton.
  • Vertex Normals are used to imply a Surface Normal as if the vertex is the center of a surface rather than a vertex. This creates a kind of pseudo-subdivision surface, used by the Smoothing (Shader?).
• Origin : Every game entity that can move has an origin. Every game entity that has non-brush geometry has an origin. All brush vertex geometry is related to the map origin = worldspawn entity.

• Studiomodel geometry (vertex $origin = entity WorldPosition & angles
• Brush geometry (vertex origin = worldspawn entity)
• non-vertex geometry (entities)
  • sphere : eg light - radius = range/distance
  • cone : eg light_spot - angles = direction, FOV = cone arc, ? = range/distance
    • NPC viewcone