Blender Addons

HoovyTools

Pick a tool

tap one
HoovyTools badge

SFM → Blender
full session import

HoovyTools Particle Import badge

SFM → Blender
.pcf particle effects

Blender to SFM importer badge

Blender → SFMunder construction

HoovyTools: SFM to Blender

Developed between 2023 and 2026 by HoovyTube with the permission of RedEye (creator of SourceIO), HoovyTools brings full SFM session import into Blender for the first time: shape keys, cameras, sounds and animations, in harmony with SourceIO. Documentation starts from this release; older builds will be documented here over time.

Installing HoovyTools

HoovyTools runs on top of SourceIO. SourceIO loads Source engine models, materials and textures into Blender; HoovyTools rebuilds the SFM session around them. Install SourceIO first, then HoovyTools.

  1. Install SourceIO: Edit → Preferences → Add-ons → Install…, choose its zip, and enable it.
  2. Download the HoovyTools .zip above. Do not unzip it.
  3. Back in Add-ons → Install…, choose the HoovyTools zip, then tick the checkbox to enable it.
  4. Open the sidebar in the 3D viewport (press N). The HoovyTools panel lives there.

Wiring in your usermod

SFM keeps your custom models, materials and sounds inside your usermod and the game folders it mounts. HoovyTools resolves every asset a session references by those same relative paths. Point it at your SFM usermod and mounted game folders and it finds your content exactly the way SFM did, with nothing renamed or re-pathed. If a model comes in missing, it is almost always a usermod path that has not been added yet.

What the import brings across

Point HoovyTools at an SFM session (a .dmx file) and it rebuilds that session inside Blender in one pass:

  • Session structure. Shots, clips and the timeline are read and reconstructed in one go.
  • Animations. Every bone channel is sampled and baked onto the Blender armature, keyframe for keyframe.
  • Shape keys. Facial flexes and flex controllers become native Blender shape keys, animated over the timeline.
  • Cameras. The SFM camera is rebuilt as a Blender camera with position, rotation and FOV, keyed as it moved.
  • Sounds. Every voice line and sound in the session is placed on the timeline, on the frame.
  • FPS-aware timing. Everything is retimed to your scene (for example 24 → 30) so animation, sound and camera stay locked together.
  • Non-destructive. Assets keep their original paths and names, so a re-import lands in the same place.

Under the hood: how the import works

An SFM session is a DMX file: a tree of elements that describes the shot. HoovyTools reads it directly (the same format datamodel / dmxconvert operate on), walks the tree, and translates each piece into the closest thing Blender understands.

What gets parsed

  • Session data: the clip and shot structure, plus the master timeline.
  • Animation data: per-bone transform channels, sampled and baked onto the armature.
  • Camera data: the camera transform and FOV channels.
  • Sound clips: the game sounds a session references and their frame positions.
  • Flex / shape channels: the flex-controller values that drive faces.

Fifteen small scripts, stacked

HoovyTools is fifteen small, single-purpose scripts stacked on top of each other. Each does one thing and hands clean data to the next.

01DMX reader opens the session and decodes it into a tree.
02Session walker finds the shots, clips and the timeline.
03Model resolver hands model references to SourceIO to load.
04Animation baker samples bone channels and keys the armature.
05Shape-key mapper turns flex controllers into shape keys.
06Camera mapper rebuilds the camera transform and FOV.
07Sound placer drops each sound onto the timeline, on the frame.
08Timing / FPS converter retimes every channel to the scene.
and the rest: coordinate-space fixes, unit conversion, naming, cleanup and validation.

Where Blender stands in for SFM

  • Flex controllers → Blender shape keys.
  • SFM camera → Blender camera with animated F-Curves.
  • DMX sound clips → sound strips on the timeline, on the frame.
  • SFM game units and coordinate space → Blender's units and axes.
  • Session timeline → Blender's scene frame range and FPS.

The result: your SFM work lands in a modern, far more stable environment, without rebuilding anything by hand.

HoovyTools Particle Import

Version history1 / 1
Overview: imported SFM effects playing in Blender1 / 3

The problem this solves

Everything else in an SFM project can leave SFM. Models, maps, animation and cameras all have a road into Blender through SourceIO, Blender Source Tools and HoovyTools: Session Importer. Particles did not. An SFM effect is a .pcf file - a description of emitters, forces and sprites that only Source could play. Move a scene to Blender and every explosion, muzzle flash and smoke trail stays behind, to be faked by hand or composited in from stock footage.

Particle Import reads the .pcf and rebuilds each system inside Blender as geometry nodes. The result is not a baked point cloud or a video. Emitters emit, forces push, sprites face the camera and play their sheets, and every parameter the original author tuned is exposed in a panel.

How to import SFM particles into Blender

  1. Install Blender 4.1 or later.
  2. Download the .zip above. Do not unzip it.
  3. Drag the .zip onto the Blender viewport and accept the install prompt. (Or use Edit → Preferences → Add-ons → Install….) Restart Blender if the tab does not appear.
  4. Press N in the 3D viewport and open the Particle Import tab.
  5. Pick a .pcf, pick a system, press Build. Press play.

The addon is standalone: it reads .pcf, .vtf and .vmt files directly. No SourceIO, no VTFEdit, no converters. It auto-detects your SFM install; if yours lives somewhere unusual, set the paths in the addon preferences.

What comes across

  • The full system. Emitters, initializers, per-frame operators, forces and constraints are rebuilt as working geometry nodes. Nothing is baked.
  • All three renderers. Camera-facing animated sprites, ropes and beams (render_rope), and velocity-stretched trails (render_sprite_trail).
  • Textures. .vtf sprite sheets and .vmt materials are decoded directly, including $additive, $overbrightfactor and sheet sequences.
  • Control points. Imported as empties. Drag one and the effect follows, the same way it follows control points in SFM.
  • Editing after import. Every parameter the .pcf authored appears in a properties panel, organised by SFM's own sections. Changes apply to particles already in the air.
  • Sharing. Node to Code exports a built system as a script anyone can run, with no addon installed.
  • Performance. Proxy View swaps heavy effects for cheap colour-coded stand-ins. A diagnosis button reports what is actually causing viewport lag.
Tested against the hundreds of custom particle systems I have built for supporters over the years. Nearly all of them import and play correctly.

Under the hood: the geometry-node machine

Open an imported system in the node editor and the graph is organised the way Source organises particles, colour-coded by job:

Time - the clock. SFM's timeline runs at 24 FPS; a time-scale group retimes it to your scene.
Emitter - when particles are born, and how many.
Initializers - values decided once, at birth: position, radius, colour, lifetime.
Operators - values recomputed every frame: movement, fading, spin, forces.
Sequence maths - which tile of the sprite sheet each particle shows.
Renderer - turns the data into camera-facing cards.

This is Valve's own anatomy, kept on purpose. If you have used SFM's particle editor, you already know your way around the graph.

The emitter

Thirty times a second the emitter computes how many particles to spawn. Fractional amounts carry over to the next tick - a rate of 2.5 spawns two now and banks the half - so long-run counts match what the author tuned. The particle cap throttles emission; it never deletes a living particle to make room. When the population is full, emission waits for a natural death.

Memory and recomputation

The simulation zone stores four values per particle: ID, birth time, birth position, and one flag. Everything else - size, colour, roll, transparency - is recomputed every frame as a function of the particle's ID. The practical consequence: change Radius while the effect plays and particles already in the air update immediately. Nothing is baked, so nothing needs re-baking.

Deterministic randomness

Random values come from a hash of the particle ID (fract(sin(id × 12.9898 + 78.233) × 43758.5453)), not from a random number generator. A given particle rolls the same values every time it is asked. This is what makes the timeline scrubbable in both directions without the effect falling apart.

Source's clock and units

Source applies drag per 30 Hz tick, not per second, and the graphs reproduce that - terminal velocity works out to gravity ÷ (30 × drag). One Blender unit equals one Hammer unit, and no value is rescaled on the way in. Effects hold up next to Source-scale characters because the maths is Source's maths.

The renderer

Each particle is a card, and its facing mode comes from the .pcf: full billboard (smoke), erect (fire - yaws to face the viewer, stays upright, takes no roll), or locked to a control point's rotation. Mirror flips are a negative X scale on the card. One material serves the whole sheet; each particle selects its sequence through a per-point attribute the shader reads at the instance level.

The graph documents itself

Every section of every generated graph carries a written note in a coloured frame: what the section does, how, and which traps it avoids. The documentation lives inside the node editor, next to the nodes it describes.

Acknowledgements

Blender Source Tools and SourceIO built the road between Source and Blender; this addon adds the missing lane. It is written by a long-time user of both, in the same spirit: free, and made so SFM artists keep more of their work when they move.

HoovyTools: Blender to SFM

An automatic Blender to SFM importer is under construction. Join the newsletter to hear when it drops.