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 the may not articulate - none of their 'internal' geometry can change. Happily, a Rigid Skeleton is so simple and easy to configure automatically that it is often overlooked. ....

• Rootbone ... $root ... $origin
• prop_static, prop_physics, item, w_weapon,

// eg: a "rigid" 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

• see SMD file format for further info.

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

Bonetree

• 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.
      • 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 (or attached?) 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.

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