Nodes/IAMCCS-nodes/MiniMax H3 Last-Frame Bridge
ComfyUI Node

MiniMax H3 Last-Frame Bridge

The tiny node that keeps shot B picking up where shot A ended

By IAMCCS·Created 11 months ago·Updated 4 days ago· 113
MiniMax H3 Last-Frame Bridge
  • fallback_image
  • cine_linx
  • image
  • exists
  • report
segment_index0
render_idminimax_h3_render

Multi-segment video generation has one classic failure mode: every segment starts from the same first frame, so your "film" is actually a series of disconnected clips where the subject teleports between cuts. The MiniMax H3 Last-Frame Bridge is the fix, and it's almost insultingly simple - it loads the final frame of the previous segment from disk and hands it to the next one as its opening frame. That's the whole job.

How it works

The node takes a segment_index and a render_id. For segment 0 there's nothing to bridge, so it returns your fallback_image (or a black frame) with exists = 0. For any later segment, it looks for a bridge file - a single frame the previous segment's backend saved to a render-specific directory - and loads it if present. Found it, you get the image and exists = 1; not found, it falls back to fallback_image if one's connected, and otherwise raises a FileNotFoundError with a message telling you to start the queue at segment 0 or connect a fallback.

The clever part is where the frame lives: on disk, keyed by render_id, not passed through the graph. That means the bridge survives across separate queue runs, and a long multi-segment render doesn't need to hold every previous shot's frames in VRAM to maintain continuity. The frame travels by filename, not by tensor.

Why you'd reach for it

You won't use this node directly if you're running the full Shotboard workflow - the Shotboard Backend handles bridge resolution internally, with bridge_frame as an optional input. This node exists for people hand-building an H3 graph segment by segment: you generate shot 1, its last frame lands on disk, and the Bridge Load feeds shot 2's conditioning. It's also handy for testing a single later segment without regenerating everything before it.

Inputs and outputs

Three inputs, all of which you've met: segment_index (which shot you're on), render_id (must match the id the previous render used, or the bridge file won't be found), and fallback_image (optional). Outputs are image (the bridged frame, or fallback), exists (1 or 0), and report - a string that tells you exactly which path it took, which is useful when the bridge silently fell back and you're wondering why the shot starts from a black frame.

Installing it

Same pack as all of these: ComfyUI Manager (search "IAMCCS") or git clone https://github.com/IAMCCS/IAMCCS-nodes.git into custom_nodes, restart. No extra dependencies - it's a file lookup plus a tensor load.

Where people get burned

The render_id mismatch is the classic one. The backend saves bridges under a render id, and if your Bridge Load node has a different id - or an empty one - the file won't be there and you'll hit the FileNotFoundError (or worse, a silent fallback to a black frame with exists = 0). Keep the id identical across the whole graph. And remember this node only loads the bridge; it doesn't create one. No previous render, no bridge, no magic.

CategoryIAMCCS/MiniMax H3

Inputs (4)

NameTypeDefaultDescription
segment_indexINT00–1000000
render_idSTRINGminimax_h3_render
fallback_imageoptIMAGE
cine_linxoptIAMCCS_SUPERNODE_LINXConnect IAMCCS NextFrameBuilder: selected storyboard frames become the initial/slot bridge images.

Outputs (3)

NameTypeDescription
imageIMAGE
existsINT
reportSTRING