Skeleton

From Valve Developer Community
Jump to navigation Jump to search
Under construction.png
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. ...

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

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" !

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 point Origin. The Origin is used (1) as this object's center of rotation and (2) to align different objects (it's relative position). Each type of origin represents a local vertex coordinate system within a hierarchy; ultimately they all refer back 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 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). The model's bones are aligned to its ModelOrigin via its Skeleton.
    • BoneOrigin : Studiomodel vertices and attachment points are enveloped to one or more Bones in the model's Skeleton.

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

Retrieved from "https://developer.valvesoftware.com/w/index.php?title=Skeleton&oldid=76157"