沐阳 H3 · 断点分段裁切（内部）

A twenty-segment H3 job is an hour of GPU time you don't want to spend twice. But it will crash, or you'll change the prompt on shot 11, or you'll notice the character's jacket is on the wrong side from segment 7 onward. Rearranging a storyboard is normal. Re-rendering everything to test a change to the last third of it is not.

H3DirectorPlanSlice is the resume mechanism. It cuts the storyboard plan down to a range starting at an absolute segment number, so the graph executes segment 4 onwards and leaves 1-3 alone on disk.

What it does with the plan

The input is plan_json - the same storyboard JSON the rest of the Director chain speaks - and start_segment (1-12, default 2), which is an absolute segment number in the original plan, not an offset. Set it to 4 and segment 4 of the original plan is the first segment this slice produces, keeping its original index. That matters because your existing output files, checkpoints and seam context are all keyed on absolute segment numbers; slice them wrong and you'll stitch segment 1's audio onto what is actually segment 4's picture.

overlap_frames (5-56, default 22) is the context window this slice should assume. It has to agree with the continuity chain you're re-joining, and the pack is blunt about it in the README: in a hand-wired graph, H3ScriptSplitter.overlap_frames must match H3LongVideo.context_length.

The optional context_video input (IMAGE) is the answer to "does the first segment of this slice need pinned head context?" Wire the previous segment's delivered frames and the sliced plan marks its first segment as needing context; leave it unwired and the first segment runs as a head-of-chain generation. That's a real distinction - resuming from segment 4 with the tail of segment 3 available produces a much better join than restarting cold at segment 4 and hoping the model re-derives the same lighting.

Output is a single plan_json string carrying the sliced plan forward.

Where it sits

Category 沐阳 H3/导演台/内部. In the normal Director flow you don't place it - you set a resume point in the UI and the Director builds a graph with this node in it. It's in the pack's resume support alongside H3LongTake's mode: redo_from options, and those two solve the same problem at different altitudes: this one reshapes the plan, the long-take nodes redo clips.

The reason to know about it is debugging. When a resumed job produces a seam that doesn't look like the others, the first question is whether the resume carried context. This node's context_video input is where that decision lives.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/civilcoco/ComfyUI-MiniMaxH3-Myang

Restart ComfyUI, hard-refresh. No dependencies beyond the pack - its dependency list is empty, and this node is JSON manipulation.

The usual model requirements apply: your own H3 diffusion model, Qwen text encoder, video VAE, audio VAE. The pack's workflows have been sanitised, so after loading the example you'll select your own model names, media, prompts and seed.

What will actually go wrong

The overlap mismatch is the one that catches people. If this slice assumes 22 frames of context but the graph it feeds was configured for 39, the first resumed segment is short by 17 frames of anchor and you'll see a visible jump - exactly the kind of thing that reads as "the model got worse on segment 4" when it's a wiring disagreement.

Second: resuming across a ComfyUI update. The pack's own compatibility note is that its structural tests cover ComfyUI v0.33.2 and v0.34.0, and that after any update you should validate a two-segment render before starting a long job. A resume is not the place to find out something moved. Also worth remembering that if you have ComfyUI-H3-Motion-Context installed alongside this pack, only one H3 continuity implementation should be active in a job - restart ComfyUI before switching.