Viggle-Animate Conditioning (H3, Windowed)
The node that lets Viggle-Animate render a clip longer than five seconds
- cond_video
- ref_image
- text_cond
- vae
- cond_set
- guider_positive
The single-shot Viggle-Animate Conditioning (H3) node tops out around 124 frames - roughly five seconds at 24 fps. That's fine for a clip, but useless when your driving video is twenty seconds of someone walking through a room. This node, the "Windowed" variant, is what unlocks the long-clip path in the ComfyUI-Viggle-Animate-H3 pack. It never samples a thing. It reads your whole driving clip, chops it into overlapping chunks, and builds a separate conditioning entry for each one so the chunked sampler downstream can render them one at a time without losing the plot between chunks.
Quick context in case you landed here cold: Viggle-Animate is a 33B finetune of MiniMax-H3's ref2va transformer for character replacement in video - a driving clip supplies motion, camera and timing, a reference still supplies identity. There's no text encoder and no prompt; conditioning is one frozen 362-token embedding loaded with the pack's Load Text Conditioning node.
How it works
The driving clip is the plan. Its length gets snapped down onto a 17j+5 frame grid (124 = 7×17+5, and the H3 video VAE encodes 17 frames into 5 latent frames), so a clip can quietly lose up to 16 tail frames. Then the clip is split into windows of chunk_frames with overlap_frames of shared footage between neighbors. The last window is placed flush with the clip's end, so it tends to overlap more than you asked for.
Each window gets its own conditioning entry: that window's own footage as the video reference (chunk 3 never conditions on frames it can't see), plus the reference still, which is encoded once and broadcast to every chunk. The one clever bit: with the stock ComfyUI H3 VAE, complete 17-frame encoder blocks from the preceding window's encoding are reused rather than re-encoded, which trims a chunk of repeated VAE work. The console log tells you how many blocks got reused.
The inputs that matter
cond_video- the whole driving clip at 24 fps. Its grid-snapped length is your output length; cut the tail with the loader'sframe_load_capif you want it shorter.ref_image- the reference still, shared by every chunk. A repainted frame from the driving shot with matching pose and framing gives the strongest identity hold. The closer the still's pose to the footage, the less identity drift you get.chunk_frames(default 124) andoverlap_frames(default 22) - the window schedule. 124/22 is the finetune's evaluated operating point; start there.width/height- 0 means "use the driving clip's own size," which is what was tested. Override only if you want a different canvas; values round to 32 and the reliable range is roughly 0.4–1.2 MP.text_condandvaecome from Load Text Conditioning and the MiniMax-H3 video VAE.
Outputs
Two: cond_set (type VIGGLE_COND_SET) feeds either the Viggle Chunked Sampler or Viggle Chunk Loop Start. guider_positive (a normal CONDITIONING) connects to BasicGuider's conditioning input - but it's a placeholder: the samplers replace the positive per chunk from the cond_set, and this output only exists so the guider's required socket has a source and your graph validates.
Installing and running it
This is one of six nodes in the pack, so install the whole thing:
cd ComfyUI/custom_nodes
git clone https://github.com/Saganaki22/ComfyUI-Viggle-Animate-H3
Or find ComfyUI-Viggle-Animate-H3 in ComfyUI Manager and install from there. Then restart ComfyUI and refresh the browser tab (the pack ships a small frontend extension for live progress). There are no extra pip dependencies - the pack runs on core ComfyUI MiniMax-H3 support - but your ComfyUI needs to be reasonably recent, and you still need the model files: the pruned ref2va diffusion model (~21 GB), the DMD LoRA, fixed_embed_fwd_anyframe.safetensors in models/text_cond/, and the MiniMax-H3 video VAE. Load the driving video at 24 fps (force_rate = 24) with frame_load_cap = 0 so VHS hands over the whole clip. KJNodes is only needed for the example workflows' CustomSigmas and fast previews.
Two gotchas worth knowing. First, dropping those up-to-16 trailing frames for the grid is expected, not a bug - leave headroom if the end of the clip matters. Second, don't go looking for sampling knobs here; they live on the sampler: keep ModelSamplingMiniMaxH3 at shift 3.0 and feed the ManualSigmas baseline 1.0, 0.8571428571428571, 0.6, 0.0 (4 sigma points, only 3 model passes - what upstream calls "4 steps"). One aside worth repeating from the README: the weights are a derivative of MiniMax H3, so the MiniMax H3 Community License applies to them - geofenced out of the US, EU, UK and South Korea - even though the node code itself is Apache 2.0.
Inputs (8)
| Name | Type | Default | Description |
|---|---|---|---|
| cond_video | IMAGE | The whole driving clip at 24 fps. All loaded frames are used as reference. Generation ends on the next H3 frame-grid boundary, up to 16 frames longer (minimum 5). | |
| ref_image | IMAGE | Reference still shared by all chunks. A repainted frame from the driving shot with matching pose and framing gives the strongest reference. | |
| text_cond | TEXT_COND | From the Load Text Conditioning node. | |
| vae | VAE | MiniMax-H3 video VAE (from the base model). | |
| width | INT | 00–16384 | Target width. 0 = driving clip's own width (the evaluated configuration). |
| height | INT | 00–16384 | Target height. 0 = driving clip's own height. |
| chunk_frames | INT | 12422–3600 | Maximum window length on H3's 17k+5 grid. The final window can be shorter. 124 is the usual baseline; shorter windows need visual testing. |
| overlap_frames | INT | 225–3600 | Overlap carried from the preceding chunk and preserved during sampling. Clamped below the window length so each chunk generates new frames. |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| cond_set | VIGGLE_COND_SET | — |
| guider_positive | CONDITIONING | — |