Anatomy of a Model

Model Properties/Features

Render geometry

Ultimately only the Skin(s) of a model are actually rendered on screen, but they are deformed (into 3D) by the Mesh which in turn may be deformed by Skeletal animation. A model's Meshes and Skins particularly are optimised for the Rendering Engine/Pipeline.

• Render model /Mesh : (aka Renderbox, Render geometry) includes Rendered Geometry: 3D Vertices, $origin, UV map)
  • Mesh options : $bodygroups allow optional add-on sub-meshes to be included in the Render model.

• Skin : (aka Texture, Material, Surface Properties) VMT (specifies VTFs & $surfaceprops)
  • Skin options: $texturegroup allows alternate skins
• Custom Gibset : $collisiontext, propdata - sub-models spawned on "break" event.
• Attached Models : Attachment points, Movement hierarchy

Todo: confirm: NPC LOS tests are traced against the Render Mesh.

Collision geometry

There are quite a few model components used exclusively for physics collision interactions

• Bounding box : used for "early-out" proximity tests, including LOS-traces, Render-traces, Bullet-traces, and Movement Collision.
  • $bbox
• Collision model: (aka Physbox, Collision Hull, Physics Model, Collision Mesh) used for Movement Collision tests
  • Rigid collision model $collisionmodel, $concave (vphysics $mass & $centerofmass)
  • Jointed collision model (ragdoll) $collisionjoints (vphysics $mass & $centerofmass for each bone-hull)
  • Entity Collision box NPC Hull, Player Hull, (/ Weapon Hull? eg Rockets, SMG grenade, Crossbow bolt, etc)
  • $cbox ?
• Hit box(es) : used for Bullet-trace hit-tests.
  • $hboxset, $hbox - if none is specified, bbox is used instead?
  • hboxes are part of damage system. Do they also block bullets? ... hit event triggers: sound, decal, vphys push?, damage
• Center of Mass : used for calculating linear & angular motion from vphys forces.
  • $origin, $mass,

Collision model is used animate the skeleton in response to vphysics collision forces. For a rigid model, this limited to displacing and/or rotating the model about its center of mass (by default, its $origin ? ... center of mass = center of rotation)

Skeletal Animation System

When a bone is moved any hitbox and mesh vertices "parented" to it moves with it. Unlike hitboxes, mesh vertices may be "parented" to more than one bone. When the parent bones move apart, the "joint mesh" is stretched, when the joint is closed, the mesh compresses. The Skeleton deforms the Mesh which deforms the Rendered Skin.

The skeleton can be articulated by either a prescribed (aka canned or keyframe) kinematic sequence applied directly to the bone positions, or by runtime-calculated kinetic (aka ragdoll or vphysics) forces (including jointconstraints) acting through the collision model, in which case we can say that the collision model articulates the Skeleton which then deforms the mesh which deforms the rendered Skin in the normal way. Without the collision model as a deformer, vphysics forces have no effect on the model's skeleton or position. The collision model cannot be deformed in any way by kinematic sequences, they belong to different movement systems. The entity dictates which system is applied to the model, whether it is moved by vphysics or kinematics.

Physics SMD therefore is a special kind of animation SMD because both apply skeletal animation to the Reference SMD. Physics SMD is a vphysics rig which is used to control skeletal animation for ragdoll physics. Only the reference SMD and Skin are moved by the skeleton.

• FK : forward kinematic = active, no collision adaptation
• IK : inverse kinematic = active, limited collision adaptation - see $ikchain
• RP : ragdoll physics = passive, full collision reactions & vphysics interaction.

• Vphysics Constraints :
  • $collisionjoints: ragdoll.smd = jointed collision model convex bone-hulls & skeleton
  • Note:A joint is where a bone attaches to its parent bone. All bones (except the root bone) must have only one joint, so the "bonename" is also used to specify its joint. bone's position is offset from joint
  • Phys entity constraints and func physbox

• Keyframe Constraints : eg func_door motion ?
  • Inverse Kinetmatics : $ikchain: used for "collision" modifiers to $sequences
  • Bone weights : $weightlist: Rigging? can be "modified" by other properties, eg iklock ... blend anims
    • Keyframe Animation controllers $sequence, Activities, Events
  • func brush-entity constraints/motions (func_rotating, func_conveyor, etc)

Entity Alignment System

• $origin keys/offsets all of the Model's Vertex Coordinates (mesh, physbox, animations, etc) to the Entity's World Position.
  • $root = top of bonetree
    • $attachment : Attached Models : Attachment points, Movement hierarchy
• Damage events: - sub-models spawned on "break" event
  • Gibs : $collisiontext, propdata
  • Ragdoll
  • Explode

Modelling Glossary

Sub-models

• $collisionmodel or $collisionjoints specifies a very important sub-model which is used for vphysics animation. Almost all World Models must have a 3D "physics shadow" of their Mesh. The collision model's geometry, smoothing group and envelope data are defined in the Physics.smd which is usually a pared-down version of the Default Mesh. The collision model is Rigged (if necessary) using the QC $collisionjoints configuration, and compiled to the model's PHY file. A Jointed Collision Model causes skeletal articulation resulting only from vphysics forces (ie passive or "Ragdoll" animation). Models under active or "Dynamic" animation use an Entity-specific Collision Hull and the IK system for collision detection.

• $attachment points allow many world prop models, such as the character's "current weapon", to be constrained to a specific bone or bones on the main model. These sub-models will move relative to the bone they are attached to, but will not deform like the Meshes. They are essentially prop-constraints used for skeletal or movement hierarchy animation.

• $bonemerge submodels include w_weapons enveloped to reference skeleton.

• $bodygroup submodels include clothing enveloped to reference skeleton.

• $collisiontext specifies a list of Custom gib.mdls that will replace the main model in game when it "breaks" (see propdata). Gibs are physics-prop models in their own right.

Collision Geometry

Boundingbox

The Bounding Box is a simple, convex, rectangular box that encloses all the Solid and Visible parts of a model; ie. its Collision Hull, Hitboxes, etc.

• Any geometry outside the Bounding Box will be regarded as NotSolid to Bullets, LOS and Solid Objects.
• It is used only for crude proximity tests; so that no sophisticated (expensive) collision tests need to be performed against objects which do not enter the Bounding Box.
• By default, the Boundingbox will be derived from the Collision Hull, which may be too small. Use the QC command $bbox to correct this.
• See also the Surrounding Bounds section CollisionProperty article.
• See also Bounding box.

Collision Hull

• Every Solid Entity has a Collision Hull of some kind. It may be
  • a Rigid Hull (see $collisionmodel),
  • a Ragdoll (see $collisionjoints),
  • or a crude but efficient NPC Hull.
  • (A Brush's Collision Hull is defined simply by its Surface Geometry)
• Sometimes called a Physbox or Movement Hull, it is used for vphysics collisions between one or more moving objects; even Static Solid objects can collide with Moving Solid objects. See CollisionProperty.

Hit box

Todo: ...WIP

• $hboxset, $hbox

Model Types

Todo: develop & move this somewhere more appropriate ?

• prop static (worldspawn-related models ?)
  • prop detail (sprites &/ models spawned rather than placed)
• prop physics (vphysics models)
  • weapon_ (worldmodel (vphysics_model), + viewmodel)
  • item_ (worldmodel (vphysics_model))
  • prop ragdoll (ragdoll models)
  • model size/weight: player_pick-up, player_push, physgun_pickup, physgun_push ?
• prop dynamic (animated models)
  • npc_ (ai_animated_models)
  •  ? (io_animated_models = scripted & triggered?)
• prop_vehicle_ (player driveable vehicles, for APC, see (ai_animated_models))

• Studiomodels
• Viewmodels
• Skyboxmodels & Detailmodels
• Worldmodels
  • Static models
  • Physics models
  • Machine models
  • Character models
• Brush models & prefabs

VTF map

Todo: move this somewhere more appropriate, Texture perhaps?

VTF Textures (via VMT Skin)

Basetexture VTF	Description	VMT Commands
modelname_clr.vtf	RGB colormap	$basetexture
modelname_clr_t.vtf	RGB colormap with Opacitymap in alpha	$basetexture $translucent
modelname_clr_s.vtf	RGB colormap with Specularmap in alpha	$basetexture $basealphaenvmapmask
modelname_clr_l.vtf	RGB colormap with Luminositymap in alpha	$basetexture $selfillum
modelname_clr_h.vtf	RGB colormap with Heightmap in alpha	(storage only : used to edit normalmap)
Bumpmap VTF	Description	VMT Commands
modelname_nrm.vtf	RGB normalmap	$bumpmap
modelname_nrm_s.vtf	RGB normalmap with Specularmap in alpha	$bumpmap $normalmapalphaenvmapmask

See also

• Dimensions