Skeleton

From Valve Developer Community
(Redirected from Joint)
Jump to: navigation, search

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 is between Rigid or Jointed Skeletons.

Most models in source have a Rigid Skeleton, which means whilst they may be able to move around, they have no moving parts to articulate. Every Skeleton must have a Rootbone to link the Render model and Collision model geometry with the ModelOrigin. The Rootbone is the linchpin that holds all the model's geometry together. 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.

A Jointed Skeleton has more than one bone, which means it has a joint to articulate. A Jointed Skeleton is a movement hierarchy of "parented" bones with the Rootbone at its apex. Render and Collision model vertices (and attachment points) are also "parented" to a specific bone so when their parentbone is moved, the local vertex geometry moves with it.

In Source, a bone can be articulated - ie caused to move differently to its parentbone - either by an animation sequence or Vphysics forces. 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 from the position and orientation of its parent's attachment point. The $attachment point is part of the parent's geometry, but has its own offset properties, ie its own position and orientation relative to its Origin's position and orientation. 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.
          • attachment : Hooks where another entity's model (eg w_weapons) may attach to this model.
          • childbone : the next named bone in the skeleton hierarchy

Joints, bones & attachments

Bones & Joints
If we think of each named bone as having a ball-end and a socket-end, the ball-end of the bone is called its joint - and is always connected to this bone's parentbone. When this bone moves, it pivots about its joint, so the joint could also be called the bone's local Origin. The socket-end of the bone, which orbits at a fixed distance around the joint, seems to be called the bone. Any childbones, attachments, and/or vertex envelopes "parented" to this bone use the bone (rather than the joint) location and orientation as their origin position. Note that a childbone is "parented" to a parentbone, not a joint.
Bone_names
Joints are referred to by their bone_name, not their parentbone_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.
Difference between Attachments and Joints
A bone is linked to its parentbone via a joint. The joint properties (angles etc) are defined by the bone, not the parent; the child attaches itself to the parent. By contrast, an attachment point is part of the parent's skeleton, and when it connects to an object (eg a weapon), the attachment point defines the (rigid) joint properties (angles, etc); the parent attaches to the child. An attachment point should really be called a constraint. This is why w_weapons are rigged with $bonemerge rather than attachment points ... ?

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. Apex of the skeletal movement hierarchy.
  • 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

  • To do: 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".
  • To do: 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" !


Surface geometry

To do: probably move this section out to its own page Surface geometry or Vertex geometry ?

An object's surface geometry (also known as its envelope or body or hull or skin or mesh or vertex geometry or model geometry) defines the exact shape and size of the spatial volumes that are each completely enclosed by a continuous surface.

  • Two main types of surface geometry with distinctive properties:
    • Rendering geometry ... at the end of the day only the Skin texels are rendered, but the skin hangs on a 3D mesh which is deformed by skeletal animation.
    • Collision geometry ... is invisible in game but defines this object's Solidity to other objects.
      • bbox (bounding box, surrounding bounds, == cbox?, collision hull, movement hull, player hull, npc hull)
      • hbox (hit box) used for bullet hit tests (and local damage modifiers ... crowbar, crossbow, phys-object hit locations?)
      • physbox (physmodel, collisionmodel, ragdoll) is used only for vphysics reactions, including ragdoll motion/animation.

In Source, Surface Geometry data is always defined as a system of Vertices in 3D space. To do: differences between Brush, Model and Sprite.

  • Vertex Location data : (X Y Z) coordintates relative to its parent Origin within the movement hierarchy.
  • Vertex Orientation data : (vertex normalvector) defines its Orientation relative to its adjacent vertices ? ... see Vertex smoothing.
  • Vertex Skin data (UV) coordinates and name of skin.vmt ... see UV map (only used on Rendered surfaces)
  • Vertex Weight data : (float value defaulting to 1.0) ... : see Weightmap (only used on Deformable Rendered surfaces)
  • To do:  a rectangular box is defined by a pair of ("min" and "max") coordinates relative to the origin which represent opposing corners; the other 6 vertex coords are deduced as necessary. A non-rectangular polygonal mesh is a network of triangles connected by their vertices. Because GPU pipelines are optimised to process triangles, rectangular (brush) surfaces are split into two triangles for Rendering.


Non-surface geometry

  • Silhouette geometry (outline or profile)... 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?) (see also sprite)
  • Skeletal geometry ... kinematic movement hierarchies ... attachment is offset from parent's origin & angles. (Rigid / NotRigid)
  • Spatial geometry ... Some Entity Properties use non-vertex geometry:

Vertex Editors