In Source, the term "Mesh" is generally used to refer to the Rendering geometry as opposed to the Collision geometry of a model. It is sometimes referred to as the envelope or skin. The Rendered Skin is projected over the Mesh which envelopes the Skeleton.
Each renderable model requires at least one mesh (the body mesh) but may also have additional sub-meshes. Each mesh may also have a number of versions optimised for LOD-substitution.
trianglesblock of a "Studio Model Data" file.
- The "default" body mesh is rendered unless substituted by a specific LOD mesh. Sometimes it is called the Reference mesh because it is defined in the model's Reference.smd and compiled via the $body or $model QC command.
- Optional Sub-meshes can be switched on and off at runtime. Like the body mesh, they are enveloped to this model's Skeleton, and will deform (stretch and flex) as if part of the Default mesh. Specific pieces of clothing are good candidates for switchable sub-meshes; eg different types of body armor or headgear. By contrast Sub-models (eg weapons) can be attached to specific $attachment points on this skeleton, but they remain enveloped to their own skeleton; their geometry will be moved by this skeleton but will not be deformed by it.
- The $bodygroup configuration allows any number of sub-meshes (SMDs) to be added to the Default mesh. By setting up multiple $bodygroups sub-mesh switching can be triggered by (code-level) events.
- Whereas "Alternative Skins" replace the Default Skin, Optional Meshes do not replace the Default Mesh.
- Sub-meshes do not affect the model's collision model.
- (To do: $model's face mesh for facial animation ?)
- Sub-meshes must be exported in separate .smd files to the body mesh, but they must be enveloped to the same skeleton so they align correctly with the model (see $bonemerge).
- Source's LOD system allows a "cheaper" (simplified) version of the Default mesh(es) to be rendered at a distance where the loss of "expensive" detail is not noticeable to the Viewer. Any number of replacement LOD_meshes can be made from pared-down Default meshes, and compiling the lod.SMDs via the $lod configuration. A Default mesh is used when no LOD mesh is active; we could say it amounts to an "lod0" Mesh. See Creating LOD Models.
- A Model is a functional set of components, including whatever Skin, Mesh, Skeleton, Collision geometry, associated Animations, Sounds, Physics properties, etc. data it needs to fulfil a given role. Often a particular SMD or Studiomodel file is referred to as a model to distinguish it from an animation or a brush; for example the "reference model" usually refers to the reference.smd, whereas all "$collisionmodel" data (including the physbox.smd data and other parameters) is compiled to the PHY file. Studiomodel is only ever used to refer to the fully compiled model used in the Source Engine, Hammer, HLMV, etc. A particular Studiomodel is usually specified by modelname.mdl, because the MDL file acts as an index of the other data files a Studiomodel needs in order to function (ie its MDL, PHY, VVD, VTX Geometry data and VMT Skins).
- In Source, the term Collision Hull is preferred to Collision Mesh because every piece of 3D collision geometry must be a Convex Hull, whether its vertex geometry happens to be defined (in uncompiled code) by a simple BoundingBox Constructor or the SMD triangles format. In order to maintain its convexity, the Hull's vertex geometry must also be Rigid, ie not deformable. A Concave Collision Model consists of rigid system of (overlapping) rigid Hulls, a Jointed Collision Model consists of a flexible system of rigid Hulls which are displaced but not deformed by skeletal articulation. So while a "Collision Hull" is always a rigid convex hull a "Rendered Mesh" is always a deformable and indentable triangle mesh. Even rectangular world brushes are "split" into triangles before they are rendered (because GPU pipelines are optimised to process triangles).