SFM Compile: The Complete Guide (2026)

You spent hours modeling a character. The topology is clean. The textures are sharp.

The rig is solid. You drag it into Source Filmmaker and you’re staring at a purple-and-black checkerboard, or worse, nothing at all.

That moment of confusion is nearly universal among new SFM creators.

The problem is almost never the model itself. It’s the compile process and more specifically, not understanding what that process does, why it exists, and how to execute it correctly.

Source Filmmaker doesn’t read FBX or OBJ files. It speaks an entirely different language: MDL, VVD, VTX, PHY.

These are proprietary Source Engine formats, and converting your assets into them requires a compiler, a QC file, and a working understanding of how Valve’s asset pipeline actually functions.

This guide covers everything from first principles to advanced optimization.

Whether you’ve never compiled a model in your life or you’re troubleshooting a stubborn compile error at 2 AM, you’ll find something useful here.

By the end, you’ll understand the full SFM compile workflow, know which tools to use and when, be able to write and debug QC files from scratch, and have a reliable process for compiling models, animations, and maps.

No filler. No hand-waving. Just the real workflow.

What is SFM Compile?

SFM Compile refers to the process of translating raw 3D assets — models, skeletons, textures, animations — into the binary file formats that Valve’s Source Engine can read and render.

The Source Engine was built by Valve in the early 2000s as the backbone of games like Half-Life 2, Team Fortress 2, and Portal.

It does not natively support common 3D formats like FBX, OBJ, or GLTF. Instead, it uses its own proprietary formats optimized for real-time rendering, physics simulation, and animation playback.

Source Filmmaker, released publicly in 2012, runs on this same engine.

That means everything you want to use in SFM — every custom prop, character, or map — must first be compiled into Source Engine formats before the software can recognize it.

The key distinction: importing vs. compiling. Importing moves a file from one location to another. Compiling transforms it from one format into a completely different set of formats. Compilation is not optional — it’s a prerequisite.

Historically, Valve used this pipeline internally to compile assets for their own games.

The tools they built — StudioMDL, VBSP, VVIS, VRAD — were eventually included with Source SDK distributions, giving modders and creators access to the same pipeline.

Crowbar, a third-party front-end developed by the community, later made the process significantly more accessible.

The MDL pipeline in short:

Raw 3D Model (FBX/OBJ)
        ↓
Export to SMD or DMX
        ↓
Write a QC File (compiler instructions)
        ↓
Run StudioMDL / Crowbar
        ↓
Output: MDL + VVD + VTX + PHY + ANI
        ↓
Load in Source Filmmaker ✓

📌 Did You Know? Valve compiled hundreds of thousands of assets using this exact pipeline across their game library. Every TF2 character, every HL2 prop, every Portal cube went through StudioMDL.

Quick Facts Table

Property	Detail
Definition	Process of converting 3D assets into Source Engine binary formats
Primary Keyword	SFM Compile
Difficulty	Beginner to Advanced (depending on asset complexity)
Tools Needed	Crowbar, StudioMDL, Blender, Notepad++, VTFEdit
Input Formats	SMD, DMX, QC, VTF, VMT
Output Files	MDL, VVD, VTX, PHY, ANI
Best Compiler	Crowbar (GUI) or StudioMDL (CLI)
Platform	Windows
Typical Compile Time	2–30 seconds (simple props); 1–5 minutes (complex rigs)
Skill Level Required	Intermediate (basic text editing, file path knowledge)
Engine	Source Engine (not compatible with Source 2)

How SFM Compilation Works

Understanding the mechanics of compilation helps you troubleshoot errors much faster. Here’s what actually happens when you click “Compile.”

Raw Asset Stage

Every compile starts with source files — the assets you’ve created or acquired. These typically include:

A 3D model exported from Blender, Maya, or 3ds Max in SMD or DMX format
Texture files in VTF format (Valve Texture Format)
Material files in VMT format (Valve Material Type)
A QC file that tells the compiler how to assemble everything

The Compiler Stage

The compiler (StudioMDL) reads the QC file and uses it as a blueprint. It processes the model geometry, resolves bone hierarchies, packages animation sequences, links materials, and generates physics hulls — all in a single pass.

Output Stage

After compilation, StudioMDL writes several binary files:

MDL — the master model file, contains bone data, hitboxes, and model metadata
VVD — vertex data (positions, normals, UV coordinates)
VTX — optimized mesh strips for GPU rendering (DX90.VTX, SW.VTX)
PHY — physics collision data (only if $collisionmodel is defined)
ANI — external animation data (for models with many sequences)

All of these files must be present for SFM to load the model correctly. Missing even one will cause load failures or visual errors.

Text Workflow Diagram

[Blender / Maya]
      ↓ Export
[SMD / DMX Files]  +  [QC File]  +  [VMT / VTF Textures]
      ↓
[Crowbar / StudioMDL.exe]
      ↓ Compile
[MDL] [VVD] [VTX] [PHY] [ANI]
      ↓
[SFM Model Browser → Scene]

💡 Pro Tip: Keep your source files (SMD, QC, textures) in a dedicated _source folder separate from your compiled output. This keeps your workspace clean and makes recompiling far less chaotic.

Files Used During Compilation

Extension	Full Name	Purpose	Required?	Auto-Generated?	Common Errors
`.QC`	Compile Script	Blueprint for compiler	✅ Yes	❌ No	Typos, wrong paths, missing directives
`.SMD`	Studio Model Data	Mesh and animation geometry	✅ Yes	❌ No	Wrong scale, broken normals
`.DMX`	Data Model Exchange	Alternative to SMD (Valve format)	Optional	❌ No	Version mismatches
`.VTF`	Valve Texture Format	Compiled texture data	✅ Yes	❌ No	Wrong dimensions, missing mipmaps
`.VMT`	Valve Material Type	Material shader definition	✅ Yes	❌ No	Wrong shader, bad path
`.MDL`	Model File	Final compiled model	✅ Output	✅ Yes	Corrupt if compile fails mid-run
`.VVD`	Vertex Data	Vertex positions and UVs	✅ Output	✅ Yes	Missing = model invisible
`.VTX`	Vertex Cache	GPU-optimized mesh strips	✅ Output	✅ Yes	Missing = crash on load
`.PHY`	Physics Model	Collision and ragdoll data	Optional	✅ Yes	Wrong mass, broken joints
`.ANI`	Animation File	External animation sequences	Optional	✅ Yes	Out of sync with MDL

⚠️ Warning: Never manually delete individual output files and recompile only part of a model. Always recompile the full set to keep MDL, VVD, and VTX in sync. Mismatched output files cause crashes.

Software You’ll Need

Crowbar

Crowbar is a free, open-source GUI front-end for StudioMDL. It’s the recommended tool for most SFM creators because it eliminates the need for manual command-line input.

Advantages:

Visual interface with clickable compile options
Built-in log viewer for error diagnosis
Supports batch compilation (multiple QC files at once)
Can decompile existing MDL files for reference
Configurable to point to different engine versions

Disadvantages:

Still requires StudioMDL to be installed
Error messages mirror StudioMDL output (can be cryptic)
Occasional version-specific quirks

Rating: 9/10 — Essential for beginners. Recommended for all experience levels.

StudioMDL

StudioMDL is Valve’s official model compiler, included with Source Filmmaker in the bin folder. It’s the actual engine doing the compilation — Crowbar simply calls it.

Advantages:

Direct, authoritative output
Most detailed error messages
Useful for scripted or automated compile pipelines

Disadvantages:

Command-line only
Requires manual path management
Less accessible for beginners

Rating: 7/10 — Use it directly when you need fine-grained control or when debugging Crowbar issues.

Blender

Blender is the most widely used 3D modeling tool in the SFM community. It’s free, actively developed, and has several plugins specifically designed for Source Engine export (Blender Source Tools by Artfunkel being the most important).

Rating: 9/10 — The standard choice for most SFM creators.

VTFEdit

VTFEdit converts standard image formats (PNG, TGA, BMP) into VTF textures and generates VMT material files. Without it, your textures can’t enter the Source pipeline.

Rating: 8/10 — Indispensable for texture work.

Noesis

Noesis is a model viewer and converter that handles hundreds of formats. It’s particularly useful for converting non-standard source files into SMD-compatible formats before compiling.

Rating: 7/10 — Situationally very useful, especially when working with imported assets from other games.

GCFScape

GCFScape opens Valve’s VPK and GCF archive files, letting you extract assets from TF2, HL2, and other Source games. Great for studying compiled models and textures.

Rating: 8/10 — Excellent learning tool. Use it to extract and study Valve’s own compiled assets.

Wall Worm

Wall Worm is a 3ds Max plugin suite for Source Engine export. If you use 3ds Max professionally, Wall Worm is the fastest path to the Source compile pipeline.

Rating: 8/10 — Best-in-class for 3ds Max users.

Crowbar vs. StudioMDL: Which Should You Use?

Feature	Crowbar	StudioMDL
Interface	GUI	Command Line
Ease of Use	Easy	Intermediate
Error Output	Formatted log	Raw output
Batch Compile	✅ Yes	Manual scripting required
Decompile Support	✅ Yes	❌ No
Speed	Same (calls StudioMDL internally)	Same
Automation	Limited	Fully scriptable
Best For	Beginners, daily workflow	Advanced users, CI pipelines
Version Support	Multiple Source games	Engine-specific
Community Support	Large	Smaller

Verdict: Use Crowbar for day-to-day compilation. Use StudioMDL directly when you need to automate builds, troubleshoot Crowbar-specific issues, or script compile pipelines.

Understanding QC Files

The QC file is the heart of the compile process. It’s a plain text file that tells StudioMDL exactly how to build your model. Without a valid QC file, compilation cannot begin.

Here’s a breakdown of the most important QC directives:

`$modelname`

$modelname "props/my_crate.mdl"

This sets the output path for the compiled MDL file, relative to the models folder in your game directory. Get this path wrong and your model will compile to an unexpected location — or not be findable by SFM at all.

`$body`

$body "Body" "my_crate_reference.smd"

Defines the main geometry of the model. The first argument is an internal label; the second is the path to your SMD or DMX file. For complex models with multiple body groups (like characters with different cosmetic options), you’ll add multiple $body or $bodygroup entries.

`$cdmaterials`

$cdmaterials "models/props/my_crate/"

Points the compiler to the folder where your VMT material files live. If this path is wrong, Source Filmmaker won’t find the materials — resulting in the infamous purple-black checkerboard. This is the single most common cause of texture errors.

`$sequence`

$sequence "idle" "my_crate_idle.smd" fps 30

Defines animation sequences. The fps value controls playback speed. Static props don’t need sequences, but any rigged character should have at least an idle sequence.

`$collisionmodel`

$collisionmodel "my_crate_collision.smd" {
    $mass 50
    $concave
}

Adds physics collision data. The collision SMD should be a simplified version of your model — low-polygon and convex where possible. The $mass value affects how the physics engine treats the object.

`$surfaceprop`

$surfaceprop "wood"

Assigns a surface material type. This determines the sound effects played when the object is hit, shot, or walked on. Valid values include wood, metal, concrete, flesh, and others defined in surface_properties.txt.

`$staticprop`

$staticprop

Marks the model as a static prop — one with no animations or physics interactions. This enables additional GPU optimizations and allows the model to be baked into map lighting. Always use this for non-animated props.

Full Example QC File

$modelname "props/my_crate.mdl"
$cdmaterials "models/props/my_crate/"

$body "Body" "my_crate_reference.smd"
$collisionmodel "my_crate_collision.smd" {
    $mass 50
}

$surfaceprop "wood"
$staticprop

$sequence "idle" "my_crate_idle.smd" fps 30

💡 Pro Tip: Valve’s compiled models are a treasure trove of real QC examples. Use Crowbar to decompile any default TF2 or HL2 prop and study the QC file structure — it’s one of the fastest ways to learn.

Complete Step-by-Step SFM Compile Tutorial

Step 1: Plan Your Asset Pipeline

Before touching any software, decide what you’re compiling: a static prop, a rigged character, an animated sequence, or a map. Each has a different pipeline. This guide focuses primarily on models.

Step 2: Create or Acquire Your 3D Model

Open Blender (or your 3D software of choice). Build your model with Source Engine constraints in mind:

Keep polygon count reasonable (under 10,000 for props; under 50,000 for characters)
Use clean topology — no n-gons, minimal triangulation issues
Apply all transforms before export (Scale, Rotation, Location → Apply All)

Step 3: Install Blender Source Tools

Download the Blender Source Tools plugin from Artfunkel’s GitHub. Install it via Edit → Preferences → Add-ons → Install. This adds SMD and DMX export support to Blender.

Step 4: Set Up Your Rig (If Needed)

For animated models, create an armature in Blender using Source Engine bone naming conventions. The root bone should be named ValveBiped.Bip01_Pelvis for humanoid characters (if matching Valve’s skeleton). For custom rigs, any naming convention works — just stay consistent.

Step 5: Export Your Model as SMD

Go to File → Export → Source Engine SMD/VTA/DMX. Export the reference mesh as a separate file (e.g., my_model_reference.smd). If you have a collision mesh, export it separately (e.g., my_model_collision.smd).

⚠️ Warning: Always apply scale before exporting. A model exported at the wrong scale is a common beginner error. In Blender: Object → Apply → All Transforms.

Step 6: Prepare Your Textures

Create your textures in Photoshop, GIMP, or Krita. Save them as TGA or PNG files at power-of-two resolutions (256×256, 512×512, 1024×1024, 2048×2048).

Step 7: Convert Textures to VTF

Open VTFEdit. Go to File → Import and select your texture file. Configure the settings (DXT1 for opaque textures, DXT5 for transparent). Save as a VTF file in your materials folder.

Step 8: Create VMT Material Files

For each texture, create a matching VMT file. A basic VMT looks like this:

"VertexLitGeneric"
{
    "$basetexture" "models/props/my_crate/diffuse"
    "$surfaceprop" "wood"
}

Place VMT files in the materials folder matching the path specified in $cdmaterials.

Step 9: Organize Your Folder Structure

steamapps/common/SourceFilmmaker/game/
├── models/
│   └── props/
│       └── my_crate.mdl (output)
├── materials/
│   └── models/
│       └── props/
│           └── my_crate/
│               ├── diffuse.vtf
│               └── diffuse.vmt
└── _source/
    ├── my_crate_reference.smd
    ├── my_crate_collision.smd
    └── my_crate.qc

💡 Pro Tip: Keep all source files (SMD, QC) in a _source folder outside the compiled output directories. This prevents confusion between input and output files.

Step 10: Install and Configure Crowbar

Download Crowbar from GitHub. Open it and navigate to the Set Up Games tab. Add Source Filmmaker as a game and point it to studiomdl.exe in the SFM bin folder. Verify the path is correct before proceeding.

Step 11: Write Your QC File

Create a new text file in Notepad++ and write your QC directives (see the QC Files section above). Save it as my_crate.qc in your _source folder.

Step 12: Validate QC Paths

Before compiling, manually check every file path in your QC file against your actual folder structure. Paths in QC files are case-sensitive on some systems. A single mismatched filename will stop compilation.

Step 13: Open Crowbar and Load Your QC File

In Crowbar, click the Compile tab. Click Browse next to the QC file field and select your QC file. Verify the game configuration is set to Source Filmmaker.

Step 14: Run the Compile

Click Compile. The log window will display real-time output from StudioMDL. Watch for lines beginning with ERROR: or WARNING:. A successful compile ends with QC files compiled OK.

Step 15: Check the Compile Log

Even a successful compile may show warnings worth addressing — things like missing LOD references or unused bones. Note any warnings and decide whether they require action based on your use case.

Step 16: Locate the Output Files

Navigate to your models output folder and confirm that MDL, VVD, VTX, and (if applicable) PHY files were generated. If any are missing, the compile failed partially — check the log for the cause.

Step 17: Load the Model in SFM

Open Source Filmmaker. In the Model Browser, navigate to your model’s path. Load it into a scene. Check that it appears correctly with no missing textures, distorted geometry, or visual artifacts.

Step 18: Test Animations and Physics

If your model has animations, scrub through the sequences to verify playback. If it has physics (ragdoll or prop physics), test it in the physics simulation. Broken bones or jittery physics are usually signs of a malformed collision model.

Step 19: Fix and Recompile

Address any issues, fix the source files or QC, and recompile. Always recompile the full model — never replace individual output files manually.

Step 20: Archive Your Source Files

Once the model works correctly, create an archive of your source files (SMD, QC, source textures). Include a README with notes on the compile configuration. Future-you will be grateful.

Compiling Models

Model compilation is the most common SFM compile task. Here are the key considerations and best practices specific to model assets.

Common mistakes during model compilation:

Exporting with incorrect scale (most often seen as a model that’s 100× too large or too small)
Leaving n-gons in the mesh (StudioMDL expects triangulated or quad geometry)
Forgetting to apply transforms in Blender before export
Using texture dimensions that aren’t powers of two
Listing incorrect material paths in $cdmaterials

Optimization tips:

Keep polygon counts as low as possible without sacrificing visual quality
Use LOD (Level of Detail) models for props that appear at varying distances
Merge mesh elements where possible to reduce draw calls
Use a single material where feasible — multiple materials mean multiple draw calls per model

Compiling Animations

Animation compilation follows the same pipeline as model compilation, with some important additions.

How Animation Compiling Works

Animations are embedded in the compiled MDL file through $sequence directives in the QC file. Each sequence references an SMD or DMX file containing animation keyframes.

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

The loop flag tells the engine to loop the animation seamlessly. Remove it for one-shot animations like death sequences.

DMX vs. SMD for Animations

Feature	SMD	DMX
Human Readable	✅ Yes	Partially
Animation Curves	Limited	✅ Full support
Facial Animation	❌ No	✅ Yes
Blender Support	✅ Full	✅ Full
Valve Preference	Older	Modern
Flexes/Morphs	❌ No	✅ Yes

Recommendation: Use DMX for character animations (especially facial animations). Use SMD for simple prop animations or when working with older plugins.

💡 Pro Tip: SFM’s internal animation system (using the DMX-based session format) is separate from compiled model animations. Model animations (compiled via QC) are baked sequences. SFM’s timeline lets you blend and layer these.

Compiling Maps

Map compilation uses a different set of tools than model compilation. Source maps go through a three-stage compile process.

Stage 1: VBSP (Visibility Binary Space Partitioning)

VBSP converts your Hammer Editor map (VMF format) into the BSP binary format. It splits the world geometry into a tree structure that the engine uses to determine visibility and rendering order.

Stage 2: VVIS (Visibility)

VVIS calculates the Potentially Visible Set (PVS) — which areas of the map can see which other areas from any given point. This dramatically reduces rendering load at runtime. VVIS is the most time-consuming compile stage for complex maps.

Stage 3: VRAD (Radiosity)

VRAD calculates static lighting and shadows. It bounces light around the scene (radiosity) to produce realistic indirect illumination. VRAD is computationally expensive — full compiles of large maps can take hours.

Fast Compile vs. Full Compile

Stage	Fast Compile	Full Compile
VBSP	Same speed	Same speed
VVIS	Approximate PVS	Precise PVS
VRAD	Low-quality lighting	Full radiosity
Time	Minutes	Hours
Use For	Testing	Final build
Lighting Quality	Draft	Production
HDR Support	❌	✅

⚠️ Warning: Never ship a map compiled with fast compile settings. Fast-compile lighting is for iteration only — it looks noticeably worse and won’t render correctly in some lighting scenarios.

Common SFM Compile Errors

Error	Meaning	Cause	Solution	Difficulty
Purple-black checkerboard	Missing texture	Wrong `$cdmaterials` path or missing VTF	Fix path in QC; ensure VTF exists	Easy
`ERROR: c0001` (file not found)	SMD file missing	Path in QC doesn’t match actual file location	Fix file path in QC	Easy
Model appears at wrong scale	Scale mismatch	Transforms not applied before export	Apply all transforms in Blender before export	Easy
`WARNING: empty sequence`	No animation data	SMD animation file is blank or incorrectly exported	Re-export animation from Blender	Medium
Bones don’t move	Bone naming issue	Bones not named correctly or hierarchy broken	Check armature against Source conventions	Medium
`ERROR: Exceeded max verts`	Model too complex	Polygon count exceeds Source Engine limits	Reduce polygon count or split model	Medium
Model invisible in SFM	Missing VVD file	Compile failed mid-run	Recompile; check for errors in log	Easy
SFM crashes on model load	Corrupted MDL	Partial compile or disk error	Delete all outputs and recompile fresh	Medium
`ERROR: physics model not valid`	Bad collision mesh	Collision SMD has open edges or too many polys	Simplify and close collision mesh	Medium
Material not found	VMT missing	VMT file not in correct folder	Place VMT in path matching `$cdmaterials`	Easy
Texture seams visible	UV issues	Incorrect UV unwrap or VTF compression artifacts	Fix UV map in Blender; try DXT5 compression	Medium
`ERROR: too many bones`	Bone limit exceeded	Model has more than 128 bones	Merge or remove unnecessary bones	Hard
Ragdoll explodes in physics	Bad PHY	Collision model intersecting with itself	Simplify physics mesh, check for overlaps	Hard
Animation plays at wrong speed	FPS mismatch	`fps` value in QC doesn’t match export	Match FPS in QC to Blender export settings	Easy
`WARNING: no LOD`	No LOD defined	Model has no level-of-detail meshes	Not an error; add LODs for optimization	Low
Model z-fighting	Overlapping polygons	Two surfaces occupying same space	Separate overlapping geometry	Medium
Wrong material assigned	Material ID mismatch	Face groups not matching VMT order	Check material slots in Blender	Medium
Flexes not working	Flex compile error	DMX flex data not correctly formatted	Re-export flexes from Blender Source Tools	Hard
`ERROR: studiomdl not found`	Crowbar misconfigured	StudioMDL path not set in Crowbar	Set correct studiomdl.exe path in Crowbar	Easy
Compile hangs indefinitely	Infinite loop in QC	Circular reference or corrupt SMD	Check QC for self-referencing sequences	Hard

🔧 Quick Fix: When you get a compile error you don’t understand, paste the exact error message into Google or the Valve Developer Community wiki. The VDC has documented almost every StudioMDL error.

Beginner Mistakes to Avoid

Not applying transforms before export. This creates scale and rotation issues that are confusing to debug.
Writing QC paths from memory. Always copy-paste paths directly from your file explorer.
Using texture sizes that aren’t powers of two. VTFEdit will accept them, but Source Engine will reject them or render them incorrectly.
Compiling everything at once before testing anything. Compile in stages — model first, then textures, then animations.
Ignoring warnings in the compile log. Warnings often become errors in a future compile after a change.
Deleting source SMD files after a successful compile. You’ll need them every time you recompile.
Putting spaces in file or folder names. Source Engine has inconsistent handling of spaces in paths. Use underscores.
Using the wrong shader in VMT. VertexLitGeneric is standard for models. LightmappedGeneric is for maps. Using the wrong one causes rendering issues.
Forgetting $staticprop on non-animated models. Missing this flag wastes GPU resources.
Skipping the collision model. Models without PHY data can’t interact with physics in SFM.
Using too many materials on a single model. Each material is a draw call. Merge materials where possible.
Not testing in SFM after every major change. Discovering errors early means fixing only one thing at a time.
Copying QC files without updating paths. Every QC has unique file paths. A copied QC template will fail unless every path is updated.
Exporting animated models as static. If your model needs animation, don’t use $staticprop.
Not studying existing working models. Decompile a Valve model with Crowbar. Read its QC. Copy its folder structure. This shortcut saves days.

Best Practices for Clean Compile Workflows

Folder Organization

Maintain a strict separation between source files and compiled output:

_workspace/
├── _source/
│   ├── models/
│   ├── textures/
│   └── qc/
└── output/
    ├── models/
    └── materials/

Naming Conventions

Use lowercase letters only
Replace spaces with underscores (my_crate not My Crate)
Prefix related files with a shared name (player_idle.smd, player_walk.smd, player_run.smd)

Texture Optimization

Use DXT1 for opaque textures (4:1 compression, no alpha)
Use DXT5 for transparent textures (higher quality alpha)
Keep specular maps in the alpha channel of the normal map where possible
Use 512×512 for small props; 1024×1024 for hero assets; 2048×2048 sparingly

Polygon Limits (Recommended)

Asset Type	Recommended Poly Count
Small Prop	Under 2,000
Medium Prop	2,000 – 8,000
Character	8,000 – 25,000
Hero Character	Up to 50,000
Collision Mesh	Under 500

Version Control

Use Git or a similar version control system for your source files. Tag each successful compile with a version number. This lets you roll back when a new change breaks a model that was working.

Backup Strategy

Keep at least three copies of your source files: local, cloud (Google Drive or similar), and an occasional offline archive. Compiled output is reproducible from source files — but the source files themselves cannot be recovered from compiled output alone (decompilation is lossy).

Advanced Optimization Tips

LOD (Level of Detail)

LOD models automatically swap to lower-polygon versions as the camera moves further away. This massively improves rendering performance in complex scenes.

$lod 400
{
    replacemodel "my_model_reference.smd" "my_model_lod1.smd"
}
$lod 800
{
    replacemodel "my_model_reference.smd" "my_model_lod2.smd"
}

LOD distances are in Source units (approximately 1 unit = 1.9 cm).

Physics Optimization

Keep collision meshes as simple as possible. For box-shaped objects, use a single convex hull. For complex shapes, use $concave sparingly — concave collision is significantly more expensive to simulate.

Animation Optimization

Group similar animation sequences and use $weightlist to limit which bones animate during specific sequences. A walk animation that animates facial bones wastes processing time.

Material Batching

Where possible, combine multiple textures into a single atlas texture. One draw call per model is ideal. Every additional material multiplies the rendering cost.

Compile Speed

For large projects with many models, use Crowbar’s batch compile feature to process multiple QC files in a single session. Pair this with a consistent folder structure and you can recompile an entire asset library in minutes.

Checklists

✅ Beginner Checklist

Blender Source Tools installed and configured
Crowbar installed and pointed to correct studiomdl.exe
VTFEdit installed
SFM installed and confirmed working
First simple static prop modeled and exported
VTF textures created and placed correctly
VMT files created with correct shader
QC file written with correct paths
First compile attempted
Model loaded and verified in SFM

✅ Pre-Compile Checklist

All transforms applied in Blender
SMD/DMX files exported correctly
All texture paths correct and files present
QC file paths verified against actual folder structure
No spaces in any file or folder names
StudioMDL path correct in Crowbar
Output directories exist and are writable
Previous compile outputs cleared (for clean recompile)

✅ Post-Compile / Troubleshooting Checklist

Compile log reviewed for errors and warnings
All output files present (MDL, VVD, VTX, PHY if needed)
Model loads without crash in SFM
No purple-black checkerboard textures
Animations play at correct speed
Physics behaves correctly
No visible z-fighting or mesh artifacts
Bones move correctly

✅ Optimization Checklist

Polygon count within recommended limits
LOD models created for props used at distance
Textures use correct compression format
Collision mesh is simplified
$staticprop used on non-animated props
Material count minimized
No unused bones in rig
Source files archived and backed up

Frequently Asked Questions

What is SFM Compile, exactly?
SFM Compile is the process of converting raw 3D assets into the binary formats (MDL, VVD, VTX, PHY) that Valve’s Source Engine requires. Source Filmmaker cannot load models in standard formats like FBX or OBJ — compilation is mandatory.

What’s the difference between Crowbar and StudioMDL?
StudioMDL is the actual compiler — it does the work. Crowbar is a graphical interface that calls StudioMDL for you, so you don’t have to use the command line. Most creators use Crowbar; StudioMDL is used directly for advanced automation.

Why does my model show a purple-black checkerboard?
This means SFM can’t find the material files. Check your $cdmaterials path in the QC file and confirm your VMT and VTF files exist in the exact matching folder.

Can I compile FBX files directly?
No. StudioMDL does not support FBX. You must first export your model from Blender (or Maya/3ds Max) to SMD or DMX format using the appropriate export plugin.

Does SFM Compile work with Source 2?
No. Source 2 uses a completely different asset pipeline with different tools and formats. SFM runs on Source 1, and its compile tools are not compatible with Source 2 assets.