smf Compile: Complete Source Filmmaker Guide

A custom model can look flawless in Blender and still appear invisible, untextured, or broken inside Source Filmmaker. The missing step is often compilation.

If you searched for smf compile, the dominant topic behind the query is Source Filmmaker compilation: converting models, animations, textures, and maps into formats Valve’s Source engine can actually use. Source Filmmaker, commonly shortened to SFM, runs on the Source engine and supports custom content, but raw project files normally need preparation before they work correctly.

Quick answer: smf compile is the workflow used to prepare custom assets for Source Filmmaker. A typical model pipeline exports geometry and animation as SMD or DMX, defines the asset through a QC script, and runs StudioMDL—often through Crowbar—to create an MDL model plus supporting VTX and VVD files.

This guide explains that workflow from beginning to end, including what the different files do, how QC scripts work, where textures fit, how maps are compiled, and what to check when something goes wrong.

What Does smf compile Mean?

The term smf compile is commonly encountered when people are actually looking for information about SFM compile or Source Filmmaker compilation.

Compilation is essentially a translation stage.

Your modeling application works with editable project data. Source Filmmaker needs assets prepared for the Source engine. StudioMDL is Valve’s command-line model compiler, and Valve’s documentation describes it as the tool that converts intermediate model formats into the binary .mdl format read by Source.

A simplified pipeline looks like this:

3D application → SMD/DMX → QC → StudioMDL/Crowbar → MDL + supporting files → Source Filmmaker

This matters because dropping a .blend project into an SFM content directory does not turn it into a usable Source model.

Compilation tells the engine about elements such as:

• model geometry;
• skeleton and bones;
• animation sequences;
• material locations;
• model destination;
• collision information;
• body groups;
• level-of-detail information.

The exact requirements depend on the complexity of the asset.

Compilation is not the same as rendering

One source of confusion is that some online material uses “compile” when discussing the final export of an SFM animation.

Technically, these are different processes.

Asset compilation turns source assets into engine-readable files.

Rendering/exporting turns an SFM scene into images or a movie.

Valve describes Source Filmmaker as a tool for creating modifiable 3D recordings that can ultimately be exported as movies or still images.

If your character refuses to appear in the model browser, you are dealing with an asset pipeline problem. If your finished animation needs to become a video, you are dealing with rendering/export.

Files You Need for Source Filmmaker Compilation

Understanding the file types removes much of the mystery from the smf compile workflow.

The files fall into three broad groups: source files, instruction files, and compiled output.

File	Purpose	Stage
.SMD	Mesh, skeleton, or animation data	Source
.DMX	Source model/animation data	Source
.QC	Model compilation instructions	Source
.MDL	Main compiled Source model	Output
.VVD	Vertex information	Output
.VTX	Hardware-optimized vertex data	Output
.PHY	Collision data when defined	Output
.VTF	Source texture	Material
.VMT	Material/shader definition	Material
.VMF	Editable Source map	Source
.BSP	Compiled playable map	Output

Valve’s documentation lists SMD and DMX among StudioMDL’s supported input formats and identifies MDL, VTX, VVD, PHY, and—in some configurations—ANI among its outputs.

SMD files

SMD is one of the traditional formats used in Source model workflows.

Depending on the asset, an SMD can contain mesh and skeletal information or animation data. A complex character may therefore use several source files instead of one giant file.

That is normal.

For example, separate mesh objects can be exported individually and assembled through QC instructions. Long-standing SFM community guidance also notes that separate objects may produce separate SMD/DMX files, which can then be combined through model or bodygroup directives.

DMX files

DMX is another Source-compatible intermediate format.

Both SMD and DMX can be valid choices for model and skeletal animation workflows supported by StudioMDL.

You do not need to convert everything to SMD merely because older tutorials use it. What matters is that your exporter, compiler, QC configuration, and target Source branch agree on the format.

QC files

The QC file is one of the most important parts of model compilation.

Think of it as the build instructions.

The mesh contains the model data, but the QC tells the compiler how those pieces should become a Source model.

A simple conceptual QC may contain directives resembling:

$modelname "custom/character.mdl"
$body "body" "character.smd"
$cdmaterials "models/custom/character/"
$sequence "idle" "idle.smd" loop

Real models can require substantially more configuration.

The key lesson is that a compiler error is not automatically evidence of a damaged mesh. Incorrect paths, missing files, invalid QC commands, or mismatched material references can stop an otherwise valid asset from compiling.

What Does StudioMDL Produce?

A successful compile usually creates several files rather than a standalone .mdl.

That detail catches many beginners.

According to Valve’s StudioMDL documentation, typical output can include the main .mdl, hardware-specific .vtx data, .vvd vertex data, and .phy collision data when a collision model has been defined.

MDL

The .mdl is the main compiled model file.

It carries information associated with the model such as its skeleton, animations, bounding information, material references, LOD information, and other model properties.

VVD

The .vvd stores hardware-independent vertex information, including UV-related data.

If the MDL exists but an expected companion file is missing, the asset may not behave correctly.

VTX

VTX files contain optimized vertex information for particular rendering targets.

A Source compile can generate variants such as .dx90.vtx and other branch-dependent outputs.

PHY

The .phy contains collision-mesh information.

It is not mandatory for every model. Valve’s documentation notes that the PHY output is omitted when no $collisionmodel is defined.

That means “my compile didn’t generate a PHY” is not necessarily an error.

Quick takeaway: Treat a compiled Source model as a package. Moving only the .mdl while leaving required companion files behind is a common way to break an otherwise successful compile.

Tools Commonly Used for smf compile

You do not need a huge software stack, but each tool serves a different part of the pipeline.

Source Filmmaker

Source Filmmaker is the final environment in which you test and animate the compiled asset.

Valve released the original Source Filmmaker in 2012. It runs on the Source engine’s Alien Swarm branch, while Source 2 Filmmaker is a distinct version available through certain Source 2 toolsets.

That distinction matters. A tutorial written for Source 1 SFM should not automatically be applied to Source 2.

Blender

Blender is widely used to prepare custom models.

Typical work before export includes:

• cleaning the mesh;
• checking UVs;
• preparing materials;
• creating or correcting the armature;
• assigning vertex weights;
• preparing animation;
• checking object scale;
• exporting Source-compatible intermediate data.

The Blender project itself is not what StudioMDL normally compiles. You first export appropriate model data.

Blender Source Tools

A Source-compatible Blender export workflow is commonly used to produce SMD or DMX data.

Before troubleshooting StudioMDL, check the export itself. A compiler cannot repair a fundamentally incorrect skeleton, missing mesh, or broken weight assignment.

StudioMDL

StudioMDL is the actual Source model compiler.

Valve documents its basic syntax as:

studiomdl [options] <path\QC>

The QC is the required input. StudioMDL also supports numerous options for debugging, performance, verification, bones, materials, and other compilation tasks.

Crowbar

Crowbar is a popular graphical frontend for Source model workflows and is specifically listed by the Valve Developer Community as a graphical frontend for StudioMDL.

For many creators, it is easier than manually constructing command-line calls.

Crowbar does not eliminate the underlying Source pipeline, though. If your QC references the wrong file or the model itself is invalid, a graphical interface cannot magically correct it.

HLMV

Half-Life Model Viewer, or HLMV, is extremely useful after compilation.

Instead of launching a full SFM project every time, you can inspect a Source model and examine features such as materials, animation, vertex weighting, pose parameters, flexes, and LODs.

This creates a cleaner workflow:

compile → inspect → fix → recompile → inspect → use in SFM

How to Compile a Model for Source Filmmaker

The easiest way to understand smf compile is to follow one model through the complete pipeline.

1. Prepare the model

Start in your 3D application.

Before exporting anything, check:

• mesh geometry;
• transforms and scale;
• UV mapping;
• material assignments;
• bone hierarchy;
• vertex weights;
• animation data;
• object names.

Do this before touching the QC file.

A common mistake is repeatedly editing compiler settings when the actual problem originated inside the source model.

2. Export Source-compatible data

Export the required mesh and animation files as SMD or DMX using an appropriate Source workflow.

Keep the project organized.

For example:

project/
├── model/
│   ├── character.smd
│   ├── idle.smd
│   └── character.qc
└── textures/
    └── character_diffuse.tga

You can use another structure, but predictable paths make troubleshooting much easier.

3. Create the QC

Write the QC so it points to the correct source files and defines the model properly.

At minimum, a simple model generally needs enough information to identify its output path, body/mesh, materials, and sequence configuration.

For example:

$modelname "custom/hero.mdl"
$body "body" "hero.smd"
$cdmaterials "models/custom/hero/"
$sequence "idle" "idle.smd" loop

Do not blindly copy a complex QC from an unrelated character.

Start with the simplest valid configuration for your model. Add bodygroups, flexes, attachments, physics, LODs, and extra animation features only when you actually need them.

4. Select the correct game configuration

Your compiler needs to target the correct Source environment.

This is especially important when multiple Source games or modding tools are installed. StudioMDL provides a -game option for overriding the VProject game path.

A technically correct model compiled against the wrong configuration can create confusing results.

5. Run the compile

You can invoke StudioMDL directly or use Crowbar.

Watch the compile log.

Do not immediately close it just because output files appeared.

Warnings can reveal problems that become obvious only later—for example, missing materials, bone issues, or unexpected model behavior.

6. Check the generated files

Confirm that the expected files exist.

A typical result might resemble:

hero.mdl
hero.vvd
hero.dx90.vtx

Other VTX variants may also be generated, and a PHY may appear if collision information is defined.

The exact set depends on the compiler, Source branch, options, and QC.

7. Verify the model

Open the model in HLMV when possible.

Check:

• Does the mesh appear?
• Is its scale reasonable?
• Are materials assigned?
• Are bones behaving correctly?
• Do animation sequences play?
• Are bodygroups available?
• Do flexes work if the model uses them?

Finding a problem here is much easier than diagnosing it after building an entire SFM shot.

8. Test inside Source Filmmaker

Finally, launch SFM and locate the asset in the model browser.

If it does not appear, verify your search filters and content paths before recompiling everything. Community troubleshooting guidance specifically recommends checking model-browser filters, subfolder searching, MDL selection, and text filters when a compiled model seems to be missing.

Where Do Compiled SFM Models Go?

Source separates editable source content from game-ready content.

Valve’s Source SDK directory documentation illustrates this distinction: source model files such as SMD and QC belong in model-source locations, while compiled MDL/VTX content belongs beneath the game’s models directory. Materials similarly use VMT/VTF files under materials.

For SFM custom content, you will often work with directories conceptually similar to:

usermod/
├── models/
│   └── custom/
└── materials/
    └── models/
        └── custom/

Your QC’s $modelname determines the model’s relative output path, while $cdmaterials tells the model where to look for its materials.

Paths deserve close attention.

If the model loads but appears purple and black, the compile itself may be fine—the engine simply cannot find the material or texture expected by the model.

How Textures Work in the smf compile Pipeline

Model compilation and texture preparation are related, but they are not the same operation.

A correctly compiled mesh can still have completely broken materials.

Source 1 commonly uses:

• VTF for texture data;
• VMT for material definitions.

Valve’s SDK directory documentation places compiled model materials in .vmt and .vtf form under the game’s materials hierarchy.

Why do SFM models turn purple and black?

The purple-and-black checkerboard is strongly associated with missing or unresolved Source materials.

When this happens, inspect the entire chain:

QC material path → VMT location → VMT texture reference → VTF location

Suppose your QC contains:

$cdmaterials "models/custom/hero/"

Your materials need to correspond to that directory structure.

A VMT may then reference a base texture along the lines of:

"VertexLitGeneric"
{
    "$basetexture" "models/custom/hero/hero_diffuse"
}

The path—not merely the filename—must make sense.

A useful debugging habit is to stop changing several variables at once. First verify the VMT is being found. Then verify the VTF reference. Then investigate shader-specific properties.

QC Files Explained Without the Jargon

A QC script may look intimidating because each instruction starts with $, but the underlying idea is simple.

It describes how the compiler should build the model.

$modelname

Defines where the compiled model belongs relative to the models directory.

Example:

$modelname "characters/robot.mdl"

$body

Points to a mesh used as a model body.

$body "body" "robot.smd"

$cdmaterials

Specifies where Source should search for materials.

$cdmaterials "models/characters/robot/"

$sequence

Defines an animation sequence.

$sequence "idle" "idle.smd" loop

$collisionmodel

Can define collision geometry.

If no collision model is specified, StudioMDL does not necessarily produce a .phy file.

The best QC for learning is a small one. Build a model that compiles first, then introduce more advanced directives.

SMD vs DMX: Which Should You Use?

Both formats appear throughout Source Filmmaker workflows.

Feature	SMD	DMX
Source model workflow	Yes	Yes
Mesh support	Yes	Yes
Skeletal animation	Yes	Yes
Common in older tutorials	Very common	Less common
StudioMDL support	Yes	Yes

Valve’s StudioMDL documentation confirms support for both formats for meshes and skeletal animation.

For a beginner, the best format is generally the one that works reliably with the exporter and pipeline being followed.

Do not convert formats simply because another tutorial uses a different one.

Consistency beats unnecessary conversion.

How Animations Are Compiled for SFM

Animations can be incorporated through the model’s QC.

Suppose you have:

idle.smd
walk.smd
run.smd

The QC might define sequences conceptually like:

$sequence "idle" "idle.smd" fps 30 loop
$sequence "walk" "walk.smd" fps 30 loop
$sequence "run" "run.smd" fps 30 loop

StudioMDL supports SMD and DMX skeletal-animation inputs.

When an animation compiles but behaves incorrectly, investigate the source skeleton before assuming StudioMDL is broken.

Typical causes include:

• mismatched bone names;
• incompatible skeleton hierarchy;
• incorrect transforms;
• wrong frame ranges;
• poor vertex weighting;
• animation exported against a different rig;
• incorrect FPS assumptions.

Test a single idle animation first. Once that works, add the remaining sequences.

How Maps Are Compiled for Source Filmmaker

Models are not the only assets that require compilation.

Source maps have their own pipeline.

An editable map typically starts as a .vmf and ultimately becomes a .bsp. Valve’s Source SDK documentation distinguishes VMF source maps from compiled BSP game content.

The traditional Source map build pipeline involves:

1. VBSP — processes map geometry and creates the initial BSP.
2. VVIS — calculates visibility information.
3. VRAD — handles lighting calculations.

These are map-compilation tools, not model compilers. Valve’s developer documentation lists VBSP, VVIS, and VRAD among Source’s map compilers while StudioMDL is listed separately as the model compiler.

This distinction matters when diagnosing a problem.

A broken custom character is not fixed with VRAD. A lighting problem in a custom map is not fixed by changing an SMD.

Common smf compile Errors and How to Fix Them

Compilation problems are easier to solve when you diagnose them by symptom rather than randomly changing settings.

Model does not appear

Check whether:

• compilation actually completed;
• the MDL and supporting files were created;
• $modelname points where expected;
• files are in a mounted content directory;
• SFM’s model-browser filters are hiding the model.

If the asset works in HLMV but not in SFM, investigate content paths and browser configuration before rebuilding the mesh.

Purple-and-black textures

Start with material paths.

Verify:

1. $cdmaterials;
2. VMT location;
3. $basetexture or relevant VMT references;
4. VTF filename and location.

Do not immediately re-export your geometry. A missing texture is usually a material pipeline issue rather than a mesh problem.

Model appears invisible

An invisible model can have several causes, including scale, material, mesh, export, or path problems.

Open it in HLMV.

If the model is invisible there too, move backward through the pipeline:

compiled output → QC → exported mesh → original model

Model is in a T-pose

A T-pose generally points toward animation or skeleton configuration rather than texture compilation.

Check the skeleton hierarchy, sequence definition, exported animation, and bone names.

Model is the wrong size

Correct scale in the source application whenever practical.

Applying random scale corrections at multiple stages makes the pipeline difficult to maintain, particularly when animations and physics are involved.

Compiler says a file cannot be found

Read the exact missing path.

Then check:

• spelling;
• file extension;
• relative path;
• QC directory;
• game configuration;
• export location.

Path errors are often straightforward once you stop reading the log as one giant block and identify the first meaningful failure.

PHY file is missing

Do not assume this means compilation failed.

StudioMDL’s documentation explicitly states that PHY collision data is omitted when no $collisionmodel is defined.

If your model does not need physics collision data for its intended use, this may be completely normal.

Crowbar vs StudioMDL

A frequent beginner question is whether Crowbar or StudioMDL is “better.”

They serve overlapping parts of the same workflow rather than representing two unrelated compilation systems.

StudioMDL	Crowbar
Valve’s model compiler	Graphical frontend/workflow tool
Command-line based	GUI based
Direct compiler control	Easier configuration
Useful for scripts/automation	Convenient for interactive work
Requires comfort with paths/options	More beginner-friendly

Valve’s documentation identifies StudioMDL as the command-line model compiler and Crowbar as a popular graphical frontend that also provides decompilation and other features.

For most newcomers, Crowbar makes the process easier to understand.

Learning what StudioMDL actually does is still valuable because compiler logs, QC files, input formats, and game paths remain relevant regardless of the interface.

Source 1 SFM vs Source 2 Filmmaker

Do not mix these pipelines.

The original Source Filmmaker uses Source technology, while Source 2 Filmmaker is a separate implementation available through tools associated with titles such as Counter-Strike 2, Dota 2, Half-Life: Alyx, and SteamVR Home Workshop Tools.

Source 2 also handles content differently.

Valve’s porting documentation notes that Source 2 uses formats such as .vmap, .vmat, and .vmdl, rather than the traditional Source 1 .vmf, .vmt, and .mdl equivalents.

So when following a tutorial, establish which engine generation it targets.

A guide mentioning QC, SMD, MDL, VMT, VTF, and the traditional StudioMDL workflow is generally discussing Source 1-style content.

A Source 2 workflow should not be treated as a drop-in replacement.

Is Rendering an SFM Movie Also a Compile?

People sometimes use the word “compile” loosely for final rendering, but exporting a movie is conceptually separate from compiling custom models or maps.

Source Filmmaker can export its 3D recording as a movie or still image.

Rendering time depends on factors such as:

• output resolution;
• scene complexity;
• lighting;
• depth of field;
• motion blur;
• sampling;
• hardware performance;
• total frame count.

Higher resolution can increase render time. Valve’s SFM rendering documentation notes, for example, that rendering at resolutions above the default 720p takes longer, particularly on lower-end hardware.

So keep the terminology clear:

Compile a model. Compile a map. Render/export a movie.

That simple distinction makes troubleshooting searches much more productive.

A Better smf compile Workflow for Beginners

The fastest workflow is not the one with the fewest steps. It is the one that makes failures easy to isolate.

Use this sequence:

1. Prepare and clean the model.
2. Verify UVs, armature, weights, and scale.
3. Export one basic SMD or DMX mesh.
4. Create a minimal QC.
5. Compile with StudioMDL or Crowbar.
6. Read the entire relevant compiler output.
7. Inspect the model in HLMV.
8. Fix materials separately from geometry.
9. Test a basic idle sequence.
10. Add advanced animations, bodygroups, flexes, collision, and other features gradually.
11. Load the finished model in Source Filmmaker.
12. Keep a working version before making major changes.

This approach prevents a common problem: trying to debug geometry, materials, bones, physics, flexes, and animations simultaneously.

Keep source and compiled files separate

Maintain a clean source directory for editable assets and a separate content structure for compiled output.

That mirrors the broader Source SDK philosophy of separating source content from game content.

Change one thing at a time

If a model suddenly breaks after five edits, you have five possible causes.

If it breaks after one edit, you know where to look.

This habit saves more time than memorizing dozens of compiler-error messages.

Keep the compiler log

Do not treat warnings as visual noise.

The log is part of the debugging process. Search for the earliest meaningful warning or error instead of focusing only on the final failure line.

Test before adding complexity

First goal:

Get a visible model into HLMV/SFM.

Second:

Make the materials work.

Third:

Make the skeleton and animation work.

Only then add optional complexity.

Practical Troubleshooting Checklist

When an smf compile project refuses to work, use a fixed diagnostic order.

If compilation fails:

• verify the QC syntax;
• confirm every referenced source file exists;
• verify SMD/DMX export;
• check the target game path;
• inspect the first meaningful compiler error.

If compilation succeeds but the model fails:

• confirm MDL/VVD/VTX outputs;
• open the asset in HLMV;
• verify its destination;
• inspect scale and geometry;
• check the model browser.

If the model works but textures fail:

• inspect $cdmaterials;
• check VMT location;
• verify VMT texture references;
• confirm VTF files exist.

If animation fails:

• verify bone names;
• check hierarchy;
• inspect vertex weights;
• confirm sequence definitions;
• test the animation independently.

This order matters. It prevents you from rebuilding a working mesh because of a typo in a material path.

Final Thoughts on smf compile

smf compile becomes much easier once you stop treating compilation as a mysterious SFM feature and see it as a predictable asset pipeline.

For Source 1 Source Filmmaker models, the core workflow is straightforward: prepare the model, export suitable SMD or DMX data, describe the model with a QC script, compile it through StudioMDL or a frontend such as Crowbar, verify the MDL/VVD/VTX outputs, prepare VMT/VTF materials, and test the result before building a full scene. Valve’s documentation confirms these core formats and tools as parts of the Source model pipeline.

When something fails, identify which stage owns the problem. Geometry and rigging belong upstream in the modeling/export process. QC and file errors belong around compilation. Purple-and-black surfaces point toward materials. VMF-to-BSP problems belong to the map toolchain. Final movie output belongs to rendering.

Once those stages are separated, smf compile stops being trial and error and becomes a workflow you can debug one step at a time.