Source Filmmaker is a popular program for creating animations and pictures, due to the accessibility and the massive library of models available across all Source games. Unfortunately, it's had its last update in January 2015, leaving it in a perpetual alpha state while Valve's worked on its other properties. Incompatibilities with modern operating systems, instability, poor performance and a whole host of other issues are to be expected, but no less annoying to deal with.

This guide lists SFM issues, starting from mundane or simple troubleshooting, then making its way to more convoluted errors, where knowledge of the Source engine becomes important. Each issue will have its symptoms described and any known causes will be shown; following that will be either proper solutions or attempts to work around the problem, and then, when applicable, an extra source such as a guide will be linked for further reading.

Please note that I will not be held responsible in the event of further problems that occur in troubleshooting. On the other hand, if you require further assistance, please refer to the forums - more info can be found at Section: I1.

Happy troubleshooting!

This guide is now structured, such that problems with similar symptoms or root causes are indexed appropriately and sorted by roughly escalating complexity in troubleshooting. Use this as a means to quickly search for the topic that may be relevant to your issue.

Alternatively, there is always the option of Ctrl + F

Ensure that the errors you encounter aren't caused by inadequate hardware.

SFM is appeased with a quad core processor of any kind, 8+ GB of RAM (4GB is technically enough, but only if you close every other program running), any dedicated video card from the last 10 years, 20GB of storage for itself, and Windows 7 or later as the operating system.

SFM scales with better hardware, but encounters diminishing returns soon.

• CPU clock speeds are more important than core counts, but anything beyond 3GHz per core is gonna be about as fast as it gets.
  
  
• Extra RAM past the minimum changes nothing, same with memory speeds. SFM is a large address aware x86 program, meaning the most it can use is 4GB of memory before it crashes under its own weight.
  
  
• GPUs are where improvements will happen, and anything from an Nvidia GTX 480 and above will get increasingly better at fluid editing. If it can be helped, avoid using integrated Intel HD graphics - it's likely to still work, but workflow will suffer, to say nothing of the visual quality. Modern AMD APU graphics could work better, but SFM works best with a discrete GPU.
  
  It's required to have a GPU that at least supports DirectX 9.0 Shader Model 3.0 or better, otherwise you'll receive an error message upon startup, stating your system does not meet the minimum requirements.
  
  If you have a system with multiple GPU's and one does in fact support DirectX 9.0, you can tell the program to use that GPU instead of the unsupported one. Follow instructions outlined in A6. Skip the part where you use the console to check the GPU, since SFM can not be launched in the current stage to do so.
  
  
• SSDs can slightly improve model viewer loading times, but actual performance when editing is largely unaffected.
  
  
• Windows 10 is obviously recommended currently, for security and performance reasons, but SFM may show more issues with it, such as the blinking viewport.

A worthwhile attempt to fix problems relating to missing elements, but far from a comprehensive solution.

Occasionally files aren't in the right place, or plain and simply aren't there at all. Thankfully, Steam has a handy function to search through the installed program/game directory and redownload missing or damaged files, and this can prove useful in some cases for us SFM users.

To verify Source Filmmaker's file integrity:

If it finds missing files, allow it to download those which it will do automatically. When it's finally done, relaunch SFM and see if it works then.

Note: The Steam UI for Game Properties has since updated, but the process is still the same.

One of the most common errors encountered in SFM running on Windows 10 is a flickering viewport: the preview window flickers black repeatedly as you update it by, say, moving the camera around.

There is no permanent fix, but several workarounds have been found.
Note: make sure your graphics card drivers are up to date.

• While SFM is running, go to the Windows dropdown -> Engine Window -> click "Auto Hide Engine Window" to disable (if enabled) or enable (if disabled)
  
• While SFM is not running, right click Source Filmmaker in your library, go to Properties -> Set Launch Options -> add the line
  -usevgui
  and click OK

Either of those methods will have the same end result: an extra, primitive editing window may or may not appear while SFM is running (which you can ignore if it does exist, but shouldn't close, as that closes the whole program!), but more importantly your flickering should go away.

This problem is so widespread that a thread on the discussions page has been pinned. For further reading and possible alternate solutions, see here:
Blinking/Flickering Viewport: Possible Cause and Solutions

On the off chance your computer is blocking you from running SFM, you might need to allow permissions for it manually via the Firewall settings.

Start -> type: Allow firewall and select "Allow an App through Windows Firewall" Scroll down the allowed apps list until you find SourceFilmMaker. If the box is not ticked, go to Change Settings and then tick it. Go to click ok to close and confirm the setting.

To make sure it 100% worked, restart the computer and try to run SFM again.

Sometimes, SFM may open up with an unfamiliar and seemingly broken interface. If you can see dropdown menus with orange text at the top of this window, then it's the vestigial Engine Window instead of the normal SFM interface. In this scenario, you can return to the normal editor like so:

Select the Windows dropdown, then select QT Port.

You should then see the normal editing interface reappear. If the interface does return but it still looks blank, go to the Window dropdown -> Layouts -> select Return to Default Layout.

Credit to Pte Jack for his contributions. Details can be found in this other guide:
https://steamproxy.net/sharedfiles/filedetails/?id=155991324

Most higher performance laptops, and a few desktop computers (depending on components), have two choices of graphics cards to run programs with:

• Integrated (such as Intel HD)
  
• Dedicated (Nvidia or AMD)

Cause:
Sometimes after an update comes around, a switch can get flicked and fools SFM into using the less efficient component for the job. This becomes more of an apparent issue when newer hardware gets added to the equation and SFM may not recognize such devices as the program ages.

How to check which one is being used in SFM:
Go to "Windows" -> "Console" and type:
This wipes all console history prior to that point so you don't get stuff mixed up with other junk.

Next, type:
Scroll all the way to the top for your driver information. This tells which GPU is being used by SFM.

Example:

If SFM is using the dedicated graphics card, you don't need need to do anything, you're all set. However, if the program is still being unresponsive or acting up, you've at least eliminated one probable cause.

If the wrong graphics card is being used, you'll need to set the software to use the correct card. Not doing so will lead to a sub-optimal experience.

Workaround for systems with Nvidia GPU:
Start by right clicking the Desktop and access the Nvidia Control Panel.

From the "Select a Task..." menu, 3D Settings -> Manage 3D Settings. To the right of the window, select the tab labelled "Program Settings" and click on "Add."


This process takes a little while for Nvidia to search all of your currently installed programs on the machine and may take several minutes.

Once the window pops up to "Select a program:" you can go ahead and look for "sfm.exe" and click "Add Selected Program." This will allow you to customise and override the settings for SFM.




In the box below, find the option for "OpenGL rendering GPU" and change it's "Use global setting" to the preferred GPU you want SFM to utilize.


Click "Apply" and Restart Computer.

We've been here before. You remember it running fine the previous day, but now its performance drastically worsened. This could be due to several reasons.

But hold on, if that were the case, how is it that I could run it before?

SFM will still try to run on suboptimal hardware, though understandably it will struggle. Especially if you have an integrated graphics card, you'll have to turn off lighting, ambient occlusion, and make compromises elsewhere to ensure you can deliver your product at all.

On the other hand, Windows, driver and other software updates may also cause issues on systems that comfortably meet the requirements. These may also, on the other hand, improve SFM performance; your mileage may vary, but there's little one can do in this situation regardless.

As scene complexity rises, performance goes down sharply. Even if your system is overkill for even modern games, let alone SFM, a few dozen/hundred models or particles, or a small number of especially high definition models, can bring performance to a near standstill. Certain models acquired from the workshop have gathered notoriety for being surprisingly intensive for the program to display.

If you absolutely must have them, the easy solution is to turn the visibility of those models OFF so SFM does not have to render them all at the same time: click on the eye icon to the left of the suspect models, particles or lights, to turn them invisible and continue working. Remember to re-enable them before preparing to export!

For the uninitiated, launch commands are additional parameters input through Steam itself (or through a config file, or through an executable shortcut with additional lines...) and before running the game or program. For SFM, these allow for specific behaviours, or force additional visual effects - and some of them come with steep performance costs.

To check if you have any Launch Commands enabled, right click SFM, go to Properties and you'll see a button saying "Launch Commands." Clicking it will bring the window up where you can insert commands. Most commands don't have any effect on performance, but the biggest culprits are or , which force the viewport to render at 1080, respectively UHD 4K resolution. Remove those commands, click OK, and you should get back performance in SFM.

Sometimes, even if everything else about the system and the program is fine, trying to load a map will have it hang with the "Loading Map..." red text.

In the console tab, you can see messages along the lines of:

"UDP" stands for: User Datagram Protocol.
It is a communication protocol used to establish connections for applications on the internet. SFM is communicating with Steam's network with the UDP local port: 27015

Source: https://support.steampowered.com/kb_article.php?ref=8571-GLVN-8711

"Heartbeat" is a ping sent to the Steam Servers when hosting your own server that tells information about your IP, amount of players, ping time, ect. The command auto runs every 30 seconds. Much more helpful in actual games like TF2 - it is vestigial in SFM, thus safe to ignore.
Source: https://developer.valvesoftware.com/wiki/Heartbeat

Cause:
It is possible your firewall is blocking Steam from reaching the port "27015" and requires you to give it permission to run its protocol, or there is another application that has already taken up the port and is blocking other programs from accessing it.

According to this post, Apple has used the same port: https://discussions.apple.com/thread/1560597

Solution:
To find out what applications are using this specific port, exit out of SFM and open Command Prompt (as Admin) and type in:
This will search for all the current TCP and UDP's. Then, search under "Local Address" for a UDP port "27015", ignore the IP address that comes before it. You can find out what application is using this port from looking at the PID (Stands for: Process Identifier.)


Once you have found the culprit, you can open "Task Manager" and track down the program that is currently running under that PID. If you do not have the PID tab already, right click on any of the top category names (e.g. Name, Status, CPU, ect.) and click on PID.

Once you have located the program matching the process identifier, as long as it's not a necessary function of the PC itself you can go ahead and "End Task" for that Application/Process. The protocol should now be free for Source Filmmaker to use and all maps should hopefully load up now.

Believe it or not, but this can actually solve many of the problems you may encounter in SFM. Save your work, exit the program and relaunch. Even if it doesn't work, it never hurts to try.

CTRL + F1 to Restore Layout to Default. If that doesn't work: Windows > Layout > Default.

Still lost? Try this:
https://steamproxy.net/sharedfiles/filedetails/?id=1441432181

A few users on SFM Discussions have stated that Usermod is a security hazard which can potentially render the program unusable, though none have been verified as of yet. A more tangible effect that adding content into Usermod is that categorizing and managing said content will prove more difficult; instead of being sorted by author, type of models, or anything else, they're all just lumped into the "materials" and "models" folders, sometimes with non-descriptive names.

Guide to Installing Non-Workshop assets:
Access your game folder here:
Note: The Steam UI for Game Properties has since updated, but the process is still the same.

Go into the Games folder and make sure you can see SFM.exe. Create a new folder and name it something (that isn't already there) and give it the following sub-folders inside that:

• models
  
• materials
  
• maps
  
• sounds
  
• particles

Next, open the SDK and check off your new folder:


Place your custom assets into the newly created game folder and you're done. Be sure to untick the folder via SDK when not in-use.

The next time you open the program, the usual splash screen and create/open session dialog will appear, but the main engine window may not show. When maximizing or minimizing the window via the taskbar, it's possible the window is displaying outside of your monitor, but you can not drag it into view. Restarting the program changes nothing.

Cause:
Usually a case where the user had a previous setup of multiple monitors, then disconnects one after having used SFM. The program will attempt to draw the main window on a monitor that doesn't exist anymore.

Solution:

For Windows 10:
Windows key + Tab. Right click the Source Filmmaker window and select to snap on either side of the desktop. You can now return to the desktop view and freely adjust SFM's window.

or

Windows key + Shift and while holding down these keys, right click SFM from the task bar and select: Restore all Windows.

If that doesn't work, try this:
Connect the other monitor back. You can now drag the window back onto your main display. SFM will now remember which monitor to display on in the future.

Note:This issue should not occur on Windows 11 where programs now minimise whenever a monitor has been disconnected.

This message is triggered after a few attempts of trying to manipulate anything from within the scene while in "Clip Editor" mode.

This is down to a case where the user simply needs to switch to either Motion or Graph editor mode, as the message implies, then you can edit things again.

Not sure how? You can get a refresher on our other guide and see what the different modes are for:
https://steamproxy.net/sharedfiles/filedetails/?id=1826909237

Something pointed out by LazyPurple. Some TF2 maps may have missing features, such as the floating windows on the map Badwater where buildings would presumably be.


Cause:
The Buildings in question are separate entities themselves and are disabled by default.

Solution:
Right click the Viewport -> Draw Game Entities -> Other Entities.

So you went ahead and downloaded your model, you load it into the scene and... it does not show up at all, except for the bones when you hold CTRL and mouse over the viewport.

This is caused by either one of two things.

• The .mdl file is not named properly and thus, SFM becomes confused.
  
• The .mdl file that SFM is trying to locate is not in the correct folder search path it was instructed to look in.

How can you find out which problem is specific for you?

Go to Console and type Clear to get rid of any junk already there.
Right Click Animation Set Editor -> Load Animation Set for New Model and search for your model, then highlight it (However, do not load it!). The console should now be showing errors specific to that model you have selected. You should write it down somewhere to keep note of it.

The errors will either display something akin to:
or

Solution to scenario 1
You should compare the file paths from the error to what it says in your model viewer window, because chances are, something ain't quite right there.

If the error is displaying the search path as:
however in the model viewer it says:

It means the SFM can not locate the file because it is trying to search for the model under a different name, the name of which the error is displaying, (which in this example case would be model_X.mdl). Locate the file and rename it to that. Problem fixed.

Solution to scenario 2
Sometimes SFM may be looking in a completely different spot to where the model actually is located.

If the error is displaying the search path as:
however in the model viewer it says:
In this case, you will need to locate model_X and place it manually within the correct search path. Some Garry's Mod models come with extended search paths and need to be trimmed for SFM to be able load them up at all. However tedious, it's well worth the effort.

Guide for further help: https://steamproxy.net/sharedfiles/filedetails/?id=1226526147

There's a chance whenever you install more models, whether from the workshop or other sources, that they will look like this:


Cause
Usually, a result of the .VMT trying to use a shader that SFM does not support. When file names conflict with each other, it is possible for it to be replaced with the unsupported model, thus causing weird wireframe artifacts to occur in-engine.

Workaround
Remove the broken files, then resubscribe to any workshop items that were sharing conflicting names with the broken files.

The Search path game folder with the workshop item should have a higher priority than that of any other .VMTs with conflicting file names via the SDK.

For a more in-depth read on shaders: https://developer.valvesoftware.com/wiki/Shader

If you're lucky, It's possible the uploader may have already posted a fix for the original broken .VMT

The model disappears entirely when the camera looks away from a certain point on the model. Sometimes the difference in angle and position can lead to an otherwise clearly visible prop turning invisible in a jarring way. This can be a culprit of two things:

Small models in SFM can cause the weird phenomenon of the model disappearing when viewed at from certain angles. However, this only takes place once the model has been scaled up a significant amount. Scaling the Pelvis instead potentially reduces the effect, but is far from ideal.

Solution:
The model in question needs to be upscaled in a 3D modelling program, such as Blender. The transforms need to be re-applied before exporting back to SFM.

Garry's Mod assets have more aggressive culling. In Gmod this is acceptable for performance reasons, as it's a game. However, it's more inconvenient when ported over to SFM.

Workaround:
Before we get started, it's important to note disabling culling may create another problem, where light hitting the object may bleed through to the other side of it, almost like the effect you see when light penetrates through fabric. Caution is advised!

You'll need:

• Notepad++
  Link to download: https://notepad-plus-plus.org/downloads/

Locate the .VMT(s) of the model within the "Materials" file. By Default, usually found here:

Once found, open with Notepad++ and add:
Save the .VMT (and if there are multiple .VTMs, rinse and repeat for all of them) then reload SFM. In theory, that should of done the trick to eliminate the model disappearing. However, as stated before, this can still present its own issues and may still not give a satisfactory result in the end.

For further reading:
https://developer.valvesoftware.com/wiki/$nocull

For those who are 3D modellers out there looking to create custom assets for the Source Engine, be aware of the limitations of the program. The same can apply if porting a model from another game.

Source Filmmaker itself actually can handle high poly meshes just fine, the real issue is the model compiler itself has a rather restrictive limit on how many vertices can be allowed on a single object - the closer to the limit, the more things will struggle as model complexity rises. If that limit is exceeded, StudioMDL will bug out and create multiple pieces of that object. There is no concrete way of knowing when exactly or where that limit is per mesh.

Workaround:
No bodygroup object can have more than 30,000 vertices! Keep below this limit and you should not have much issues. Although keep in mind, in some cases you maybe able to get away with higher.

It's possible to increase the overall limit of vertices via including a string command within the .QC file:
This will allow the compiler to go to it's upper limit with vert count, however it should go without saying, it is not certain how well the program will tolerate the model itself when loaded into a scene with this much complexity. You should ultimately prepare yourself as the program may crash a lot more often as a result of this.

Note #1 If you're creating a character with multiple bodygroups, this will only apply when 1 or more mesh pieces of that character exceeds the limit threshold. You can have a character made of separate bodygroups that overall exceed the limit with no issues as long as each piece is under the maximum limit of vertices.

Note #2 While SFM may not have a finite limit on vertices, something to be of real mindfulness is the limit on materials per model. No model can have anymore than 32 materials assigned. You probably would want to avoid a large amount of materials anyway if they are high resolution as this is usually the culprit for large memory consumption.

SFM does not like duplicate models - in this case, downloading a Workshop variant of a model you may have in usermod will not let you use the Workshop model, assuming all its files and materials are in order. This can happen even with your own model submission!

Solution:
Delete or move the files of that model (along with it's materials) out of usermod. SFM will then give you access to the copy in the Workshop folder.

Our familiar friend from Garry's Mod. This is usually caused by incorrect or missing materials for your map or models. Badly named .VTF and .VMT files associated with the map/model may also be to blame, even if the folders are correct.

Solution:
Go to Console and type:
to get rid of any junk already there.

Right Click Animation Set Editor -> Load Animation Set for New Model and search for your model, then highlight it (However, do not load it!) The Console should now be showing errors specific to that model you have selected. You should write it down somewhere to keep note of it.

The errors will similar to:
This list can be quite extensive depending on how many bodygroups your model contains.

Next, locate where your .VTF and .VMT files actually are. Materials are kept within a different location to your models .MDL files. Let's say for example they are in this search path:
Did you catch that? According to the error, it is trying to locate the materials in a folder named "model_X" however we can see within the search path in file explorer, it is named "model_Y" and thus, needs to be corrected.

Before you try to load the model up again and assume the problem is fixed, let's actually have a look in said material folder and see if there are any problems in there:



As it turns out, the .VMT files do not match the same name as the ones shown in the error!

For example:
One of the .VMTs the program is looking for needs to be named "body_X" as shown in this error:

However in the actual materials folder, it is named "body_Z" and thus, needs to be corrected, along with all the other .VMT (and .VTF files if applicable) so SFM can properly search these and apply them to the model in-engine.

Once you have done all that, your model should be be presented with its proper materials within SFM. If the program is still running, type in command:
This will reload all Materials within the scene and should apply to your model.

Guide for further help: https://steamproxy.net/sharedfiles/filedetails/?id=1226795892

All
Beards
Are
Fu♥♥♥d
~LazyPurple

When using assets from a later version of TF2 than the one already on SFM (for the record, anything beyond very early 2008), the cosmetic beard items will be subject to their own manifestation of texture/rendering errors: neon or disappearing beards. The flashing neon issue can be mitigated by removing the frames from the exported Image Sequence animation that contain the weird phenomenon, but it can take absurd amounts of time to resolve and is far from a practical solution!

This mainly addresses the disappearing beard problem. It is not yet clear if this will also resolve the flashing neon colours!

Cause:
The .VMT contains material instructions from a newer version of TF2, while SFM is still unfortunately stuck with an outdated version of TF2 and may not recognise the instructions, causing incompatibility errors.

Solution:
Locate the .VMT file of the Beard model and place // in front of the attribute:
This will cancel out that instruction.

An alternate solution is to look around the Workshop and see if a fix specific for that beard has been posted. If not, the next step would be to ask politely if someone can help you.

Video for further help:
https://www.youtube.com/watch?v=J8va7cOSPUc

A lot of the Garry's Mod assets are done without ambient occlusion added, and combined with other possible material and model properties, it can cause them to appear in SFM as if they're semi-transparent. They will show the ambient occlusion of objects behind them, rather than their own AO. Most of the time these props will also not cast shadows from manually placed lights.

Solution:
You'll need a few applications for this:

• Crowbar
  Link to download: https://steamproxy.net/groups/CrowbarTool
  
• Notepad++
  Link to download: https://notepad-plus-plus.org/downloads/

Spawn the faulty AO item/character into SFM and from the Animation Set Editor window, right click said item/character and click on "Show Game Model in Explorer".

This will take you to the models location. Get out of that folder and copy and paste it onto your Desktop. Do not move or cut it from its location!



You may now exit SFM and load up Crowbar. Inside the application, navigate over to the "Decompile" tab and select "Browse" to search for your models .MDL and hit "Decompile".

Let it do its thing, hopefully it goes through with no errors.

When it's done, go back to where you plopped your folder with the .MDL and you should see a new folder called "decompiled". Click into it and a .QC file should be present. You will need Notepad++ to open it with.

Once in, enter the lines:
Just place them alongside the other string commands.

Save the .QC and exit.

Back in Crowbar, go to the "Compile" tab and browse for your .QC file. Set the output to Game's "models" folder and ensure you have "Source FilmMaker" for the "Game that has the model compiler" option selected. When ready, hit "Compile".


You should now be able to go back into SFM and reload the model. It should (hopefully) have proper AO now, however not every model is 1 to 1 and may just be too stubborn for it to work at all.

Video for further Help: https://www.youtube.com/watch?v=t6Gqup2BBoo

SFM has a very limited range of supported sound file formats - that is to say, precisely one. Issues with incompatible formats can vary from unresponsive sound to no control of the imported sound file. While it may still work, issues are bound to pop up.

Your sound file must be a 16 bit PCM-formatted .WAV file, with a frequency of 44100 Hz (though 11025 and 22050 Hz have a chance of functioning). Anything else is not guaranteed to work.

If you are doing the recording by yourself, ensure you have the settings set to output as .WAV of a Sample rate of 44100 Hz.

Note: Audacity link removed due to it now being a security hazard.

For some reason, SFM can not handle lengthy audio files, regardless if it's the correct format or not.

Workaround:
Cut the audio file into shorter segments, then import into SFM. Alternatively, there is the option to add sound via post-production from a separate video editing software.

Rarely, a small audio file in the correct format cannot be added into an SFM session. This may not have anything to do with the audio file itself, if you can load it without issues in other/new sessions; thus, it's a problem specific to the given session where it fails to load.

Cause:
This potentially loops back to SFM being a large address aware 32 bit program. The implications this can have on loading audio files is usually negligible, unless the user has used up memory up to about 2.5GB where the Mem usage is in the red. Past this point, loading further elements into the project may cause the program to crash, and this includes audio files.

Workaround:
Navigate over to the Animation Set window and click on the eye icons next to objects or groups to disable them temporally. This may improve program stability and allow adding audio files into the project once more.

At some point, if you use too many volumetric lights, some or all of them will look poorly sampled. This can happen when the number of volumetric lights in the scene is a multiple of 17.

Workaround:
Delete one or add another volumetric light somewhere.

Source Filmmaker was programmed specifically to work with a maximum of 8 shadowed lights, for performance reasons however, there is now a solution to raise that limit!

Cause:
A parameter set by the developers to keep the engine running smoothly.

Solution:
https://steamproxy.net/sharedfiles/filedetails/?id=2788015755

Note #1

Note #2

Because lights in SFM's engine version are merely projected textures, Gobo lights are alternative textures that can be loaded instead of a light's default. The downside of altering gobo textures is that the memory capacity (notice a theme?) and item indexing will be filled quickly, since every texture is indexed and then loaded through the dialog window.

Workaround:
No known workaround. If intending to use alternative gobo light textures, make sure to save your project, close SFM completely, relaunch it and change the light textures as you see fit. With especially high model/texture counts in the directory, you'll have to make the choice between altering gobo textures, or placing models and other elements in your scene, per each session of SFM.

In an ideal world, this wouldn't be a problem. After all, if you're not intending to do a movie, you likely want to export a single picture - an Image, if you will. Or perhaps a Poster? These two options are available in the File -> Export dropdown, but in truth they're far from optimal ways of exporting stills.

Poster Rendering
Posters allow rendering past 4K resolution, leading to potentially ridiculous 8K monstrosities, but the benefits of Posters quickly end here. Because it renders the image in rectangular chunks, if there's ever a problem in rendering a piece (highly likely past 4K), that part will have no data and will appear entirely black. In addition, exporting is slow, regardless of settings, system or scene complexity; bloom and possibly AO will not work correctly; flexes may distort; elements like screen overlays will not work correctly; and the actual file will be in a weird 9bit format containing a ton of garbage data that, while not affecting the image itself, bloats it to unreasonable file sizes.

Image Export
Image Exports take snapshots of what is in current view on the viewport. Its sole advantage is being near instantaneous. For otherwise obvious reasons, you'll be stuck with just a 720p image (unless you fiddle with the program to get a higher res viewport), and because it's a WYSIWYG (what you see is what you get) kind of deal, you have to preview at full samples in the Clip Editor before exporting as an Image. Far from ideal.

Solution:
Fun fact, movies are essentially successions of still pictures. We can, thus, order SFM to export a "movie" consisting of just one, or a few pictures from your project:
Export -> Movie, then tick the "Image Sequence" option.

Afterwards you can select a custom export section of your timeline through the Duration dropdown: for example, setting the frames from 0 to 1 will render the first frame of the project.

This is generally the way to go if you desire maximum visual fidelity in your single image exports (and funnily enough, if you have access to a half decent non-linear editor program, the way to go for regular animation too). The downside to this method is it requires Launch Commands to access the higher resolution options such as 1080p or 2160p(4K). These are disabled by default, which is why you'll see the dialog only has options for resolution up to 720p.

To access the higher resolution options, save your project, exit SFM and from the Steam Library, right click "Source Filmmaker" and select "Properties". From the General Tab, navigate to "Launch Options..." and in the box, copy and paste in either:
or

2160 corresponds to UHD 4K and includes 1080p as an export option. Relaunch SFM (the commands are automatically saved when you exit) and the choice to export up to that resolution in the Export -> Movie dialog will be available.


Please note:
These launch commands will tank your performance, regardless of hardware. When you are done using them, make sure to disable them by going back to the "Launch Options..." menu and deleting the commands.

Flex decay is a phenomenon in Source, which applies a slight delay to flexes - usually facial animation - which allows for more natural movement in animation. However, for single image exports, this is more of a nuisance than an actual boon: your export may show the flex partially engaged or otherwise distorted in a fashion that's not desirable.

Cause:
The author of the model did not disable Flex Decay before compiling.

Workaround:
Render multiple frames via the Image Sequence export, and keep the better result. This is the easiest and fastest route you can take.
or
Wait until the author fixes the problem by disabling Flex Decay.
or

Solution:
Decompile the model yourself and edit the .QC file, then recompile.

The main drawback of this is that compiling with flexes is not reliable. There's a chance this either has no tangible result, or can harm your model or flexes in some manner, and is generally a hassle to manage. The solution also assumes the flexes are in a .VTA format that are located somewhere within the .QC file.

First, you're going to need these:

• Crowbar
  Link to download: https://steamproxy.net/groups/CrowbarTool
  
• Notepad++
  Link to download: https://notepad-plus-plus.org/downloads/

Go ahead and launch Crowbar, head to the decompile tab and search for the .MDL file corresponding to the model that has the problem. Follow the demonstration image below and then hit Decompile once everything is in order.


Next, use Notepad++ to open the .QC file you should have received. Within this, look for a block of code that starts with a .VTA format line. Add Decay 0 at the end of every flex line command. This will disable it completely if done right. The image shows an example of 1 line containing the command and thus needs to be repeated at the end of each line until the end of the .VTA code block.

Once you're done with that, save a copy of the .QC and go to recompile it within Crowbar.


Thus, if you did everything correctly, the problem should now be absent when you go to render.

For further info on Flex Animation:
https://developer.valvesoftware.com/wiki/Flex_animation

You may sometimes have a sticky playhead following your mouse's movement, and more annoyingly you may find yourself unable to click in the viewport. This most often happens when multiple ctrl+ and shift+ keyboard shortcut commands are issued in quick succession, leading to overlap.

Workaround:
CTRL + M -> Escape -> CTRL + A
or
Hold shift and drag-select a small area.

Finger posing with a rig, for some reason, may cause SFM to lag.

Workaround:
Shorten Timeline clip to 10 seconds or less.

The default clip length is 60 seconds. Going past that can make parts of the program unresponsive. This is more likely to happen in animation projects.

Workaround:
Double click the timeline in Clip Editor and extend the yellow clips.

There's no safeguard to dragging the model preview window's borders. You can end up making the window unusable and remove the preview by mistake, if you drag it too far to the side. The resizing control is technically still there, but very difficult if not impossible to reach, even at the lowest mouse sensitivity/DPI settings.

Workaround:
Delete: in your SFM directory, found in "platforms\scripts", or in "platform\config." This will reset your interface layout and bring back the model browser preview.

Not to be confused with the Launch Command setting, allowing export renders up to 4K.

This is a rather peculiar problem where if you are using a 4K monitor, SFM will not scale up properly, regardless of your dpi scaling settings. Luckily with Windows 8 or above, you can do a trick that can force 4K scaling in SFM.

This section involves tampering with system registry files. Exercise caution following these instructions!

*The example for "Before" was taken from a 58" inch Television. The larger the screen size, the more obvious it becomes!

Solution

Part 1

Open System Registry via right click start -> Run -> Type: Regedit -> Yes.

In the top search bar, copy and paste:

In the right window, right click -> New -> DWORD (32-bit) Value.

Name it: PreferExternalManifest
Value data: 1
Base: Hexadecimal

Click ok.

Part 2
Create a txt. file and copy and paste all of the contents here into it:

Rename the txt. file to: Make sure you can edit file extensions so it properly converts to a manifest file.

Place the file in SFM's game file directory (where sfm.exe is located)

You should now be able to launch SFM with proper scaling, however you might also notice everything looks like a blurry mess now! There is sadly no definitive fix for this unless you have a fairly large monitor to compensate.

Note #1:
Launch commands will not help mitigate the blurry mess. SFM will not detect the Manifest file if you Launch from Steam. You have to Launch SFM via file explorer.

Note #2:
DPI Settings must be disabled for this to work. To check, right click sfm.exe -> Compatibility and make sure the option "Disable display scaling on high DPI Settings" is unchecked.

Video for more help: https://www.youtube.com/watch?v=Dq_CRJnCC74
For further Research: https://community.spiceworks.com/how_to/137758-4k-dpi-scaling-issues-solved

A majority of maps ported from Garry's Mod have missing or broken HDR, leading to a visual artifact where the bloom is overwhelming, and any reflections stop working correctly.

This Error message may also pop up:


Workaround:
Open the console via Windows -> Console. Set
and/or
Then type in
Restart SFM after it's done.

Sometimes, when editing the Horizontal/Vertical FoV slider values for lights and adjusting their position with the viewport, when switching back to the main or workcamera view, you'll find yourself stuck in the same warp effect as the light you just edited the values for. This is a rare bug that doesn't often happen all that much, but it's happened to even us a couple times and therefor warrants mentioning.

Solution:
Save the Session and restart SFM. The cameras viewport will reset back to normal when the session gets reloaded.

When using the Graph Editor, rotating bones can also affect the bones' position, making them drift in a seemingly random direction and distort your models. This, understandably, can ruin your animation effort.

Video showing off problem:
https://www.youtube.com/watch?v=Gajeb9pXuM4
Workaround:

Originally posted by Zappy:

Rotating bones in the Graph Editor tends to move the bones slightly, too. To avoid that, you have to deselect the bone's position transforms before rotating it.

In the Animation Set Editor, expand the bone's control to reveal a "pos" (position) and a "rot" (rotation) value inside.
Select the "rot" part, and/or deselect the "pos" part.

For further reading:
https://dev.dota2.com/forum/dota-2-custom-games-tools/source-filmmaker/260479-rotating-bones-while-in-graph-editor-mode-will-induce-positional-drifting

Ever seen this window before?


This is a frustratingly common error. The most common culprit is that you have downloaded enough assets from the workshop to cause errors in SFM as it searches the directory. In this situation, the only workaround is to go back and unsubscribe from a few submissions, or create a new custom assets folder and allocate part, or all of your workshop files over there to make room for more downloads.

Solution
Access your game folder here*:

Note: The Game Properties UI has since updated, but the process is still the same.

Go into the Game folder and make sure you can see SFM.exe. Create a new folder and name it something (that isn't already there) and give it the following sub-folders inside that:

• models
  
• materials
  
• maps
  
• sounds
  
• particles

Next, open the SDK and check off your new folder:


Move some of your workshop assets into the newly created game folder.

Mind that this method of clearing up the workshop folder will also prevent you from receiving automatic updates to the subscriptions, until you resubscribe to them (and copy the files to your custom folder, if applicable).

Cause:
Loading certain models causes an "Engine Hunk Overflow" error to display, followed by SFM crashing.

Workaround:
Add the following line to /usermod/cfg/autoconfig.cfg:

Cause:
SFM is unable to properly make a connection to the Steam network, usually if Steam is not running in the background or the client is having issues making a stable connection.

Workaround:
Run with the command:
This disables SFM from having to communicate with the Steam servers in order to run. Otherwise, you can restart Steam or wait until a stable connection to the Servers can be re-established.

Cause:
This tends to happen when SFM has been moved to another drive location after it has been previously installed, leading to "VGame" being set to the wrong location. For example, SFM was installed in C:\, then it was moved to D:\ thus confusing the program.

Unfortunately, a simple uninstall and reinstall will not do anything for you here, even after deleting the residual files. It is heavily encouraged that you do not move SFM once it's installed somewhere to prevent the error of this message popping up.

Solution:
First, in Start, type "envi" and choose "Edit environment variables for your account"


In this window, you only need to worry about what is in the top window - everything below is of no concern. Under "Variables" there should be:

• VGame
  
• VContent
  
• VProject
  
• VTools

If they do not exist, create them via "New..." and set the Value as the Search Path to where SFM is currently installed, like so (in this example, SFM is currently located in E:\):


If the Search Path for the Variable is incorrect, highlight it and click on "Edit" and then enter the correct Search Path where SFM actually is located.

Click "Ok" once that's all done and dusted and restart your computer.

Cause:
SFM crashes on startup when loading more than 70 search path folders on the SDK, regardless of content.

Workaround:
Disable search paths not in use before starting SFM for each session.

How to Access the SDK Search Paths:

Tick the box next to the folders to disable/enable them.

In the Particle Editor Tool, "System Properties -> Add..." causes SFM to close. No Freezing and no error message, just the window closing the animation.

Following the crash, an average of 34 files need to be retrieved via validation.

Workaround:
This is a bug left behind by the developers and can not be removed. Instead, just add parameters to the rest of the particle system.

This error means that either the file is corrupted or otherwise unable to be opened by SFM. This is a rare problem, though; it's highly unlikely project files get rendered unusable, unless they had been tampered with in some fashion.

Workaround:
If you have auto-save enabled (which should be by default) you may still be able to recover the session file. Locate where your sessions are saved. Here, each Session is under a file extension (DMX) with a sibling file to go with it (autosave). Rename or move the original corrupt DMX file out of the directory and then change the autosave file to have the DMX file extension instead.

Click ok and you should now be able to open that file. You may have to redo a couple things that did not get saved, but you can now continue working. The original DMX file can be discarded as it's no longer usable. A new autosave file will be generated when you launch from the new file after a couple minutes have passed.

Exercise prudence, and regularly back up your long-term projects.

If you ever went into SFM's Game folder, you might of noticed a strange file mentioning "sfm_crash", followed by a bunch of numbers:

This is generated when the program crashes, recording its final moments into this MDMP file. It is meant to be sent to the developers, to help them understand and effectively troubleshoot what caused the crash. It's nigh useless to any end-user and can not be easily deciphered without having some advanced computer skills in mind.

Sometimes instead of "sfm_crash" you'll get "sfm_assert", also followed by a bunch of random numbers and also in a MDMP format. The difference here is that the naming suggests SFM has been crashing quite a lot.

By the way, these are safe to delete. They are not a necessary component of the program itself and can be discarded without consequences.

If nothing listed so far is proving helpful, you always have the choice of heading to the Steam discussions and asking other users more directly. Describe your PC specs, what you have tried and if you have modified the game directory in any sort of way to help pinpoint the cause of the issue.

Try to be descriptive and thorough in explaining the situation. A helpful thing to do is to check whether loading an entirely new session, then loading the map 'stage.bsp' works or also causes the program to crash. This opens the door to explore other options and makes the process of finding the solution a little bit quicker.

Another avenue is outside of Steam. The closest to an official subreddit, found here, is another place to ask for feedback on. While seldom updated, the Community-run Valve software wiki may also prove useful for the more technical issues.

Regardless of where you post, be polite, have patience and be cooperative.

Credit to Capt Fuzzy for his excellent advice on how to approach the Steam Discussion Boards:
https://steamproxy.net/sharedfiles/filedetails/?id=754793347

You've met a new kind of problem, or a particularly stubborn one. You've tried everything else shown in this guide, around the forums, and even outside of Steam. You can't seem to get this freaking problem solved.

There's one more thing to try out:

...and then reinstall it and redownload any assets you were using.

Before you go through with this, keep in mind that this will delete EVERYTHING in your Sourcefilmmaker directory! All of your projects, your custom models, sounds and particles, your workshop subscriptions (though at least these can be redownloaded automatically later) - everything will be gone.

Also, in practice, this may not actually solve much, either. It's on the level of verifying files, but with a much higher chance of losing all your stuff.

If you accept the risks and are willing to try one more thing out, back up your usermod and any custom file paths and then proceed with uninstalling and reinstalling. May the Source Spaghetti Monster have mercy and bring back a good SFM experience.

Author - Prof. Purble

Thanks to various Reporters on SFM issues!
Kamerad
Zappy
Mystic Monkey
LazyPurple
Fames
Practical Problems
Pajser
Papyesh
FallenNoob
Anonymousgamer

Special Thanks
EmperorFaiz
Capt Fuzzy
Pte Jack
9joao6

Past contributors who wish to stay anonymous - You know who you are. Thank you.

Source Filmmaker is developed and owned by Valve.

While I appreciate the continuous attention and positive reception gathered by this guide, no further additions of bugs, glitches and other issues will be provided. This was largely a passion project by me, and the guide has still, as per with the Fundamentals Guide, ballooned beyond the initial scope into something greater.

Having said that, to be up to date on any newly discovered or resolved problems with SFM, I'll direct you to section I1's resources.

I once again thank you, the community, for the positive reception and constructive feedback handed out over the lifespan of these projects.