DiffusionGemma Advertisement Multi-Shot Planner

DiffusionGemmaAdvertisementMultiShotPlanner is the node that makes a 30-second ad physically renderable at all. MiniMax H3 generates clips of roughly 4–15 seconds, so a governed 30-second campaign cannot come out of one H3 invocation - it has to be divided into lanes. This node takes the campaign's full native-shot H3 prompt and divides it into at most four lanes, each capped at 15 seconds, while preserving every native [Shot N] block. That distinction - native shots are a storyboard concept, lanes are a generation-duration concept - is the entire trick, and this pack treats it as a contract, not an approximation.

The inputs are the advertisement_contract_json, the full base_h3_prompt, shot_metadata_json and lane_states_json (normally supplied by the Planning Defaults node), and performance_mode - Natural/audio-led sync, Dance/music sync, or Lyrics + lip sync. The planner then picks where to cut between lanes. It prefers boundaries at native shot cuts where measured recovery is clean, falls back to native or mixed evidence, and only as a last resort uses deterministic duration-balanced seams. Here's the subtle part: when it must cut mid-shot, it doesn't just slice blindly - it carries the still-active source shot into the next lane so later native timestamps stay exact, and it rebases timestamped cues instead of letting them fire early or vanish. Continuity is preserved by design, not luck.

On outputs, the top of the list is advertisement_plan_json - the authoritative plan the assembler consumes - plus generation_lane_count, and then a full fan-out for each of up to four lanes: lane_N_prompt, lane_N_start, lane_N_duration, lane_N_frames, and lane_N_ready. So a 30-second campaign with, say, eight native shots might come out as two 15-second lanes; the planner reports exactly how many frames each lane owns so the assembler can trim precisely.

The identity discipline is baked into the lane prompts: every lane re-states the performer authorities (Pictures 1 and 2), the product authority (Picture 3), and product presence, while Picture 4 carries only the retained previous-lane tail for continuity. In practice that's the difference between a two-lane campaign where the performer visibly changes between lanes and one where they persist. This is the pack leaning on everything the character-consistency field learned: repeat the authority, keep the relay optional and bounded.

A beginner-friendly way to use it: wire the contract from the master contract node, feed the JSON outputs of Planning Defaults into the metadata inputs, connect the validated H3 prompt from your Director/splitter path, and read lane_N_duration and lane_N_frames before queueing H3 so you know what you're committing to. The honest caveat from the pack: missing ideal seam evidence is advisory, not fatal - but structurally invalid clocks, gapped shots, or more than four required lanes still fail closed. Don't try to hand-edit advertisement_plan_json to force a different split; regenerate from the planner, because the assembler and finishing nodes verify the plan hash and campaign revision.

Install is the pack install: ComfyUI Manager search "DiffusionGemma Prompt Builder", or clone into custom_nodes. The graph it belongs to wants ComfyUI 0.33.1+ and H3's model files; the planner itself is pure text/JSON planning and runs on CPU in a blink. Queue each lane as its own run and feed the retained tail back through the relay - that's the loop this planner was built to feed.