MiniMax H3 Aicg 分段采样
Segment Render samples the whole shot list — and carries motion forward between them
- h3_context
- sampler
- sigmas
- model
- sampling_plan
- segments
Here's the honest framing: most "long video" workflows are last-frame chaining with extra steps. Generate five seconds, grab the final frame, feed it back as an image, generate five more. It works, and it degrades - every hop is a VAE round trip, and after four or five segments the colour and the face have drifted.
AICG3D_H3SegmentRender - MiniMax H3 Aicg 分段采样 - is the node that does the first pass differently. It takes a whole context plan (the shot list with per-segment prompts and media) and samples it segment by segment, carrying the previous segment's latent tail forward instead of a JPEG of it. That's what the pack calls Motion Context-style continuity, and it's the reason the seams in an AICG3D render are usually better than the last-frame-chaining version.
The mechanism
The context node hands over a plan: N shots, each with its prompt, its frame budget, its media references. Render walks that list. For each shot after the first, it slices the phase-aligned tail of the previous shot's sampled video latent - the raw latent, aligned to H3's temporal grid - and attaches it as keyframe guidance for the new sample. No decode, no re-encode, no lossy hop. The audio tail gets carried alongside it, which is why dialogue doesn't restart at every boundary.
The alternative continuity modes (RGB guide, the AV modes) are set on the context node, not here, and they trade that lossless handoff for a tighter visual match at the cost of one extra decode per segment. Latent is the default because it's fastest and holds up fine for continuous camera moves.
Inputs and outputs
Required: h3_context, sampler, sigmas, seed, segment_seeds.
Optional: model (only if the context doesn't already carry one) and sampling_plan.
seedis the base noise seed. Note it has the usual control-after-generate widget, sorandomizewill re-roll it and invalidate the cache - which is expected, that's how you re-roll.segment_seedsis the interesting one.defaultmeans every segment uses the base seed. A comma list (11,22,33) assigns seeds per segment and quietly fills the rest from the base seed. More values than segments is an error. Use it when one segment out of twenty keeps doing something stupid and you want to fix only that one.sampling_planis where a strategy node plugs in - AICG3D_H3SelfLiftStrategy is the one shipped with the pack. Attach it and the sampling path changes from "plain denoise" to "progressive resolution".
Output: segments (MINIMAX_H3_SEGMENTS). Wire it to 分段解码 for a preview, or to 分段二采 if you're doing a high-res delivery pass.
Install
Standard pack install - there is no separate dependency for this node:
cd ComfyUI/custom_nodes
git clone https://github.com/JGRFW/comfyui-AICG3D
Restart ComfyUI, hard-refresh (Ctrl+F5), and look under the AICG3D category. If you'd rather use Manager, search AICG3D, 短剧工作台, or MiniMax H3.
You'll also need a MiniMax H3 model bundle before any of this runs - this node won't load weights for you, it expects a context with an attached bundle. Note the licensing reality while you're downloading tens of gigabytes: H3's community licence excludes the US, EU, UK and Korea from its applicable territory, so running the local weights in those regions isn't licensed at all. The hosted API is the legal path there.
Things that bite
The chain is impatient with mismatched plans. Every segment step re-reads the plan from the setup and checks that the plans are literally the same object. Editing the context node so it rebuilds its plan mid-chain, or mixing two contexts, gets you "the chained Segment Steps come from different H3 Context plans". Rebuild the chain instead of patching it.
Random seed, same seeds. With control_after_generate on randomize, a cached result can look stale after a rerun if nothing else in the graph changed. If a re-run gives you the identical video, force re-execution or nudge segment_seeds.
A sampling plan changes the memory profile. SelfLift samples a low-resolution stage first and lifts it, which needs the video VAE and an upscaler around at the same time. Smaller cards should be looking at the vram tier settings on the global config rather than at this node.
Clearing the chain runs it again, from scratch. Because segments are held on CPU between sampling and post-processing, a long chain is also a long time in system RAM. Don't queue three of these on one machine and then complain the box is swapping.
Inputs (7)
| Name | Type | Default | Description |
|---|---|---|---|
| h3_context | MINIMAX_H3_CONTEXT | — | |
| sampler | SAMPLER | — | |
| sigmas | SIGMAS | — | |
| seed | INT | 00–4294967295 | — |
| segment_seeds | STRING | default | — |
| modelopt | MODEL | — | |
| sampling_planopt | default | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| segments | MINIMAX_H3_SEGMENTS | — |