View source for MDL (GoldSrc)

{{LanguageBar}}
{{gldsrc topicon}}
{{tabs|MDL|quake=1|gldsrc=1|source=1}}
{{stub}}

'''MDL''' (sometimes referred to as '''Half-Life MDL''' or '''HLMDL''') is a model format used by {{gldsrc|4}} to store dynamically lit [[models]] which can be animated using [[skeletal animation]], along with their associated [[textures]]. It is a heavily modified version of the [[Quake MDL]] format.

== Overview ==
=== Limits ===
HLMDL has the following limits per input SMD:
* 1 mesh
** 2048 vertices (and vertex normals) per mesh
** 4080 triangles per mesh
* 1 animation sequence
** 512 keyframes per sequence
* 128 bones

Additionally, the following limits apply to the ''whole MDL'':
* 4 bone attachments
* 8 bone controllers
* 32 meshes across all submodels
* 256 animation sequences.

Textures must:
* Be 8-bit uncompressed [[BMP]] files.
* Have a resolution which is a multiple of 8 (multiples of 16 are preferred).
* Have a resolution which does not exceed 512x512 (soft limit; raised to 1024x1024 in {{sven|4.1}} and other engines like {{fte|4.1}}).
* Have a file name which is not longer than 64 characters (including the {{code|.bmp}} extension).
<br>
{{modernImportant|Older versions of [[StudioMDL]], including the version found in the {{hlsdk|4.1}} on Steam, do not support tiling UVs, clamping them to the edge of the texture. ''This is not a limitation of the HLMDL file format''; the [https://www.the303.org/tutorials/gold_qc.htm#AS Sven Co-op StudioMDL] can create MDLs compatible with vanilla {{gldsrc|4.1}} which have tiled UVs. 
{{bug|The latest version of the Sven Co-op StudioMDL (from December 2020), as found in the Sven Co-op SDK, has some bugs with bounding boxes; use the version linked above instead (from November 2018).}}
}}
{{tip|To create a model or submodel with more than 4080 tris, split the model into multiple SMD meshes, with a separate {{cmd|$body}} or {{cmd|$bodygroup}} entry for each mesh in the [[QC]] file.
{{warning|'''''<big>Avoid going over 9000 tris!</big>'''''<br>While the HLMDL format can handle over 100K tris, the old OpenGL renderer struggles with such "high-poly" models, even on high-end GPUs.{{ref|1}}
{{note|Third party games that upgrade the renderer (ex: {{paranoia}}, {{cof}} or {{csnz}}) can handle higher polygon MDLs better. This does '''''not''''' include {{sven|4.1}}, which uses a mostly vanilla renderer.<br>This is obviously not a problem for games on engines much newer than {{gldsrc|4.1}} that use the HLMDL format, such as {{cloop|4.1}} ({{Unity}}) or {{freecs|4.1}} ({{fte}}). }}
{{modernConfirm|Is this soft limit 9000 total, or 9000 being displayed simultaneously?}}
{{modernConfirm|Can replacement renderers without engine access, such as [[Trinity Engine]], improve performance for higher-poly MDLs?}}
}} }}
{{modernConfirm|Max textures, max skins, and other limits?}}

== Flags ==
=== Model flags ===
Particle effects ''cannot'' be combined, but all others can.{{clarify}}
{| class="wikitable"
|-
! Bit !! Flag name !! Particle effect? !! Description
|-
| 1 || EF_ROCKET || Yes || {{quake|4|nt=0}} rocket trail particles and dynamic light
|-
| 2 || EF_GRENADE || Yes || {{quake|4|nt=0}} grenade trail smoke particles
|-
| 4 || EF_GIB || Yes || {{quake|4|nt=0}} gib blood trail particles
|-
| 8 || EF_ROTATE || No || Rotate this model around its origin, like the weapon pickups in {{quake|4|nt=0}}; requires supported game code.
|-
| 16 || EF_TRACER || Yes || {{quake|4|nt=0}} skrag spit particles
|-
| 32 || EF_ZOMGIB || Yes || {{quake|4|nt=0}} zombie blood; like EF_GIB, but darker
|-
| 64 || EF_TRACER2 || Yes || {{quake|4|nt=0}} death knight slashing particles
|-
| 128 || EF_TRACER3 || Yes || Like EF_GRENADE, but only has one trail
|-
| 256 || EF_NOSHADELIGHT || No || Reduces intensity of shadows on the model, without making the model flat {{modernConfirm|[[Half Lambert]]?}}
|-
| 512 || EF_HITBOXCOLLISIONS || No || Use hitbox for collision instead of bounding box
|-
| 1024 || EF_FORCESKYLIGHT || No || Always use skybox lighting, regardless of model location
|}

=== Texture flags ===
{| class="wikitable"
|-
! Bit !! Flag name !! Description 
|-
| 1 || STUDIO_NF_FLATSHADE || Shade the model a single tint, without any shadowing, resulting in the model looking "flat" like a cartoon character.
|-
| 2 || STUDIO_NF_CHROME || Use matcap environment mapping to render the texture as a sphere map.
{{bug|Limited to 64x64 in vanilla {{gldsrc|4}}; this is fixed in {{sven|4}}. Chrome resolutions higher than 256x256 tend to have diminishing returns.}}
{{note|Automatically set for any textures that contain the string {{code|chrome}} somewhere in their name.}}
{{modernImportant|Setting the chrome flag via StudioMDL will also add the flatshade flag, as well as move all UV coordinates to the top-left corner (chrome doesn't use UV mapping).}}
|-
| 4 || STUDIO_NF_FULLBRIGHT || Display texture at maximum brightness, ignoring lighting.
{{bug|Doesn't work in vanilla {{gldsrc|4}}; fixed in {{sven|4}} and custom renderers.}}
|-
| 8 || STUDIO_NF_MIPMAPS || Generates mipmaps for the texture, greatly reducing texture aliasing at a distance. <br>No effect in {{sven|4}}, which always generates mipmaps for models, regardless of this flag.{{bug|This flag was actually originally intended to ''disable'' mipmaps for a texture, but this behavior was accidentally inverted.{{modernConfirm|Allegedy fixed in 25th Anniversary Update.}} }}
{{tip|Recommended for most textures except alphatested ones. Due to the way textures are stored, enabling mipmaps of alphatested texture will result in the texture transparency becoming more exaggerated at a distance, with fine details like thin foliage and wire fences disappearing, and shadowing occurring around the edges occurring due to transparent texels not being [[alpha dilation|dilated]].}}
|-
| 16 || STUDIO_NF_ALPHA || Unused?
|-
| 32 || STUDIO_NF_ADDITIVE || Use [[$additive|additive]] translucency. Still affected by entity lighting; use the Additive rendermode on an entity to ignore lighting.
{{bug|Sometimes breaks [[normal]]s of non-additive faces on the same [[mesh]].
{{workaround|Split the additive portions onto a different mesh, by listing it as a separate [[SMD]] with a separate [[$body]] line (usually after the main mesh).
{{tip|This affects the order in which faces are loaded into the z-buffer, which can be used for manual alpha sorting. In practice, this means defining an additive chrome overlay (to simulate specular highlights) as a separate mesh after the main mesh  will prevent {{w|z-fighting}}, even if the mesh is coplanar. }}
}} }}
|-
| 64 || STUDIO_NF_MASKED || Use binary [[$alphatest|alphatest]] transparency, wherein the last palette entry of the texture is transparent.
|}

== In other engines ==
Half-Life MDLs are supported by {{fte|4}} and the {{unity|4}} game {{cloop|4}}.

== External links ==
* [https://www.the303.org/tutorials/ The303's GoldSrc model tutorials and documentation]
* [https://github.com/malortie/assimp/wiki/MDL:-Half-Life-1-file-format Assimp documentation for HLMDL]

== References ==
<ol>
<li> From the [https://www.the303.org/tutorials/gold_mdl.htm GoldSrc Model Export Tutorial by The303]:
{{quote
| 1 = In order to compile models with more than 4080 triangles, you must break up your SMD's into parts and give them their own $body lines for compiling. '''Also, FOR THE LOVE OF ALL THAT IS HOLY PLEASE DO NOT GO CRAZY ON YOUR TRIANGLE COUNT; remember this is goldsrc, not source engine.''' Going any higher than 9000 tris is excessive and direct ports from source/other games are inefficent, wasteful, and cause performance issues for the old renderer.
| 2 = The303
}}

[[Category:File formats]]