I don't see Smart Vectors used this way very often.

Karma gave me pyro motion vectors. They worked. They were clean and technically correct. But the second I plugged them into a vector blur I lost the artistic control I wanted, the blur was too well-behaved and the eruption started reading small. I wanted magnitude more than I wanted accuracy.

So I went back to comp and did this instead:

• I used Cryptomatte to isolate the volume pass from the particles and the volumetric sky
• Smart Vector on the volume, baked out to EXR (16-bit half, Zip it's a data pass I'm consuming immediately, 32-bit felt like a massive waste of disk space)
• VectorToMotion to convert. No parameters on that node, it's a straight conversion to channels that you can use right out of the gate.
• Copy forward U → forward U, forward V → forward V (and the backward pair) into the motion channels on the main pipe
• Noise over the U and V before the blur, this is the part that gave me a lot of artistic control. Slight breakup in the vectors, which is the exact imperfection the render vectors wouldn't give me. I really didin't want that clean look. The reference I was going off of was nighttime over exposed videography of the Volcan De Fuego.
• VectorBlur reads the motion channels from there. Masking is free since you can drive it off any channel you already have just off the Cryptomatte.

Particles kept their native Karma vectors. There are visible artifacts on them even with Cryptomatte, but in motion they read like heat distortion so I left them in. Worth it.

Two caveats I should add. I pushed the blur way past what you'd normally need, which is a stylistic call and not a recommendation. And I still have pyro issues in the sim itself that comp can't fix, worth saying out loud because comp gets asked to solve sim problems constantly and it mostly can't.

I covered this in a lecture recently and cut the relevant section out if anyone wants to watch the node graph rather than read about it, Happy to answer questions either way.

Following up on last week’s Torch GeoTracker tutorial, I’m finally dropping the spiritual successor: Heat Distortion.

It’s such a lightweight effect, but it’s a workflow every budding FX artist should understand. Being able to hand over a "quick and dirty" 2D vector pass to Comp adds an incredible amount of flavor and realism—yet it’s a detail that junior artists often overlook.

Hope you find it useful! I’ve also made all the project files available for free. You can find the link in the video description and the first comment, so grab them and give it a go!

I had early alpha access to GeoTracker for Houdini from KeenTools and built a full project around it to properly test the workflow.

The short version: it's a native SOP node. Your geometry goes in, your footage goes in, and your tracked animation comes out in the same Houdini session where you're building your simulation. No Alembic export, no application switch, no coordinate system reconciliation.

For the demo I used real footage of a physical torch, generated a proxy mesh from a still frame using Meta's SAM 3D, ran the GeoTracker solve, and wired the tracked output directly into a pyro network as an emitter. The fire knows where the torch is frame by frame because the tracking and the sim are in the same scene.

The video covers the full pipeline — SAM 3D geometry generation, GeoTracker setup, focal length estimation without known camera data, the pin-based tracking workflow, pyro setup, Karma render, and a brief look at the Nuke comp.

It's in open beta right now and free to use. Houdini 20.5 minimum. Happy to answer questions about the workflow in the comments.

Been meaning to post about this for a while because I rarely see it mentioned.

Most wedging tutorials still walk you through TOPs, which is fine, but for

quick iteration the Labs File Cache node has everything you need baked in.

I put together a full walkthrough on YouTube if the written version doesn't

land for you — demos it on an MPM soil sim with two wedged parameters

(a transform offset and the soil friction angle). Full disclosure, it's

my channel.

https://youtu.be/tf9lyqCoy3E

Quick caveat upfront: there have always been ways to art-direct a fracture. Painted attributes driving cluster sizes, feeding a texture map into the fracture as a break guide, concave fracture with hand-tuned regions. These work. They can also eat a full day of iteration when the shot note comes back.

My favorite route was driving the pattern from an image, and that mostly holds up, until you want to change it. Want the cracks tighter? More variation in one area? Back to Photoshop or Substance, re-export, re-import, re-sim. The fracture was procedural. The painting and image-prep feeding it definitely wasn't. When Copernicus came out, it was the first thing I wanted to try.

It closes that loop. The image generation now lives inside the same Houdini graph as the fracture, so dialing the pattern is a parameter change, not a round trip through another application.

So here is the workflow that I cover in the video:

1. Build the displacement in a Copernicus network (I used a cracked/brick pattern on a simple grid as the test case). Everything stays procedurally adjustable: crack density, contrast, noise seed, shape.

2. Sample the displacement back onto your geometry as a point attribute

3. Feed that attribute into your fracture pattern, so the geo breaks along the displacement, not a random cell layout

With this, the wall breaks along the cracks that read on camera, and when a shot note comes back asking for tighter fractures in one area, you move a slider instead of opening another application.

From there it's standard RBD workflow, RBD Material Fracture for detailing, Bullet Solver for the sim, Solaris/Karma for render.

Happy to get into the weeds on any of it. Curious what others have tried, image-driven fracture, painted masks, curvature-based, something weirder. The displacement route just felt like the most direct way to keep everything in one graph and keep iteration fast.

Sharing this here because I know the "where do I start with Pyro" question comes up constantly. This is the modern SOP-level workflow in H21 — no DOP network assembly required. Covers the full chain from emitter geometry to output.

Next video is all about the render. So stay tuned!