BFS H3 Workflow Options (SAM / Loop)

It's a switch. That's the whole node.

BFS H3 Workflow Options (SAM / Loop) takes two booleans and gives them right back. use_sam31 in, use_sam31 out. use_shot_loop in, use_shot_loop out. Both default to false. There is no computation, no caching, no magic.

If you've spent any time in ComfyUI you know why something like this exists. A boolean widget lives on some node's panel; to toggle two branches you'd otherwise have to hunt for the two different widgets it's wired into, or unroll a reroute and rewire. Here the author labels one node START HERE at the top of the example graph, and from there you drive the whole topology: SAM cast masking on or off, shot loop on or off.

That's worth an article only because the consequences of those two switches are unusually well-behaved, and understanding that is the difference between a workflow that runs on a laptop with no SAM checkpoint and one that doesn't.

What each switch actually controls

use_sam31 feeds BFS H3 Optional SAM 3.1 Model's enabled. Off means the loader never resolves a path, never loads weights, and returns nothing - no checkpoint required. It also gates the click selector and the tracking node, whose inputs are lazy, so the whole SAM branch can sit in your graph looking wired while costing nothing. The docs call the branch "lazy" and that's literal: disabled branches don't execute at all.

use_shot_loop feeds BFS H3 Native Shot Loop Start's enabled. Off and you get one segment containing the entire loaded clip: no repeated sampling, no continuity handoff, and chunk_frames / camera_cuts are simply ignored. On and the loop runs as configured.

Both on is the combination people actually want eventually: track the full loaded video once, then slice those masks per shot inside the loop. That sequencing matters - you don't want to re-run SAM for every segment, and the apply node exists specifically to do the slicing.

Why a dedicated node beats "just set the widget"

Two reasons, both practical.

First, it is one place. In the example graph there are four or five nodes whose behaviour has to change coherently when you flip a mode. Wiring one boolean to all of them is exactly what the KB's writing on ComfyUI plumbing calls the "one source, many consumers" pattern - a primitive that drives several widgets is less error-prone than three widgets in three panels that you'll forget to keep in sync.

Second, it survives handoff. If you publish a workflow, the recipient sees a node literally labelled as the options node at the top. They flip two checkboxes. They don't have to reverse-engineer which of the forty grey nodes in the middle decides whether SAM loads.

The cost: these booleans are pure pass-throughs, so nothing stops you wiring use_sam31 from this node into a loader and hard-coding the tracking node's enabled to true elsewhere. Contradictory state, confusing errors. Let the options node be the only switch.

Install

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

Restart, hard-refresh the browser tab. Requires BFSNodes 1.115.31 or newer for the optional-branch example workflow (examples/h3_tara_optional_sam_loop.comfy.json); the pack is at 1.115.33 as of this writing. You don't strictly need this node to run anything else in the pack - it's a convenience wrapper around two existing booleans.

One caveat about expectations: the pack's validation for this pattern is CPU checks on the disabled/lazy branches and the graph links. No browser or GPU end-to-end run has been signed off, so "both OFF" working in the bundled example is asserted by the author's test suite, not by a community of users. Given BFSNodes turns up in two Reddit threads in the entire modidex corpus, you are very early. Load the example, queue once with both switches off, and confirm the plain single-pass generation looks right before you start enabling branches.

Common issues

Nothing downstream runs. If use_sam31 is on and the SAM checkpoint isn't in models/checkpoints, the loader raises on purpose - that's the deferred check doing its job. Either drop the file in or switch it back off.

You toggled it and the graph looks the same. Your downstream nodes have their own enabled widget set to false, which wins. The output booleans are just values; they can't override a widget.

Loop settings seem ignored. use_shot_loop off. chunk_frames, chunk_seconds and camera_cuts do nothing in single-pass mode, by design.

The token editor started blocking sampling. Unrelated to this node, but a common pairing: in these example workflows the token editor is set not-inspect-only by default from 1.115.30, while older saved workflows keep their own value. If a queue finishes in a tenth of a second with no video, check that before blaming the switches.