BFS H3 Native Shot Continuity (Experimental)

The problem it solves, honestly

You're generating a 20-second take in chunks of 107 frames because that's what MiniMax H3 will give you at sane VRAM. Every chunk is a fresh generation. Chunk two has no idea what chunk one's wardrobe, lighting or face looked like, so you get a jump - sometimes a subtle one, sometimes the character becomes a different person who happens to be standing in the same room.

BFS H3 Native Shot Continuity (Experimental) is the cheap fix: after each segment, take that segment's last generated frame, append it to the reference Pictures for the next segment, and tell the prompt what it's for. That's it. The author is careful to call it "native still-image continuity, not first-frame latent locking," and that disclaimer is doing real work. H3 sees an extra image reference. Nothing is pinned at the latent level, nothing is composited, and nothing guarantees a seamless boundary.

In a workflow it sits between your reference bundle and the H3 conditioning node, with the loop state threaded through it:

Describe References → Continuity → Native Reference Set to Video
Loop Start ────────→ Continuity

How it works

The node reads the loop state, looks up which segment it's on, and checks two things before doing anything. If this is the first segment, or the current segment begins at a camera cut, it passes everything through untouched and says so on continuity_status. Continuity is only meaningful within a continuous take - you don't want the end frame of a wide shot glued onto the start of an unrelated close-up.

If it is mid-take, it loads the previous segment's saved frames from the loop's temp folder, takes the final frame, and appends it as the next available Picture. Then it appends a written instruction to your prompt: that Picture number is the last frame of the preceding segment of this same take, use it for consistent scene appearance, identity and wardrobe at the boundary, keep following the current guide's performance and timing, don't freeze on the anchor's pose. Original Picture numbers are untouched, which matters because everything downstream - cast bindings, describe-references, regional weights - indexes Pictures by number.

Inputs and outputs

references (the BFS_H3_REFERENCE_SET bundle) and prompt go in on one side and come back out the other side, with the anchor appended. loop_state comes from BFS H3 Native Shot Loop Start. enabled defaults to true; switch it off to A/B the result, which you should.

continuity_status is the field people ignore and then complain about. It's a plain string that tells you Continuity OFF: first segment, Continuity OFF: camera cut, Continuity OFF: disabled, or Continuity ON: previous final frame is Picture N. Wire it to a text preview. Five seconds of setup, saves you twenty minutes of wondering why nothing changed.

The hard limit: at most 8 user reference images while continuity is active, because H3's native node caps at 9 Pictures including the anchor. Nine references plus the anchor throws.

Install

It ships in the same pack as the rest of the H3 loop nodes:

cd ComfyUI/custom_nodes
git clone https://github.com/alisson-anjos/ComfyUI-BFSNodes.git
cd ComfyUI-BFSNodes
pip install -r requirements.txt

Then restart and refresh the browser. You need ComfyUI new enough to have dynamic graph execution - the loop end relies on it, not this node - plus the usual H3 model and VAE loaders. Nothing extra to download for continuity itself.

Common issues

It throws about needing a free Picture slot. You have nine references wired. Drop to eight.

The output length is right but the seams still pop. That's the honest failure mode, not a bug: this is soft image conditioning. The docs admit continuity "may still bias composition or propagate errors." If segment one drifted off-model, segment two inherits the drift. Disable the node and compare - sometimes a clean reset at a cut looks better than a propagated error.

Someone changed the loop length and the folders piled up. Every run gets a folder under ComfyUI/temp/bfs_h3_native_loop/<session> holding float frame tensors. Those get big. The manifest there is a record, not a resumable checkpoint - there's no auto-resume if the run dies. Delete the session folder after you've saved the final video, and definitely not while a run is still going.

No cuts are being detected. There are no cuts to detect - this pack's native loop nodes don't do scene detection. You enter frame indices yourself on Loop Start, or you accept fixed-length chunks. The pack's separate Planner/Shot Loop path has PySceneDetect, this one doesn't.