Anatomy of a Model

From Valve Developer Community
Jump to: navigation, search


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.
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.
  • Collision model: (aka Physbox, Collision Hull, Physics Model, Collision Mesh) used for Movement Collision tests
  • 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.

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.

  • Vphysics Constraints :
    • $collisionjoints: ragdoll.smd = jointed collision model convex bone-hulls & skeleton
    • Note.pngNote: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
    • func brush-entity constraints/motions (func_rotating, func_conveyor, etc)

Entity Alignment System

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.

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
  • 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

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