DiffusionGemma H3 Relay Reference Gate

Multi-lane H3 rendering has a continuity problem that has nothing to do with prompts: lane 1 ends on frame 360 at some pose and wardrobe state, and lane 2 starts from your original reference images - so the subject can visibly "reset" between segments. DiffusionGemma H3 Relay Reference Gate is the low-budget fix. It optionally routes the retained tail of the previous H3 lane into the next lane as a continuity reference, so lane 2 (and 3, and 4) start from where lane 1 actually left off rather than from a fresh guess.

Read the design constraints and you'll see why this is a gate and not just a wire. The original identity references remain authoritative; relay is identity-first and off by default; and disabled downstream lanes don't request upstream media at all. It's a continuity aid for costume, pose, and scene state - never a substitute for your identity pictures.

Inputs

• shot_plan_json - connect plan_json from the Audio-Aware H3 Multi-Shot Planner. The embedded identity/relay policy inside the plan is authoritative; the gate validates the plan schema, version, readiness, lane list, identity-picture tags, and relay mode before doing anything.
• lane_index - default 2. The later generation lane that may consume the immediately previous lane's retained tail.
• relay_image - lazy optional: one retained final frame from the immediately previous lane. Because it's lazy, it isn't evaluated when relay mode is Off or this lane isn't planned - no wasted upstream decode.

Outputs: relay_reference (IMAGE, or None when relay is off), relay_picture_tag (the manifest role it occupies), enabled (boolean), and status.

The mechanism, in plain terms

When relay is on, the retained tail becomes a continuity Picture in the manifest - and because the planner can reserve Picture 1 (identity) and Picture 2 (multi-panel evidence of the same subject) for real authority, the relay tail slots in as Picture 3 (or Picture 2 in single-identity mode). The gate's docstring says it plainly: "Off returns None, which stock MiniMaxH3ReferenceToVideo skips as an absent optional image." That's the whole elegance - it uses H3's native "optional reference is just absent" behavior instead of hacking around it.

The gate refuses to operate on a plan that contradicts its policy: mismatched identity tags, a continuity requirement that conflicts with the reference policy, or a lane that isn't planned all raise rather than guessing.

Where it sits

Upstream, the Audio-Aware Multi-Shot Planner decides the lanes and whether relay continuity is wanted (continuity_relay_mode: Previous lane tail or Off). This gate executes that decision per lane. Downstream, the retained frames come from the actual rendered lanes - in the advertisement stack there's an even heavier sibling, DiffusionGemma Advertisement Relay Gate, that persists a hash-verified Picture 4 artifact across the campaign's governed H3 lanes. This node is the general-purpose, in-memory version for music-video production.

Installing it

Part of exportAnything/ComfyUI-DiffusionGemmaPromptBuilder, under prompt/diffusiongemma/production-planning:

cd ComfyUI/custom_nodes
git clone https://github.com/exportAnything/ComfyUI-DiffusionGemmaPromptBuilder

or search DiffusionGemma Prompt Builder in ComfyUI Manager and restart. Light node - validation and an optional image pass-through.

Common issues

• No relay happening even though you connected an image. Check the plan's continuity_relay_mode. If it's Off, or the lane isn't planned, the gate returns None by design - the relay_image input is deliberately unevaluated.
• Validation errors about identity tags. The gate enforces that the plan's policy matches the manifest tags exactly. If you changed identity_picture_count or the manifest in the planner, regenerate the plan - the gate won't accept a stale one.
• Continuity drift anyway. Relay reduces drift between lanes; it can't guarantee performer likeness across long multi-lane renders. H3 stays stochastic, so keep identity references strong and expect to curate.