nyuuzyou/wikis huggingface dataset:
$hbox

It creates a hitbox around a bone. These hitboxes are used by the AI for simple collisions, such as bullets.
Running studiomdl with the -h option will print out all of the autogenerated hitboxes.
If any hitboxes are defined this way, autohitbox generation is disabled.
==Hitbox Groups==
When a hitbox is added to a bone, it has an additional group parameter before the name of the bone which can change how the hit is calculated for damage. Many NPC as well as certain vehicles follow a scheme for each hitbox.
* $hbox 0 - Generic - the default group of hitboxes, appears White in HLMV 
* $hbox 1 - Head - Used for human NPC heads and to define where the player sits on the vehicle.mdl, appears Red in HLMV 
* $hbox 2 - Chest - Used for human NPC midsection and chest, appears Green in HLMV 
* $hbox 3 - Stomach - Used for human NPC stomach and pelvis, appears Yellow in HLMV 
* $hbox 4 - Left Arm - Used for human Left Arm, appears Deep Blue in HLMV 
* $hbox 5 - Right Arm - Used for human Right Arm, appears Bright Violet in HLMV 
* $hbox 6 - Left Leg - Used for human Left Leg, appears Bright Cyan in HLMV 
* $hbox 7 - Right Leg - Used for human Right Leg, appears White like the default group in HLMV 
* $hbox 8 - Neck - Used for human neck (to fix penetration to head from behind), appears Orange in HLMV 
==Syntax==
 $hbox (group number) (bone name) (min x) (min y) (min z) (max x) (max y) (max z)
==See also==
* $cbox
* $bbox
* $hboxset
__NOTOC__
Category:Modeling
hbox
Category:Source
$hboxset

It creates a named block for a group of $hbox definitions. The AI can select any one set to use for collisions.
==Syntax==
 $hboxset (name)
==Example==
 $hboxset "default"
 
 $hbox 0 "airboat.hull"	 -40.00 0.00 -72.50 40.00 20.00 72.50
 $hbox 0 "airboat.hull"	 -12.50 20.00 -21.00 12.50 65.00 11.00
 $hbox 0 "airboat.hull"	 -11.00 20.00 22.50 11.00 37.50 47.50
 $hbox 0 "airboat.hull"	 -20.00 20.00 -99.50 20.00 80.00 -24.50
 
 $hboxset "entryboxes"
 									
 $hbox 0 "Airboat.Hull"	 25.00 10.00 -104.00 85.00 110.00 104.00		// top left
 $hbox 1 "Airboat.Hull"	 -85.00 10.00 -104.00 -25.00 110.00 104.00		// top right
 $hbox 2 "Airboat.Hull"	 -37.50 10.00 40.00 37.50 110.00 104.00		// top front
 $hbox 3 "Airboat.Hull"	 25.00 -40.00 -104.00 85.00 10.00 104.00		// bottom left
 $hbox 4 "Airboat.Hull"	 -85.00 -40.00 -104.00 -25.00 10.00 104.00		// bottom right
 $hbox 5 "Airboat.Hull"	 -37.50 -40.00 40.00 37.50 10.00 104.00		// bottom front
 $hbox 6 "Airboat.Hull"	 -37.50 10.00 -132.00 37.50 110.00 -88.00		// top rear
 $hbox 7 "Airboat.Hull"	 -37.50 -40.00 -132.00 37.50 10.00 -88.00		// bottom rear
==See also==
* $cbox
* $bbox
* $hbox
__NOTOC__
Category:Modeling
hboxset
Category:Source
$hgroup

Puts auto generated hitboxes into groups based on their parent bone. Groups also propagate down to the children.
 $hgroup 1 "Bip01 Head"
 $hgroup 3 "Bip01 Pelvis"
 $hgroup 2 "Bip01 Spine2"
 $hgroup 4 "Bip01 L Arm1"
 $hgroup 5 "Bip01 R Arm1"
 $hgroup 6 "Bip01 L Leg"
 $hgroup 7 "Bip01 R Leg"
== Syntax ==
 
 $hgroup (group) (bone name)
__NOTOC__
h
$ikautoplaylock

Before the autoplay sequences are run, the specified $ikchain is locked in place wherever it happens to be. This is useful for locking the feet in place in case there are any pelvis motions on autoplay head turns or chest turns. 
== Syntax ==
 $ikautoplaylock <chain name> <pos lock> <angle lock>
The <pos lock> value dictates how high the chain is off the ground. Generally values between 0-1 are acceptable enough, but you can go higher or go lower into the negatives if need be.
The <angle lock> value can be left untouched (or even at 0). This controls the rotation of the chain and isn't really necessary.
== Example ==
 $ikautoplaylock rfoot 1.0 0.1
 $ikautoplaylock lfoot 1.0 0.1
 $animation a_pose_neutral "CT_body_poses" frames 0 0
ikautoplaylock__NOTOC__
$illumposition

It sets the lighting origin for the model, relative to its origin. By default the $illumposition is the model's origin.
When illuminating an animated or moving model in the engine, the lighting calculations are only done for the two brightest light sources, via the worldlights lump. All the other lights, as well as bounced light from the environment, are taken from a single ambient cube.
You can optionally specify a bone name for the illum position. If you do, the position specified will be interpreted as being relative to the specified bone.
== Syntax ==
 $illumposition (x) (y) (z) [optional bone name]
== Examples ==
 $illumposition 0.000 0.048 -0.115
 $illumposition 0.000 9.21 4.00 ValveBiped.Bip01_Pelvis
== See also ==
* prop_static
__NOTOC__
illumposition
$includemodel

It is used to add an MDL file that this model will include at run-time. All new sequences and animations will be appended to the model.
* Animations and sequences are processed in-order, so subsequent animations/sequences that have name conflicts will be ignored, and any references to .mdl local entry by the same name will be overwritten with the reference to a first one declared.
* Included .mdl's can have different bone ordering, but they need to have the same bone hierarchy and ikchain declarations. Currently there's no run-time checking to verify they match.
* Using $Includemodel will copy $animation, $sequence, $attachment and $collisiontext data. Models, Textures, Faces and other data are ignored.
== Example ==
* This creates a viewmodel for the Left 4 Dead 2 Boomer's hands, while taking the animations from anims_v_claw_Boomer.mdl.
$modelname "v_models\weapons\v_claw_Boomer.mdl"
$model "hands" "v_Boomer_Hands_l4d2.smd" 
$includemodel "v_models/weapons/anims_v_claw_Boomer.mdl"
i
$jointconstrain

$jointconstrain is a parameter of the $collisionjoints QC command. It is used to set the limit of a named bone's movement relative to its parentbone in a jointed collision model. 
== Syntax ==
 $jointconstrain <bone_name> <axis> <allow_option> <min_angle> <max_angle> <friction>
where
; <bone_name> : is the name of the 'child' bone as opposed to the 'parent' bone of the joint.
; <axis> : specifies either the X, Y, or Z axis of rotation.
; <allow_option> : can be one of three values:
:* Free : ensures the joint can move between a <min_angle> of -360 and a <max_angle> of 360, with a selectable <friction>. Ignores user specified <min_angle> and <max_angle> values.
:* Fixed : ensures the joint does not move at all. <min_angle>, <max_angle> and <friction> values are effectively locked to "0". 
:* Limit : ensures the joint is completely customizable. The user must specify <min_angle>, <max_angle> and <friction> values. 
; <min_angle> : specifies the minimum angle of rotation about <axis> in degrees. (No lower than -360).
; <max_angle> : specifies the maximum angle of rotation about <axis> in degrees. (No higher than 360).
; <friction> : specifies the Friction value .
=== Example ===
For example, the right-hip joint of a valvebiped is defined by constraining the movement of valvebiped.bip01_r_thigh in relation to its parent bone (which would be valvebiped.bip01_pelvis). Notice we need a separate $jointconstraint for each axis of rotation.
 $collisionjoints "phymodel.smd" {
 	$mass 70.0
 	$inertia 10.00
 	$damping 0.01
 	$rotdamping 1.50
 	$rootbone "valvebiped.bip01_pelvis"
 	$jointmerge "ValveBiped.Bip01_Pelvis" "ValveBiped.Bip01_Spine1"
 
 	$jointconstrain "valvebiped.bip01_r_thigh" x limit -12.00 12.00 0.00 // from -12 to 12 degrees in the X-axis - twist knee left/right
 	$jointconstrain "valvebiped.bip01_r_thigh" y limit -8.00 75.00 0.00 // from -08 to 75 degrees in the Y-axis - spread knees
 	$jointconstrain "valvebiped.bip01_r_thigh" z limit -97.00 32.00 0.00 // from -97 to 32 degrees in the Z-axis - raise knee
 	
 	//etc
 	}
: 
jointconstrain
$keyvalues

It embeds a block of arbitrary keyvalues into the .mdl file.
Programmers can access the $keyvalues block with modelinfo->GetModelKeyValueText(GetModel()) and the KeyValues class.
== Syntax ==
 $keyvalues
 {
 keyvalue data
 }
== Common KeyValues ==
See :Category:QC Keyvalues for a complete list.
;prop_data
:Defines various properties for models for use in Valve's prop_* entities - usually .
;physgun_interactions
:Defines any non-standard interactions with the Gravity Gun.
;particles
:Attaches particles.
; door_options
: Configures the model for use with .
;vehicle_entry
:Positions where the player will enter into a vehicle, where the player's camera will blend into the vehicle's camera position ( eyes ). It is defined by attachments with a number to indicate the hitbox group, set previously on any hitbox within a hitbox set called "entryboxes".
;vehicle_exit
:Positions where the player will exit from a vehicle. Defined by the name of an attachment and if is intended to be used while the vehicle is upright ( "upright" ) or upside down ( "upsidedown" ).
;vehicle_escape_exit
:Positions where the player will exit from a vehicle in case there are problems ( underwater, upside down, other events... ). Same definitions as in vehicle_exit.
;AddedAmbientScale <int>
:Softens the ambient lighting received by this model. Present in L4D2 infected.
== Example ==
 $keyvalues
 {
 	prop_data
 	{
 		base Wooden.Small
 		dmg.bullets 0
 		explosive_damage 100
 		explosive_radius 100
 	}
 	physgun_interactions
 	{
 		onfirstimpact 	break
 		onfirstimpact 	paintsplat
 		onlaunch 	spin_zaxis
 		onbreak 	explode_fire
 	}
 
 	// hud_name has been made up as an example of a one-dimensional custom KV.
 	// (If you were being picky, you might point out that it ought to be localised ...)
 
 	hud_name "Rubber chicken with a pulley in the middle"
 }
 $keyvalues
 {
 vehicle_entry
 {
 "enter1" "1"
 "enter2" "2"
 "enter3" "3"
 "enter4" "1"
 "enter5" "2"
 "enter6" "3"
 "enter7" "1"
 }
 vehicle_exit
 {
 "exit3" "upright"
 "exit4" "upright"
 "exit6" "upsidedown"
 }
 vehicle_escape_exit
 {
 "exit1" "upright"
 "exit2" "upright"
 "exit5" "upsidedown"
 "exit7" "upright"
 "exit8" "upsidedown"
 }
 }
keyvalues
$lightmap

It defines a lightmap to be used to light the MDL model's material, instead of the per-vertex lighting used by or point-based vertex lighting used by other models.
This parameter does not usually need to be added manually, as VRAD will generate model lightmaps automatically if is enabled for the prop_static and is enabled in VRAD. Nonetheless, it can still be added manually, such as for using a lightmap on a prop_dynamic, or if a prop_static has multiple materials (as VRAD can only generate lightmaps for the first material and skin).
__TOC__
==VMT syntax==
 $lightmap <texture>
== Limitations and caveats ==
== See also ==
* - Can be used on the UnlitGeneric shader to simulate lightmaps in all Source engine branches.
* - A shader that can be used to fake lightmaps or vertex coloring in all Source engine branches. It can bypass some of the limitations of , but requires additional setup to look convincing.
l
$lightwarptexture

It tints texels depending on their brightness. It can be thought of as localized color correction.
== Caveats ==
== Lightwarp textures ==
A lightwarp texture is a one-dimensional strip of pixels. Dark texels will be tinted with the colour on the left-hand side, and bright texels with the colour on the right. 50% gray means no tint. 
=== VTF parameters === 
A lightwarp texture should use uncompressed BGR888 format to avoid undesired color banding on lighting gradients, and should be UV clamped.
If using , use these compile parameters:
nocompress 1 // disable texture compression, to prevent undesired color banding
nomip 1 // disable mipmaps, which are unnecessary in this instance
nolod 1 // always use the full resolution version of this texture (due to being low-resolution to begin with)
clamps 1 // prevent tints at lighting extremes from blending together
clampt 1 // optional?
stripalphachannel 1 // remove unnecessary alpha channel, if present
=== Examples ===
; ():
: This is the lightwarp texture used in the screen above. It is designed to add a subtle bluish tint to darker snow without affecting brighter regions.
; ():
: This is applied to all characters, not just the Pyro. It creates the high-contrast shadows with red-tinged terminators typical of the illustrative art the game apes.
; Posterized (custom): 
: This custom warp texture creates a posterized "line art" style. Enabling lightwarp alone isn't enough however: ambient lighting must be at 0 to make unlit areas black, and world lighting must become viewer-dependent to ensure that shadows are always cast.
; Cel Shading (custom):
:Cel shading can make objects look more cartoony by replacing the smooth lighting gradient with sharp steps.
Other possible uses of include contrast enhancement, tweaking vertex lighting shadow transitions, highlight softening, and more.
::
== References ==
Lightwarp Fixes [Team Fortress 2] [Mods] on GameBanana
l
$limitrotation

By default, all bones will rotate through the shortest path - anything less than 180 - when blending between any two or more unrelated animations that are overlap with the bones well out of phase. This can cause problems with bones that can legally be posed at angles greater than 180 degrees away from each other, such as in two different animations or a hyper flexible wrist or hinge, but they shouldn't rotate through the shortest arc but through some less than 360 arc.
Setting a bone to $limitrotation causes studiomdl to calculate the rotation domain of the bone as specified from the source animations and calculates a "mid point" rotation that all rotations compare against, which allows for greater then 180 degree rotations.
== Syntax ==
 $limitrotation (bone name)
== Example ==
 $limitrotation "Antlion_Guard.claw1_L"
 $limitrotation "Antlion_Guard.claw2_L"
 $limitrotation "Antlion_Guard.pelvis"
__NOTOC__
limitrotation
$lockbonelengths

Bone lengths as specified by the $definebone commands are used to override any bone animations in the source files. Animations are recomputed with the new bone lengths, and the IK chains are resolved so that they end up in the original 3D locations. This is a very crude way to map one set of animations on to a different skeleton.
== Syntax ==
 $lockbonelengths
lockbonelengths__NOTOC__
$lod

It is also available in . It is a QC command describing how to reduce the level of detail when rendering the model at a given size. It handles the removal or replacement of expensive parts of the model so it can be rendered more efficiently. There can be up to 8 levels.
== Limitations ==
== Syntax ==
$lod <threshold>
{
	<options>
}
$shadowlod // Used to generate cheap render-to-texture shadows (not shadow maps)
{
	<options>
}
; threshold
: Defines when the LOD takes effect. Its value is (100 / screen pixels per unit) , which means that distance at which the transition happens depends on the size of the user's monitor and their FOV, not simply the model's distance from the camera. Someone with a truly massive screen may never see an LOD!
: The threshold formula makes it difficult to determine what values to use, however. The best way of working things out is to load your model into HLMV, switch to the Model tab, enable Auto LOD, and use to zoom in and out.
=== Options ===
; replacemodel <Reference smd> <LOD smd> [reverse]	
: Replaces the given reference SMD (can by anything from $body, $bodygroup or $model) with an LOD version.
: Reverse is used to correct reversed normals on the LOD, which can be caused by SMD export problems. 
; removemodel <Reference smd>	
: The specified SMD will not be rendered at all at this level of detail.
; replacematerial <Reference material> <LOD material>	
: Replaces all instances of the reference material with another. Useful for removing expensive processes like $bumpmap and disabling the Eye shader. Paths are relative to $cdmaterials.
; removemesh <Reference material>
: Removes all triangles attached to the named material. Unlike in replacematerial, paths are relative to the root materials folder. 
; nofacial
: Disables facial animation.
; bonetreecollapse <Reference bone>
: Causes children of the specified bone to be removed. Their attached vertices return to the reference position. This is commonly used on fingers. Remember that it only applies to clients!
;replacebone <Reference bone> <LOD bone>
:The precursor of bonetreecollapse. Replacing bones is much more complex, but allows all kinds of unusual bone optimisations that a simple collapse wouldn't achieve.
; use_shadowlod_materials
: 
== Example ==
$lod 12
{
	replacemodel "Police_reference" "lod1_Police_reference"
	replacemodel "Manhack_reference" "lod1_Manhack_reference"
}
$lod 18
{
	replacemodel "Police_reference" "lod2_Police_reference"
	replacemodel "Manhack_reference" "lod2_Manhack_reference"
	bonetreecollapse "ValveBiped.Bip01_R_Hand"
	bonetreecollapse "ValveBiped.Bip01_L_Hand"
}
$lod 42
{
	replacemodel "Police_reference" "lod3_Police_reference"
	replacemodel "Manhack_reference" "lod3_Manhack_reference"
	bonetreecollapse "ValveBiped.Bip01_R_Hand"
	bonetreecollapse "ValveBiped.Bip01_L_Hand"
}
== See also ==
* LOD Models
* LOD system
lod
$maxverts

It defines when to split and the maximum amount of vertices allowed in each model.
It allows to compile bigger model without use of cracked compilers and not having to deal with "shattered" model in game.
== Syntax ==
 $maxverts <Limit: int> [Clamp: int]
: Both Limit and Clamp default to 21,845 if the command is not used
; Limit
: This specifies the number of vertices if the model goes over to split the model.
: The value passed in is clamped between 1,024 and 65,536.
; Clamp
: When the model is being split this is the amount each split model can have.
: If a value is passed in, its clamped between 1,024 and 65,536.
: If value not passed in it defaults to Limit clamped to 32,768.
== Example ==
 $maxverts 65536 65536
: This sets it so all models use the max amount amount of vertices possible.
 $maxverts 20000 10000
: This makes it if a model has over 20k vertices then each split model has a max of 10k vertices.
m
$modelname

It is required, as it specifies the path and filename of the compiled model.
* In , this is either a relative path (relative to $cd) or an absolute path. Absolute paths must be encapsulated in quotes, but relative paths do not.
* In , this is always a relative path, relative to the \models folder of the mod. 
==Example==
 $modelname		"weapons/shell.mdl"
 
 $staticprop
 
 $body		body	"shell"
 
 $cdmaterials		"models\weapons\"
 
 $sequence	idle	"shell_anim_@idle"
 
 $collisionmodel		"shell_physics"
This model will be created at <game path>\models\weapons\shell.mdl.
Category:Modeling
modelname
Category:Source
$moss enable

This is procedural moss implementation, which is triplanar projection shader that allows you to project additional texture that mixes with normalmap. This shader available for VertexLitGeneric, LightmappedGeneric and Lightmapped_4WayBlend shaders. It was created during development of Xen for and was designed to simulate presence of moss on surface.
For VertexLitGeneric, it uses the specified texture. For LightmappedGeneric and Lightmapped_4WayBlend, instead of using the texture itself for moss, this shader takes color that most of the texture consists of and then applies color to the surface according to the parameters specified in .vmt.
All parameters works in the same way for both shaders.
In it was used for models\props_xen\moss_test\sphereofchon.mdl and models\props_xen\moss_test\test_moss001.mdl models. Both using the models/props_xen/moss_test/bubblemoss texture. The final version of the game doesn't use this shader in any of the maps. May be incompatible with some shaders (as it was with $phong).
This shader was used in . Besides moss, it was also used for dust caps and other small details. 
This shader also should be good for a snow layer.
== Parameters and Effects ==
== See also ==
* New Specular
* BlackMesa XenEngine: Part1 – Heavily Modified Source Engine (page from Black Mesa developer about Black Mesa engine, better known as XenEngine)
Category:Black MesaCategory:Shaders
$mostlyopaque

It causes the model to be rendered in two passes: The first pass renders only the opaque portions of the model, and the second pass renders only the translucent portion of the model. 
The use of $mostlyopaque can be used to improve the visual quality of models such as foliage or underbrush, by improving the lighting on the translucent materials.
== Syntax ==
 $mostlyopaque
== See also ==
* $opaque - Similar command for models that have mostly opaque materials, and renders in one pass.
mostlyopaque
$mraotexture

It is available exclusively for the PBR shader to define the MRAO map to use for the Physically Based Rendering effects.
==Additional Parameters==
== Physically Based Rendering ==
Physically Based Rendering is a photorealistic shading technique that takes lighting information about the metalness, roughness, and ambient occlusion of a texture and then renders lighting in a realistic manner. Most modern game engines utilize PBR for most of their textures, and unfortunately due to the engine's age, it is not supported by all the official Valve branches. However, some third party games and engine branches support this shader.
== What is an MRAO map? ==
An MRAO (M etalness, R oughness, Ambiemt Occlusion) map is a texture that contains lighting information on the metalness, shininess, and self-shadowing of the diffuse (a.k.a base, albedo) texture through the intensity of the RGB channels. This reduces the amount of texture maps needed for one PBR material from 5 to 3, reducing file space and memory cost. However, image editing programs often do not have an easy way to make these textures. Thankfully, there are a couple of methods to create these textures that work.
==See also==
*PBR (Strata shader)
*Adding PBR to your mod
*Physically Based Rendering
*Category:PBR
==External links==
*https://www.adobe.com/products/substance3d/discover/pbr.html - All You Need To Know About PBR (Adobe.com)
Category:PBR
$no draw

It is a setting that causes the material to not be drawn or rendered at all. Usually used to quickly hide parts of a model, without having to make a transparent texture.
Similar to %CompileNoDraw, except this can be applied to models. This can be used as a workaround to the broken "Removemodel" on $lod, or to have a material disappear in a specific skin.
== Example ==
VertexLitGeneric
{
$no_draw 1
}
Category:Material System
no draw
$nocull

It disables backface culling, resulting in triangles showing from both sides. It is used to allow for infinitely thin dual sided objects without duplicating the triangles with reversed vertex order. Lighting will still only be calculated from the "front" side of the face, and be copied to the reverse side, potentially creating an effect where light bleeds through to the other side like a thin sheet hung up in direct sunlight, so use with caution.
==VMT Syntax and Examples==
 $nocull <bool>
 LightmappedGeneric
 {
 	$basetexture glass\window001a
 	$nocull 1
 }
 VertexLitGeneric
 {
 	$basetexture models\items\medkit
 	$nocull 1
 }
 VertexLitGeneric
 {
 	$basetexture models\props_2fort\blue_window001_glass
 	$alphatest 1
 	$nocull 1
 }n
$opaque

It causes the model to be assumed to be opaque with respect to its sorting against all other objects in the scene. Use this in cases where only a small portion of the model is translucent (hair, eyes, glasses, etc.) so if there are any sorting issues, it won’t matter.
== Syntax ==
 $opaque
o
== See also ==
* $mostlyopaque - Similar command for models that have translucent materials, which renders in two passes.
opaque
$origin

It adjusts the position (and optionally Z rotation) of a model within its own local space. During compiling, it will be offset by the X, Y, -Z and Z-rotation values provided.
This is useful when adjusting view models, for ensuring that models don't spawn inside the world, and helping in the arranging of clusters of separate models that need to be aligned precisely with each other (e.g. parts of a building).
== Syntax ==
 $origin <x> <y> <-z> [z rotation]
Note that Z's value is reversed.
== With viewmodels ==
center
== See also ==
* $autocenter
* Origin
origin