FL_MiniMaxH3MotionCollect

FL MiniMax H3 Motion Collect is the last internal stage of FL MiniMax H3 Motion Refine in shot-plan mode. Refinement fans out into one prepare/sample pair per planned render; this is what folds them back into a single image batch and a single report. Dev-only, not in the node menu unless dev mode is on, and normally built for you by the refine node.

What it does

It takes total_frames and two autogrow inputs: images, whose ports are named shot_0, shot_1, … and reports, with the same naming. In the expanded graph the refine node wires each shot's sampled images to images.shot_N and each shot's report to reports.shot_N, then hands the whole thing the authored total from the plan.

Execution is four checks and a concatenation. The port sets have to match shot_0 … shot_{N-1} exactly in both inputs - no gaps, no strays, no shuffling. The frame counts have to sum to total_frames. Then it concatenates along the batch dimension in index order and emits the batch, plus a report that opens with N shots assembled into T frames at 24 fps; original cuts preserved. and then appends each shot's own report underneath.

Two outputs: IMAGE (feed it to Create Video at 24 fps, with your original soundtrack), and STRING (wire it to Preview Any - in a multi-shot render it's the only place the per-shot timing and step counts survive).

Why the strictness is a feature

There's a temptation to read the key-matching as pedantry. It isn't. In shot-plan mode the shots have unequal authored lengths, some carry hidden motion-context prefixes that must not appear in the output, and the frames you get back are on the original clock rather than the stretched one. Concatenate in the wrong order, or silently drop a failed shot, and you get a video that looks plausible for ten seconds and then cuts to something that happened later. So the node fails instead:

• assembled shots are incomplete or out of order - typically you bypassed or muted the middle shot's branch, or the autogrow ports no longer line up with the plan after an edit. Recheck the expanded graph, not the parent node.
• recovered shots do not match the authored duration - the frames don't add up to the plan's total. Often the artifact of editing the shot plan (adding a beat, changing a render group, turning on Shot Motion Context) without re-sampling, so the latents carry an older authored length.

Both are plan-versus-latent mismatches at heart, which is why the sibling node FL MiniMax H3 Motion Shot tends to fail first with the same root cause. Fix the plan/latent agreement upstream and this node goes quiet.

Install

Nothing to install beyond the pack itself. ComfyUI Manager, search FL MiniMax H3; or:

cd ComfyUI/custom_nodes
git clone https://github.com/filliptm/ComfyUI-FL-MiniMaxH3.git

Restart ComfyUI. The pack's only declared dependency is huggingface_hub (used by the VDN node's weight download), so nothing here pulls in a heavy stack. You still need current ComfyUI with native H3 support, the H3 model/encoder/VAE files, and ComfyUI-MAINodes for the refinement path.

Worth knowing before you use it

Exact frame counts matter here in a way they don't for a single continuous render. The 17k+5 grid means a "5 second" request and a "121 frame" request are different things, and shot boundaries are authored in frames on the 24 fps timeline. If your assembled clip is one shot short or a few frames off, read the report strings before touching the graph - the per-shot reports state the authored length and hidden prefix for each render, and the mismatch is usually visible in two lines.

Also: collection happens after refinement, and refinement is not a restoration pass. Frames come back on the right clock with new detail in them; they don't come back as the original pixels. If you're comparing against a baseline, keep that baseline in its own branch - the pack's comparison pattern holds the baseline render and the refinement seed fixed and swaps coverage off against balanced, rather than refining and un-refining in one chain.