MiniMax H3 Storyboard Generator 🐑

Every long AI video starts the same way: you queue eight clips, wait, and discover the story made no sense. MiniMaxH3StoryboardGenerator makes you look at the plan first. Give it a concept and a target shot count and one LLM call returns a structured storyboard - beats, shot sizes, camera moves, transitions, durations - as a table you can read and a JSON array your tooling can chew.

It's a planning artifact and stays one. This node doesn't write H3 prompts and doesn't touch the Production Plan; that's MiniMaxH3LoopPromptGenerator's job further down the graph.

What you set

• concept - the whole story in a paragraph. Blank falls back to a built-in "short cinematic moment with a protagonist" default: useful for seeing the output shape before committing a real idea.
• shot_count - what you're asking for, 1 to 20. It's a request, not a contract: read the third output pin for the real number.
• style - how beats get arranged, and the dropdown that changes the board most: narrative_arc (three-act), parallel_montage, rhythmic_cuts, single_continuous for the one-take look, character_study.
• genre - a 22-entry taxonomy shared with the pack's H3 prompt generator, so the advice here and downstream don't contradict each other.
• output_format - how storyboard_text renders: table (Markdown table), detailed (multi-field per shot), minimal (id plus description).

language picks the prose language (en / zh; English by default because H3 behaves better with it). Advanced knobs are temperature at 0.8 - a storyboard is the one place in this pipeline where you want creative layout, not obedient formatting - plus max_tokens and timeout.

What comes out

• storyboard_text - the rendered board. This is the one humans read and edit.
• shots_json - the normalized array: shot_type, camera_movement, transition_in, duration_seconds, narrative_beat, plus characters, props, notes. Shot types come from a fixed whitelist (extreme_wide_shot through extreme_close_up, over_the_shoulder, point_of_view, two_shot, insert_shot, …) with unknown values falling back to medium_shot, durations clamped, ids uniqued. So the JSON is safe to key on, which is more than you can say for most model output.
• shot_count (INT) - what the board actually contains.

One wrinkle before you wire it: the docs describe feeding shots_json into the Loop Plan Generator, but the loop node's only free-text input is user_input - there's no shot-list socket on it. The handoff is text: read storyboard_text, edit what you disagree with, paste it into user_input (or the enhancer's draft). The board is your thinking space; the loop node turns prose into plan-shaped prompts.

H3 timing note: duration_seconds is the field to respect. H3 generates 4–15s per call and the loop node caps every scene at 14s, so a board planning eight 20-second shots is a board you'll be re-cutting.

How it behaves when the model misbehaves

It asks for a JSON array in one call, tolerates a bare array, a ```json fence or prose around it, and strips a leading <think> block from a reasoning model. If the array still won't parse it does one corrective retry - a "your last reply was malformed" turn - then fails the node outright. No partial boards, which is the behaviour you want when a bad board would otherwise become twelve paid generations.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/MieMieeeee/ComfyUI-MieNodes
cd ComfyUI-MieNodes && pip install -r requirements.txt

Or find ComfyUI_MieNodes in ComfyUI Manager - it's on the Comfy Registry under publisher mie. No models, no heavy dependencies: just a Set*LLMServiceConnector with a working key (or a local Ollama endpoint, which costs nothing per call and handles this job fine).

Where people get burned

• A local 8B model that won't emit JSON. The contract is a JSON array, and the failure is a hard fail, not a shrug. Keep getting "unparseable after 2 attempts" on a small local model? Switch that one node to something bigger - it's the least frequent call in the pipeline, so it's the cheapest place to rent quality.
• Reasoning models and max_tokens. The 8192 default already assumes some models burn budget thinking before they answer (the source of this repo notes exactly that failure: HTTP 200, empty content). If you drop it low "to save money", that's what you'll get.
• shot_count isn't honoured to the digit. Models round, merge and pad. Trust the output pin, not the number you typed.
• It plans, it doesn't prompt. No dialogue is locked verbatim, no <d> blocks are emitted, no continuation rules are written. If what you want is a shootable H3 plan, this is step one of two - the loop node is step two.