Paint Six Flat Colours, Get Fire: The Control Video Is the Real Interface

A free LTX 2.5 adapter turns painted blobs into smoke and fire in about a minute, and it published every training number, so the recipe transfers to whatever effect you actually need.

The prompt is four words long. ainvfxfluid, smoke plume. That is the entire text instruction, and it stays that short whether the plume rises straight, drifts left, doubles back on a gust of wind, or sits behind a building in the mid-ground.

Everything else comes from a drawing. Flat grey blobs on the first frame, flat grey blobs on the last, black in between. The shape of the volume, where it sits in frame, how it moves across five seconds, even how it is shaded: all of that lives in the painting, not the sentence.

That inversion is the interesting part of ainvfx-fluid, a free 654 MB in-context LoRA for LTX 2.5 published by AInVFX on September 13. Prompt engineering has been the interface to generative video for two years. Here the prompt is almost inert and the control video does the work, which changes who can direct the thing.

Why this is a different job than prompting

A note arrives on an approved shot: add smoke in the background. Three options have existed until now, and all three are bad.

Stock footage is the fast one, and it never sits where the frame needs it. You end up warping a plate to match a plume instead of the other way around. A real simulation gets you exactly what you want and costs setup, cache and iteration time you do not have on a note. Generating from a prompt gets you smoke somewhere in the frame, and then you ask again.

The fourth option is the one that did not exist: take the drawing the supervisor already scribbled on the frame and turn it into a moving element. That drawing is a specification. It says where, how big, what shape, in a way no sentence does.

What makes this work is that an in-context LoRA learns a relationship between two videos rather than a style. During training it sees pairs. On one side a control, on the other the result it should produce from that control. Here the pair is dead simple: flat colour blobs on the painted frames with black everywhere else, and the same shot with real smoke, steam or fire where the blobs were. At inference you supply a new control and get the matching result.

Once you see it that way the prompt's job becomes clear. It is not describing the shot. It is naming the material, and cleaning up what the model invents on its own.

The control video rules, which are the whole game

This is the part that decides whether the model behaves, and it is rigid in ways that will bite you silently.

A control video is a normal video file the same size and length as the shot you want.

Dimensions must be multiples of 64. 512x512, 960x512, 512x960, 1024x576 and 1920x1088 all work. This is not a style preference. The reference is encoded at half resolution by the loader, so anything off the grid degrades fast.

121 frames is the tested length, at 24, 25 or 50 fps. Other lengths of the form 8k+1 should work, but 121 is what was verified.

Your painted first frame sits at index 0, your painted last frame at index 120, black frames everywhere between.

Extra keyframes must land on a multiple of 8, plus 1. Frame 1, 9, 17, and so on up to 113. This is the rule most likely to waste your afternoon, and there is a real mechanism under it: the LTX VAE groups frames into blocks of eight. A keyframe sitting on that grid gets read cleanly. One placed off it gets smeared across a block instead.

A keyframe can be a single frame or held across its full eight frames. Both were in the training set, so both are read correctly.

Paint flat colours. One blob per volume. Light grey for smoke, white for steam, orange with a yellow core for fire. Black background, or a few flat zones for sky and ground.

The shape rules sound fussy written out. In practice you set the canvas once and the rest is painting.

What the paint carries that the prompt cannot

Two behaviours are worth knowing before your first attempt, because both look like bugs until you understand them.

Shading transfers. Put a second, darker grey along one edge of your painted plume and the generation comes back with shading on that side, not a flat white cloud. You are art-directing the lighting with the paint, which means a two-minute pass in GIMP buys you something no prompt reaches.

The result follows your painted shapes closely and still leaks a little at the edges. That is correct behaviour, not sloppiness. Over-controlling a fluid is how a simulation stops looking like a fluid.

Where the prompt earns its keep is narrower than you would guess. It does two jobs. It removes things you did not ask for, because the model sometimes invents an emitter or a foreground element, and ainvfxfluid, smoke plume over a black background cleans that up into an element you can composite. And it describes material and light, which the doodle genuinely cannot say: wildfire and smoke plume, brown soil in the foreground, trees behind the fire, blue sky at the top of frame.

Put this into practice

About half an hour, most of it downloading.

1. Install the node pack. ComfyUI Manager, search "LTXVideo", install ComfyUI-LTXVideo. On a recent ComfyUI you may hit an import error on pad from Kornia. Open the file named in the traceback, remove the pad import, add pad = F.pad below it, restart. The author documents this fix because everyone hits it.
2. Accept the gates and place the models. The LTX 2.5 transformer, both VAEs and the Gemma text encoders are gated on Hugging Face. A free account and a click-through clears it. Put ainvfx-fluid.safetensors in ComfyUI/models/loras/.
3. Run the shipped example before you paint anything. Copy the two PNGs from the repo's workflow/inputs/ into ComfyUI/input/, load the workflow, queue it. It opens pre-painted with a smoke plume, so your first run tests your install rather than your painting. This is the step people skip and then spend an hour debugging the wrong thing.
4. Load the LoRA correctly. Use LTX IC-LoRA Loader Model Only at strength 1.0. The loader reads the reference downscale factor from the file, so there is nothing to set. A generic LoRA loader ignores the reference path and silently drops the conditioning, which produces a plausible video with none of the control applied.
5. Repaint. The workflow uses two Painter nodes piped one into the other, so the second opens on your first frame and you paint the change on top. Painter needs Nodes 2.0, which you turn on in ComfyUI settings. One bug to know: if a Painter's output stops reaching the graph, toggle Nodes 2.0 off and on again.
6. Generate. Distilled transformer, 8 steps, CFG 1, euler_ancestral, seed 42 to start. There is no separate scheduler with LTX; the step distribution is set through sigmas directly, and the shipped values put most steps in the high-noise range where composition gets decided.

Expect roughly 50 seconds for a five-second 512x512 element on a laptop 4090. That figure is the author's, on his hardware, and it is the one number in the whole write-up I would most want to verify on my own machine before planning around it.

Two ways to push quality when the element matters. Generate at higher resolution, up to the 1920x1088 the final training stage used. And swap the distilled transformer for the non-distilled LTX 2.5, because the LoRA was trained against the non-distilled base. Slower, better.

For production, treat it as a stock shot generator and composite. Generate over black, bring the element into Nuke or whatever you comp in, and put it over your plate. If you need the perspective solved, run two generations: one with the plate as the background to get the perspective right, one over black to patch.

The part that transfers: train your own

The reason this write-up is worth more than the adapter is that AInVFX published the entire bill.

Dataset. 52 stock clips from Pexels: bonfires, wildfires, grass fires, smoke over forests, chimney steam. 44 horizontal, 8 vertical, at 24, 25, 30 and 60 fps. The 30 fps clips were resampled to 25 and the 60 fps clips to 50 by timestamp, so motion speed is unchanged. Captions by Qwen3-VL, trigger word first.

Control videos were generated from the clips themselves, which is the trick that makes this affordable. Each keyframe was reduced to six flat colours, with the palette chosen from colours actually present in the frame rather than by surface area, so a flame covering 2 percent of the frame keeps its own colour instead of being averaged away. Between two and five keyframes per clip on the 8-frame grid, first and last always, each held for one to eight frames, black elsewhere. That variety is precisely why the finished model reads both a single painted frame and a held one.

Three-stage resolution chain, each stage warm-started from the previous one:

Stage	Pairs	Geometry	Steps	Learning rate	Time
1 · motion	40	576 x 320 x 321 frames	2000	1e-4	3 h 48
2 · shape and material	94	1024 x 576 x 121	1000	5e-5	2 h 26
3 · fine detail	206	1920 x 1088 x 33	500	2e-5	1 h 32

Rank 32, alpha 32, v2v target preset, reference downscale 2, batch size 1, 8-bit AdamW, FP8 base weights. Total 7 hours 47 minutes on a single RTX PRO 6000, caching and previews included, peak 24 GB of VRAM. Trainer is the ltx-2-dev branch of AkaneTendo25's musubi-tuner fork, built on kohya-ss/musubi-tuner.

Set that against what Lightricks spent on its own Ingredients adapter, which its model card states plainly: rank 128, 12,000 steps, eight GPUs running DDP. Roughly eight GPU-hours on one rented card against a multi-GPU job an order of magnitude larger. The gap is the point. A single-purpose control adapter is a weekend and a two-figure rental.

Notice also the shape of the honesty. Three pairs were held out of stage 2 and used as sample controls, so every preview during training was on material the model had never seen. The final loss was about 0.26 and noisy, and the author says outright that the held-out previews were the signal and the loss curve was not. That is the correct way to evaluate a small generative adapter and almost nobody writes it down.

The recipe is model-agnostic in the way that matters: swap the dataset, keep the control video rules. If the effect you need is not smoke, nobody is coming to build it for you, and now nobody has to.

Honest limitations

Smoke, steam and fire only. Water, ink and clouds are hit and miss. Prompting recovers some of it and not all of it. If you need water specifically, Lightricks ships a separate Water-Simulation adapter for the same base.

It is not a plate matcher. You can paint your fluid over a photograph and use that as first and last frame, and the result keeps the composition and colours of the plate, but it is a video inspired by your plate, not a pixel-exact match of it. The model was never trained to reproduce a plate. This is the failure most likely to waste a day, because the output looks close enough that you keep trying to push it the rest of the way.

The grid is unforgiving. Off the 8-frame keyframe grid, or off multiples of 64, quality drops fast. Nothing errors. You get a worse video and no explanation.

The revenue cliff is real. The LoRA is a derivative of LTX-2.5 and ships under the LTX-2.x Community License. A company with 10M USD or more in annual revenue needs a paid agreement with Lightricks before using LTX-2.x or any derivative. The two sources disagree on where to look, which is its own small warning: the blog post points at Section 3.5, while the model card cites Section 4 on use restrictions plus Attachment A. Read the licence file in the repository rather than either summary, mine included.

One measurement, one machine. The ~50 seconds figure, the 7 h 47 training time and the 24 GB peak are all the author's own numbers on his own hardware, published without an independent check. They are specific and plausible and they are still single-source.

Worth saying about the data: the 52 training clips are Pexels-licensed, which permits commercial use and modification without attribution, and the repository redistributes no clips, only weights and six painted sample controls. The author lists every training clip by Pexels video ID anyway. Given how many adapters ship with a dataset line reading "various sources," that list is the most unusual thing in the repo.

What I would actually do with this

The adapter is useful and the method is the thing worth taking. A control video, a small dataset of matched pairs generated from your own source footage, rank 32, and an evening of rented GPU gets you a capability that did not exist and that nobody else was going to build.

The bottleneck is not compute anymore and it was never the model. It is knowing what pair to train on. Somebody had to decide that painted flat blobs were the right control signal for a fluid, and that decision, not the 7 hours 47 minutes, is what made this work.

So the question I would put to anyone with a shot list and a repetitive note: what is the drawing you keep making by hand, and what would it look like as one half of a training pair? If you can answer that, the rest of it is documented.

If you train one, publish the control rules. That is the part the next person needs, and the one most people leave out.

---

Medium metadata

• Title: Paint Six Flat Colours, Get Fire: The Control Video Is the Real Interface
• Subtitle: A free LTX 2.5 adapter turns painted blobs into smoke and fire in about a minute, and it published every training number, so the recipe transfers to whatever effect you actually need.
• Tags: AI Video, VFX, ComfyUI, Machine Learning, Open Source
• Suggested read time: 9 minutes
• Canonical sources: ainvfx-fluid on Hugging Face · AInVFX write-up · 45-minute video walkthrough · musubi-tuner ltx-2-dev · ComfyUI-LTXVideo