MiniMax H3 Atomic Shotboard Conditioning

In the "atomic" H3 backend, each segment of your shotboard gets its own self-contained conditioning pass, and this node is where that pass happens. IAMCCS_MiniMaxH3AtomicConditioningBackend takes the shotplan out of cine_linx, figures out which task the current segment is (T2VA, I2VA, FL2VA, or REF2VA), and builds the matching conditioning and the AV latent - all in one step. Outputs include model, positive, latent, first_frame, planned_last_frame, and a reference_manifest_json describing what references went in, plus prompt (the resolved prompt, so you can see exactly what the segment was told).

The docstring says "Build matching T2VA/I2VA/FL2VA/REF2VA conditioning and AV latent" and that's the whole job, but the "matching" is where the depth is. A REF2VA segment conditions on reference images, reference video, and reference audio; a FL2VA segment conditions on first and last frames; a T2VA segment barely needs media at all. One node handling all four means the graph stays the same shape regardless of segment type - the backend just routes the inputs it was given. That's the architectural bet of the atomic backend: identical wiring, per-segment behavior.

The inputs that matter:

• model, clip, video_vae, audio_vae - the always-on quartet. These are the same models the router handed you (model from IAMCCS_MiniMaxH3AtomicModelRouter).
• cine_linx + segment_index - where the shotplan and the per-segment task live. Everything downstream of these two is optional, which is what makes the node flexible.
• bridge_frame - the continuity hand-off frame from the previous segment. This is how the atomic pipeline avoids the classic long-form failure of each segment starting from scratch. The pack's whole motion-continuity story (the IAMCCS_H3_MOTION_CONTEXT type, motion_state in/out) hangs off this.
• first_frame_override / last_frame_override - jam in specific keyframes for FL2VA segments instead of trusting the plan.
• ref_image_1..4, ref_video, ref_video_audio, ref_audio - the REF2VA reference media, straight from your Cine Info nodes.
• prompt_override - per-segment prompt escape hatch; leave empty to use the shotplan's prompt.
• render_id - names the render, used to keep segment artifacts addressable.

Outputs, in the order you'll wire them: model (patched), positive (conditioning), latent (the AV latent the sampler will denoise), first_frame / planned_last_frame (IMAGES - planned_last_frame is gold for previewing what continuity expects before you spend a render), reference_manifest_json, prompt, current_segment / total_segments / trim_head_frames (the loop contract the queue uses), report, and motion_state (the continuity context that flows into the next segment).

Installation: search IAMCCS in ComfyUI Manager or clone https://github.com/IAMCCS/IAMCCS-nodes.git into custom_nodes, restart. The real requirements are external and heavy: a current ComfyUI with native MiniMax H3 AV conditioning, the H3 model family (the router picks which branch), the Qwen3-VL text encoder, H3 video + audio VAEs, and - per the pack's workflow doc - at least 32GB system RAM is practical, 64GB recommended, with 12GB VRAM supported through dynamic offload. This is not a lightweight node and it doesn't pretend to be.

Where people get burned: it's the per-segment backend, so a segment_index that doesn't match the router's is how you get conditioning built for segment 3 while sampling segment 2 - the report output prints both, so check it on your first segmented run. And the bridge_frame hand-off is what keeps multi-segment identity stable; if your segments drift at the boundary, the fix is almost always the bridge and motion context, not the prompt.