EP.008 — ← back to log

Red is the Wrath of the Womb — Fire FX Breakdown

Leading the fire VFX on a horror film's climax — eight shots, six artists, two months, everyone juggling coursework alongside it. Pipeline, team structure, hard technical problems, and a deep dive on the shot I lived in.

VFX Supervisor + FX Lead
6 artists
8 fire shots, sim → delivery
2 months, part-time
Houdini · Nuke · USD · ComfyUI · SCAD farm
SH180 — the house fully engulfed in flame, final render
SH180 — final render, the house fully engulfed

Note: this breakdown is still being revised — more shots and detail to come. To be added: how I use AI tools to generate utility maps for easy compositing, more technical Q&A addressing production quirks, and 2 more shots once finalized.

Overview

Red is the Wrath of the Womb is a horror-supernatural thesis film, directed by Sophia Pozetta from SCAD Film. Its climax: a lantern thrown to the floor by the protagonist escalates into a house fully engulfed in flame — eight VFX shots.

I led that work as VFX Supervisor and FX Lead: two months, everyone including me juggling coursework and other projects in parallel. That constraint shaped the pipeline, the delegation, and where corners could and couldn't be cut.

This post covers the full process — creative brief, pipeline, team structure, hard technical problems — with a deep dive on SH180, the shot I was most invested in. The other seven are covered in a companion breakdown video.

TL;DR

  • Supervised the fire VFX for the film's climax — 8 shots, 6 artists, 2 months, everyone (including me) juggling coursework alongside it.
  • Pushed back on a practical miniature burn in planning and made the case for a fully CG house instead — more control over fire behavior, scale, and iteration.
  • SH180, the hero shot, ran on multiple separated simulations for maximum control, and surfaced most of the sequence's hardest pipeline bugs — Cryptomatte/farm compatibility, a path-related farm crash, an EXR race condition, and a cross-machine color mismatch.
  • Leading six people under real time constraints meant standardizing the pipeline early, building in schedule buffer, and staying hands-on when someone fell behind rather than just reassigning the work.
  • Biggest personal takeaway: being the supervisor doesn't mean having every answer — it means listening, owning the final image, and getting the team to the right call together.

Creative brief / reference

Nothing was invented. Every creative decision on this sequence traced back to a reference source, not a guess.

Every shot was built strictly against reference — no invented behavior. Sources were Shotdeck film frames and real burning-house footage from YouTube, chosen per shot to match the storyboard and on-set plates.

I compiled all of it — reference, storyboard, and set footage — into a single PureRef board per shot, shared with the whole team. One reference standard, no drift in interpretation across the team.

Shot tracker — storyboard, reference and motion notes for SH180, SH200, SH166, SH179
Shot tracker — SH180, SH200, SH166, SH179
Shot tracker — storyboard, reference and motion notes for SH178, SH190, SH167, SH86
Shot tracker — SH178, SH190, SH167, SH86
Shot tracker page 3
Shot tracker, cont.
Shot tracker page 4
Shot tracker, cont.
Shot tracker page 5
Shot tracker, cont.

The sequence at a glance

Before diving into one shot, here's the shape of the whole sequence and where my hands were on it.

I supervised all 8 shots end to end — creative direction and technical assistance across the team — and personally built the fire FX on 3 of them.

On-set supervision

Bridging two teams

VFX work didn't start in Houdini — it started on set. Even the best chef needs good ingredients; no amount of pipeline work in post can fix footage that wasn't shot with post in mind.

My job on set was to make sure that gap never opened. I worked with the director to understand what she wanted from each shot, then translated that into practical terms with the DP — lighting, framing, and setup choices that would actually support what post-production needed to deliver later. This covered on-set supervision for the full sequence, not just one shot. It was also the first time this film crew had worked with a VFX supervisor on set, so the working relationship went both ways.

Capturing reference

I personally captured HDRIs of the bedroom and house exterior using an Insta360 X4, for accurate lighting reference in post.

I also brought two artists from the team on set as VFX PAs, tasked with measuring everything we'd need to model or camera-match later — house dimensions, key distances, reference points — as well as taking photo reference and documenting camera data for post. Strictly speaking, the job only needed one PA. I brought two because neither had been on set before, and it was a chance for them to get that experience.

The case for a CG house

In planning, the director, producer, and art department proposed building and burning a miniature model of the house practically. I pushed back: a practical burn gives you exactly one take, no control over how the fire actually behaves, scale that rarely reads correctly on camera, and a real risk that the miniature just doesn't sell as a full-size house. I made the case for a fully CG house instead, and the team went with it — full control over fire behavior, scale, and as many iterations as we needed.

Catching a pacing problem

During storyboarding, I asked the director how strong the fire should be in each shot, and the plan looked reasonable on paper. On set, once I understood how the shots were actually going to be pieced together, I flagged a realism problem: the storyboard plan had the house going from spark to fully engulfed in 15–20 seconds — fire doesn't spread that fast. I raised it with the director on the spot, and we adjusted the pacing so the escalation felt believable rather than instant.

A consistency lesson

For two shots involving fire reflected in an actor's eyes, the crew shot without communicating lighting setup or camera data (lens, aperture, distance) with me. I was on set, ready to be consulted, but no one told me they were shooting a VFX shot until it was already done. It wasn't a fatal problem, our compositors made it work, but it wasn't professional either. Missing that communication creates extra work for the post team and risks a worse result than if it had been done right the first time. It's a clear example of what "good ingredients" on set actually means in practice.

Pipeline architecture

With 8 shots and six artists working in parallel, the pipeline had to be settled before anyone started — not figured out shot by shot. There's no single correct way to do this; different studios solve color, render, and interchange differently. Here's the approach I chose and why it held up across the whole sequence.

Color — ACES/OCIO. Set footage was shot in RedWideGamut with a Log3G10 curve — a different color space than any CG render. Unifying everything into one working space (ACEScg) was non-negotiable: it's the only way to give accurate color notes, and the only way a comp artist can judge whether a CG plate actually sits correctly in the set footage. ACES was also the practical choice because every major DCC in the pipeline — Houdini, Nuke, Maya — supports it natively, so no tool was fighting the color pipeline. After comp, the compositor transformed the finished footage back to RedWideGamut, matching the set footage's native color space so the editor could manage color consistently across CG and practical shots alike.

Render — USD, Solaris, Karma. All fire and smoke FX were built in Houdini, so Solaris and Karma's native volume rendering was the obvious choice over exporting to a third-party renderer. One shot broke that pattern: our lead modeler/lookdev artist Jay had already built the CG car side-mirror scene in Maya with a large asset library, so for that shot it was easier to bring the fire sim in as a VDB and render in Arnold, native to Maya, rather than rebuild the scene in Houdini.

Interchange — FBX. Cameras and house models were built in Maya and brought into Houdini via FBX.

Standardizing this early meant every shot spoke the same language — same color space, same render path, same export format — before any artist started work.

Testing pipeline setup with Jay at the SCAD lab
Testing pipeline setup with Jay

Deep dive: SH180 burning house

Eight shots, but this is the one I lived in. SH180 is the film's climax: fire venting through a window in a single, sustained directional arc, the moment the house fully commits to burning. If one shot had to carry the weight of "wrath," it was this one.

Creative target

Built strictly against reference, like every shot in the sequence — but here the bar was higher, because SH180 had to read as the turning point of the film, not just another burning-house beat. The fire needed to feel directional and deliberate, venting outward through the window with intent, not just billowing generically. That distinction shaped nearly every simulation decision that followed.

Simulation

SH180's fire isn't one simulation — it's several, deliberately separated for maximum control. Three windows each ran their own sim. The roof fire was its own sim. Ground scatter fire, indoor filler fire, and a secondary smoke-leak sim were each separate as well. Splitting them this way meant I could tune each fire's behavior independently instead of fighting one monolithic sim trying to do everything at once.

The hardest sim problem was getting the window fire to curve along the roof edge instead of just venting straight out. My first instinct was Pyro's curve force microsolver, but it deformed the fire shape too aggressively and lost detail — it didn't read as natural fire anymore, just a bent shape. I ended up achieving the curved path with initial velocity plus wind speed instead, letting the fire's own motion carry it along that arc rather than forcing the shape directly.

Shading

That per-source separation carried through to shading too. The window fires needed thinner, less dense smoke than the roof fire, so each got its own shader tuning — color, intensity, and density all adjusted separately to read correctly for what that fire actually was, not a single look stretched across every source. For the window fires specifically, I added inner partial transparency to the flame, then combined that with the indoor filler fire sim visible through it, so the fire read as sitting in front of a burning interior rather than as a flat cutout shape.

Rendering

Rendered in Karma. A few deliberate choices went into keeping this shot flexible in comp. Rather than rendering noise-free, I let Karma render with some noise and denoised in Nuke with Neat Video instead — more control over the noise/detail tradeoff after the fact than baking a denoise decision into the render. Motion blur was handled the same way: instead of rendering it in, I output a motion vector pass and left motion blur to comp, so it could be adjusted or disabled per-shot without a re-render.

Cryptomatte was its own problem here. The SCAD render farm couldn't render the sequence with correct Cryptomatte output — on this version of Karma (21.0.440), Cryptomatte wouldn't read correctly in Nuke unless a manifest file path was explicitly specified. AOVs had their own share of trial and error too, including a genuine Karma XPU bug. (Both fixes are detailed in the Q&A section below.)

Team & leadership

The pipeline gave every shot a shared foundation. Leadership was making sure six people, each juggling this project alongside everything else, actually used it well.

Production sheet — table of contents, naming convention, and links
Production sheet — naming convention & links
Production sheet — crew and tracking
Production sheet — crew & tracking
Production sheet — deadlines and weekly meeting notes
Production sheet — deadlines & meeting notes

Team structure

The VFX team sat inside a larger film crew: a director, a producer, and an editor, with VFX reporting up through me. Within VFX, six of us split roughly by specialty — modeling/lookdev, FX, and comp — but ownership was tracked per shot, not just per department:

Jay Jeon Lead Modeler / Lookdev — house, car side mirror, hard-surface assets
Emilie Jones Modeler / Lookdev — set-dressing assets: birdhouses, fan, camera, bell
Evie Wang FX Artist — lantern fire, bedroom fire, tree burning
Alyssa Lin Compositor
Yijia Che Compositor / Camera-Matching / Lighting Artist
Myself VFX Supervisor & Producer / FX Artist — window fire, house fire, tree fire

Delegation under constraint

With everyone carrying coursework and other projects, the schedule couldn't assume full-time availability from anyone, including me. I broke the two months into weekly phases — previz/layout, modeling/lookdev, FX, comp, render/deliver — with each person's shots assigned week by week rather than all at once, so the plan could flex as availability shifted. I also deliberately pushed deadlines earlier than strictly necessary, building in buffer for the delays I knew were coming given everyone's schedules. That foresight paid off more than once.

Communication & review cadence

We ran a weekly production meeting (Sunday nights, 9–11PM EDT, on Discord) with four fixed objectives: check progress, gather feedback, assign the coming week's tasks, and debug anything blocking. Attendance wasn't rigid — if someone had already given me a progress update earlier that week, they didn't need to sit through the full two hours. Outside that meeting, I tried my best to answer as soon as possible whenever a technical problem came up or a shot needed a direction call. The standing expectation was to post WIP to Discord often and ask for peer feedback constantly, so problems surfaced before a deadline, not at one.

A leadership moment

Not every delegation went smoothly. One artist, given a paid course I'd provided along with ample time to prepare, fell significantly behind — to the point where I had to step in directly: teaching the technical fundamentals myself and debugging their work multiple times over.

It was frustrating in the moment. But the job wasn't to be frustrated, it was to get the shot delivered and the artist unstuck. I stayed patient, walked through the process with them step by step, and kept at it until they could work independently again. The result wasn't perfect, but it was solid, and they finished the assignment.

What leading taught me

When something goes wrong on a shot I'm supervising, the question isn't whose fault it is — it's what needs to happen next to get it done. That's the lesson the artist I stepped in for taught me, and it's the one that came up again and again across the sequence.

The other half of leading, for me, was listening. I respect the artists I worked with, and I asked for their input constantly: is there a better way to do this, will this actually hold up in the time we have, does this read the way we think it does. I'm the supervisor, but I'm also still a student learning this craft alongside them. Staying humble about that, and treating their pushback as useful information rather than a challenge to my authority, consistently led to better shots than if I'd just made every call myself.

Final result

Lessons learned / retrospective

What I'd do differently

A few things I'd change if I ran this sequence again:

Sit in on more of the planning meetings myself. The fire pacing problem got caught on set, but it shouldn't have needed a last-minute save — I was consulted on fire intensity per shot, but not deeply involved in how the sequence was planned to flow together. Being in the room earlier, not just reviewing decisions after they were mostly locked, would have caught it at the storyboard stage instead.

Align render machine settings before, not during, production. The cross-machine color mismatch on SH180 came down to different OCIO/Karma defaults on different artists' machines. That's a five-minute check I should have run at pipeline setup, not something I debugged mid-sequence under deadline pressure.

Check in on prep and course progress earlier and more directly. I gave one artist a paid course and time to prepare, but only found out they hadn't gotten through it once they were already visibly behind. A direct, earlier check-in — not waiting for the weekly meeting to surface it — would have caught the gap before it became a bigger problem to fix.

Reflections

Going into this project, I thought of myself as an FX artist who happened to be supervising. Coming out of it, I don't think that's true anymore. The technical work — the pyro sims, the Karma renders, the pipeline debugging — was the part I already knew how to do. What I actually learned was everything around it: advocating for a CG house before a single frame was shot, catching a pacing problem on set by really listening to how the story would play, staying patient enough to teach someone the fundamentals instead of just taking the shot back from them.

The thing I'm most proud of isn't a specific fix. It's the humility behind all of it — the same instinct to keep listening that I described in Team & Leadership. I'm still a student learning this craft, same as everyone on the team. This project taught me that being the supervisor doesn't mean having every answer. It means making sure the team finds the right one, together, in time.

Tips for supervising

If you're about to supervise your first VFX sequence, here's what actually mattered on this one.

Before production starts

Delegating under real constraints

On set

Staying humble

Giving direction

Owning the final image

Q&A — production quirks & fixes

A running list of technical problems that came up across the sequence and how they got solved. Not exhaustive — more will be added as it comes back to me.

Q: Fire rises straight up but the smoke above it drifts sideways — why don't they match?

Buoyancy was overpowering wind. If the temperature field strength is too high relative to the wind force, fire outruns the wind's influence before it can bend the plume. Fix: rebalance temperature field strength against wind so wind can actually act on the fire column.

Q: I need the hottest core of the fire to read as transparent, but density and temperature are linked — how do I separate them?

Decouple density from temperature at the volume cache level with a fit remap (VEX or Volume VOP), rather than trying to mask it shader-side. Caching the decoupled result makes it reusable across passes.

Q: My volume AOV renders pure black — is the shader broken?

Two separate causes, usually: (1) if you're checking a diffuse AOV, that's expected — volumes don't have a diffuse BSDF, check Volume Direct/Indirect and Emission instead. (2) If a dedicated volume AOV is black, check the light's Volume contribution toggle first, then check for a known Karma XPU bug where volume AOVs render blank — workaround is disabling "Create Render Var" on the shader's AOV VOPs and manually adding the render var under Image Output → Extra Render Vars.

Q: Cryptomatte works fine locally but doesn't show up in Nuke when rendered from the farm.

Karma's multi-part EXR writer doesn't reliably embed Cryptomatte manifest metadata. Fix: set an explicit Manifest File path on the Karma Cryptomatte LOP so husk writes a sidecar .json instead of embedding it in EXR metadata, then point Nuke's Cryptomatte node's Manifest Source at that file.

Q: Farm render crashes with exit code 139 (segfault) — where do I even start?

Check for hardcoded absolute paths first. $HIP/$OS expressions can bake to absolute machine-specific paths (e.g. a Windows drive letter) at USD export time instead of evaluating at husk runtime on the farm, which corrupts the EXR writer on a different OS. Fix: use relative, portable paths with no machine-specific prefix.

Q: Still crashing after fixing paths — what else could it be?

OpenEXR's multithreaded scanline compressor can hit a race condition when too many AOV channels get written into one multi-part EXR at single-scanline ZIP compression. Fix: split heavy passes (like Cryptomatte) into their own separate Render Product, and switch to multi-scanline ZIP blocks to reduce thread contention. Reducing Cryptomatte rank also helps if channel count is the bottleneck.

Q: Same scene renders different fire color on two different machines — which one is right?

Check the EXR's actual embedded color space tag, not just what you assume — it may be accurately reporting a real mismatch (e.g. one machine defaulting to Linear Rec.709 instead of ACEScg) rather than a false tag. Fix: read each file in its correct native space, then convert to your working space with an explicit OCIOColorSpace node before compositing. Prevention: align OCIO/Karma output settings across every render machine before starting production, not after the mismatch shows up.


← back to the log