Compiling a model

Models need to be compiled before they can be used in a game. There are three components of a compile:

1. A set of source files (SMD, DMX, VTA) describing a model. See Exporting a model if you don't have any. FBX enjoys limited support in CS:GO starting from update 1.34.8.4. OBJ can also be used with any branch, with the same limitations as FBX.
2. A QC file that defines, in a manner not too dissimilar to a texture's VMT, how the source files should be transformed into a Source engine model.
3. StudioMDL, the SDK program that consumes the QC and spits out a compiled model.

Setting up

Assuming that your source files have exported OK from your favorite 3D modeling software, the only step you need to take before compiling is choosing the current VPROJECT. This defines where studiomdl will write out the compiled model. You can configure the value:

1. Globally, by selecting your game/mod in the SDK launcher's drop-down list.
2. For studiomdl only, by running it with -game "<full path to your gameinfo.txt folder>"
   Tip:Most SDK tools accept -game.

Syntax highlighting

Editing a QC file becomes much easier when you use an advanced text editor with support for syntax highlighting. There are two editors with QC highlighting rules at the moment:

• Notepad++
• ConTEXT

Creating a QC

A QC file is simply a text file with the extension .qc. You can create it anywhere and name it anything, but it's best to be organised and store it with your SMDs in a folder with the same name as the destination model file.

Inside it should be a list of commands that tell studiomdl about the location of the model's various SMDs, where the compiled files should be written to (relative to VPROJECT), how to process animations, and potentially much, much more. You will find all known commands listed at Category:QC Commands.

Example

File locations

When a source file is referenced in your QC, the compiler will look for it in the same folder. You should therefore place all your source files for a given model in the same folder. There are, however, commands to tell the compiler that you want to give it a file that is not in the same folder as the QC!

• With an absolute path (e.g. C:\modelsrc\my_model\)
• With a relative path (e.g. .\subfolder or ..\)
  Tip:A single period is the current folder. Two periods is the one above it. ..\..\ goes two directories up.
• With $pushd and $popd.

Here is a very simple QC file for a solid model without any animation or special properties (click on each command for details):

$modelname	"props\myfirstmodel.mdl"
$body mybody	"myfirstmodel-ref.smd"

$surfaceprop	combine_metal
$cdmaterials	"models/props"

$sequence idle	"myfirstmodel-ref"

$collisionmodel	"myfirstmodel-phys" { $concave }

You should be able to use this as a template to compile your own model, so swap in your own SMDs (of DMXes, or FBXes) and see what happens.

Note:All models must have at least one $sequence, even if they aren't actually animated!

Tutorials

• For physically-simulated objects, see prop_data
• For characters or player models, see Compiling a character model
• For weapons, see Creating worldmodels from viewmodels
• For vehicles, see Vehicles (modeling)
• For general help with compiling models, see Category:QC Commands

Compiling

With your text editor

The easiest way to compile a model is with the built-in launch features of advanced text editors.

• With Notepad++
• With ConTEXT

With a batch file

If you can't (or don't want to) use an advanced text editor, you will be compiling QCs by dragging them onto studiomdl in Windows. You can find the executable file in sourcesdk/bin/[orangebox|ep1]/bin/.

The process will be easier if you create a .cmd file somewhere more accessible to automate it. This is simply a renamed .txt file containing something like this:

"%sourcesdk%/bin/orangebox/bin/studiomdl" -nop4 %1
pause

Drop your QC file onto the CMD as you would studiomdl itself; it's essentially a shortcut to the executable.

With Compiling Tools

Third party tools, such as Crowbar, include model compiling, and decompiling, tools. All you have to do with programs like these is specify the QC file, select the game you are using, and press compile. It will automatically do all the steps listed above.

Common errors

• Error opening <model>! (Check for write enable)

Studiomdl won't create folders that don't exist; you must manually create a path to your .mdl before compiling.

• Costly collision model
• Duplicate weightlist pelvisonly
• Short conversion out of range
• WARNING: (4768124) : ERROR: 'EXCEPTION ACCESS VIOLATION' (assert: 1)

If you receive EXCEPTION_ACCESS_VIOLATION without an error code, try compiling with HLMV running.

• WARNING: Bad collision model, check your smoothing groups!!!

If you created the collision model with XSI then you need to turn off Geometry Approximation's Automatic Discontinuity (Explorer -> Your Mesh -> Geometry Approximation -> Polygon Mesh -> Discontinuity -> Untick Automatic) for the smoothing groups to be exported properly.

Note:If disabling automatic discontinuity doesn't work, try making your collision model simpler.

• WARNING: Model has 2-dimensional geometry (less than 0.500 inches thick on any axis)!!!

This will happen if one, or more, face isn't in the same smoothing group as the rest of the collision model. To fix this simply assign all faces of your mesh to the smoothing goup 1 (since you can only use 1 smoothing group). Many thanks to Vaenyc for this thread

This also happens if there literally is too thin geometry in a collision model. This might be related to scaling down a model with $scale, especially if the intent was to recompile a full-sized model for skybox usage. (In that case, replacing the collision model by an empty one might be adequate as skybox content usually won't need collisions.)

• Bounding box out of range

The compile error "bounding box out of range" followed by a string of coordinates means that the collision model for your mesh is larger than the maximum allowed size which seems to be hard coded at 16384 units in any direction. This often happens when you either scale up a model too much forcing the collision outside the range, or if your animation causes your collisionjoints to move outside this range.

Tip:A solution might be to divide the model into several smaller pieces if possible.

In the case where your model isn't going to be colliding with other objects in the world, it seems that you can also ignore this error if need be as it doesn't seem to impact performance.

SDK samples

The SDK has numerous sample models, including several fully-articulated characters and players. They can be found at steamapps\common\sourcesdk_content\<game>\modelsrc\.

Note:Left 4 Dead and Left 4 Dead 2 sample models can be found at <game>\sdk_content\modelsrc\

sdk

Complete SMD source for both player models and weapons in Day of Defeat: Source.

tf

Complete, but outdated, DMX source for all TF2 classes. Rigged reference meshes are also available as SMD and Maya.

generic

A tweaked ValveBiped rig (no meshes)

cstrike

"Urban CT" player model

Several static props

hl2

Airboat and Buggy

Antlion Guard

Male citizen (old version with only a few animations)

Some CS stuff that is probably a duplicate of \cstrike's content

Viewmodels for all HL2 weapons

hl2mp

All with multiplayer animations only:

Combine soldier

Metrocop

Male rebel

Left 4 Dead

Common infected Models, Bodygroups, and commands necessary for Dynamic Skins

Breakable Woodrail prop example

Explosive Weapon examples for red gas cans and propane tanks

Left 4 Dead 2

Breakable Woodrail prop example different from the one found in Left 4 Dead 1

Crumbling Ceiling dynamic prop example

Alien Swarm

Drone alien and marine source files

See also

• QC
• Category:QC Commands
• Crowbar
• studiomdl
  • Studiocompiler, a graphical interface for studiomdl
  • GUIStudioMDL, another graphical interface
• Highlighting and Compiling QCs with ConTEXT
• Notepad++ VDF languages
• Common Compile Errors and Some Solutions