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.





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.
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.



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:
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
- Standardize color, render, and interchange pipeline decisions before anyone touches a shot — not shot by shot.
- Build a shared reference board (PureRef or equivalent) that the whole team works from, so there's no drift in interpretation.
- Get into the planning/storyboard meetings yourself, not just the ones where you're specifically consulted — problems are cheaper to catch before they're locked in.
Delegating under real constraints
- Break the schedule into phases with per-person assignments made week by week, not all at once — plans need to flex when people's availability isn't full-time.
- Push deadlines earlier than strictly necessary. Build in buffer before you need it, not after something slips.
- Check in on prep and progress directly and early — don't wait for the next scheduled meeting to discover someone's behind.
On set
- Your presence on set is about protecting what post-production needs later — HDRI, clean measurements, camera data, lighting notes.
- If the crew hasn't worked with VFX before, expect to catch things they don't know to flag. That's not a failure on their part, it's part of the job.
Staying humble
- Ask your team constantly: is there a better way to do this, and can we actually do it in the time we have.
- When something goes wrong on your watch, the question isn't whose fault it is — it's what needs to happen next.
Giving direction
- Be as clear and specific as possible. Always name the subject and the object — avoid vague words like "this," "that," "better," "worse." Describe exactly what you mean.
- A good visual reference beats a thousand words of description. If you can show it, show it.
Owning the final image
- You're the supervisor — you're responsible for the final image, not just for being encouraging. If something isn't working, it's your job to say so and ask for a revision, politely but clearly.
- Sometimes that means being the person who says the hard thing. Addressing it directly, even when it's uncomfortable, is more respectful of the work and the team's time than letting it slide.
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.








