Difference between revisions of "Anatomy of a Model"
(Restored the page before deletion, if someone could give a proper explanation on why this was deleted, that would be great)
m (removed stub tag, definitley not a stub)
|Line 1:||Line 1:|
Latest revision as of 13:01, 1 October 2020
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
To do: confirm: NPC LOS tests are traced against the Render Mesh.
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.
- 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.
- 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
- 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.
- Damage events: - sub-models spawned on "break" event
- $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.
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.
- 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.
To do: ...WIP
To do: develop & move this somewhere more appropriate ?
- prop_static (worldspawn-related models ?)
- prop_detail (sprites &/ models spawned rather than placed)
- prop_physics (vphysics models)
- prop_dynamic (animated models)
- npc_ (ai_animated_models)
- ? (io_animated_models = scripted & triggered?)
- prop_vehicle_ (player driveable vehicles, for APC, see (ai_animated_models))
- Skyboxmodels & Detailmodels
- Static models
- Physics models
- Machine models
- Character models
- Brush models & prefabs
|Basetexture VTF||Description||VMT Commands|
|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_s.vtf||RGB normalmap with Specularmap in alpha||$bumpmap $normalmapalphaenvmapmask|