Reference model

From Valve Developer Community
Revision as of 07:58, 20 January 2009 by Brandished (talk | contribs) (comment made no sense without subject)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Reference Model

The Reference Model is the basic template or foundation to which a models properties are added. It comprises the Render Geometry and the Rigged Skeleton, and by implication includes the:

  • Default Pose/Animation (Rigid)
  • Default CollisionProperty (NotSolid)
  • Default Appearance (no Skin or Mesh variants)
  • Default LOD threshhold (lod0)

Animation model : "Reference model" is a term used by animators to distinguish the un-animated model's deformable 3D rendering data from the the actual animated sequence (deformation) data that can be applied to it. This includes the model's basic Rig (Skeleton) and Render Surface (Mesh & Skin). It's like a puppet before the puppeteer gets his hands on it. Without animation or propdata for physics, the reference model is unable to move.

Collision model defines the Solidity of the model. Because Source is a little more than a simple animation renderer, most models also require a separate Physics model for collision detection, etc. Although not Rendered on screen, the Physics model is also a kind of Reference model because it too may be deformed by skeletal animation, and contains its own Rigging and (Rigid) Mesh data. The only difference between the "physics" model and the "render" model is that one is used by the Physics Engine, and the other is used by the Rendering Engine... so Physics or Collision models don't have Skins. Collision models are deformed by skeletal animation (ragdolls) but are generally not altered for LOD or visual variations.

LOD models : are "cheaper" versions of the render model - using a simplified Mesh, Skin and/or Skeletal structure for rendering at a distance where the loss of detail is not visible. LOD models are deformed by the same animations as the Reference model.

Variant models visual variations such as optional Skins or optional sub-meshes, are an efficient way to introduce variety or runtime alterations to the render model. Variant models are deformed by the same animations, and are subject to the same LOD version considerations as the Reference model.

So the "Reference model"'s properties add up to an un-animated, not solid, lod_0, single-skinned and single-meshed model.

Compiling a Model

probable destination for this section is an introduction to Compiling models for Source. 3rd party MDL compilers often provide a different GUI to the QC file than StudioMDL, so a checklist of "things you should already have done" would be relevant to all MDL compiler docs. It includes model anatomy/glossary definitions for #REDIRECTs ?


  • The Reference.smd is traditionally named "modelname_ref.smd".
  • It defines the model's Reference Skeleton and its "default" 3D Rendering Geometry:
    • The Reference Skeleton is the key for all of the model's geometry: vertex data for the render mesh, sub meshes, collisionmodel, hitboxset, attachments, animations, gibs, etc. all reference the skeleton.
    • The Reference Mesh is the "main body" (as opposed to $bodygroup sub-meshes) of the Render Model. The Reference Mesh's Skinning data also defines the filename(s) of the model's Default Skin(s).
  • Notably, the reference.smd does not contain the model's
    • Physics geometry (collision & hitboxes)
    • Skin files
    • LOD meshes & skins
    • Optional meshes & skins
    • Animations
    • Game settings (QC /StudioMDL parameters)
Tip.png Tip: See SMD file format for exactly how this data is stored in each "Studio Model Data" file.


  • "submeshname_sub1.smd", "modelname_ref_sub1.smd" or "modelname_hat_ref.smd".
  • defines a rendered submesh which may be added to the default mesh via $bodygroups. Submeshes cannot be included in the reference.smd.
  • includes: ref-skeleton, defines: mesh (ie: skinname, uvmap, envelope & weightmap data)
  • submesh.smd must be enveloped to the ref-skeleton ...


  • "lod1_modelname_ref.smd", "lod1_modelname_sub1.smd".
  • LOD Models are simplified versions of renderable meshes. each requires its own smd, and are compiled into VVD/VTX of main model via the $lod configuration.
  • the convention is to prefix the modelname "lod#_". The ref and sub.smds are effectively lod0_modelname_ref.smd, lod0_modelname_sub.smd,
  • includes: ref-skeleton, defines: mesh geometry (ie: coords, smoothing, skinname, uvmap, envelope & weightmap data)


  • The Physics.smd is traditionally named "bodymeshname_phy.smd". _physmodel.smd or _physbox.smd
  • defines the hull geometry, envelope and smoothing group data for the collisionmodel. incl ref-skeleton.
  • includes the ref-skeleton and defines: hull geometry(s) (ie: vertex coords, normals, & envelope data)
    • Because hulls are rigid and not rendered, they don't use any UVmap or weightmap data.
    • Each hull must be a convex shape ie somewhere between a sphere and a box. Overlapping/intersecting multiple hulls are used to create ($concave) models.
    • Rigid collisionmodels ($collisionmodel) envelope all hulls to the same bone.
    • Jointed collisionmodels ($collisionjoints) envelope some hulls to different bones.


  • Confirm:not compiled by StudioMDL, but opened in text editor for hitbox vertex coordinates?
  • not rendered, simple collision = simple box geometry


  • Each Animation.smd is traditionally named "sequencename.smd".
  • includes the ref-skeleton and defines a keyframed sequence of skeletal poses.
  • $sequence "idle" "modelname_idle.smd"
  • $sequence "ragdoll" "ragdoll.smd" ACT_DIERAGDOLL 1 fps 30.00
  • $includemodel includes an AnimationLibrary.mdl