Viggle Chunk Loop Start
Where the crash-safe, disk-checkpoint Viggle loop begins
- cond_set
- initial_state
- loop
- state
- status
If you're here, you're considering the serious option for long Viggle-Animate clips: instead of one node sampling everything and only handing you a video at the very end, the four-node disk-checkpoint loop - Start, Sample Chunk, Loop End, Assemble - decodes and saves each chunk as it renders, and can pick up a cancelled run from the disk. Viggle Chunk Loop Start is the node that opens that loop. It reads the window plan from the windowed conditioning, sets up the run's checkpoint folder, and hands you the wires that make the whole graph-expanded loop go.
For context: this pack wraps Viggle-Animate, a 33B finetune of MiniMax-H3's ref2va for character replacement in video. A driving clip gives the motion, a reference still gives the identity, and there's no text prompt at all - just one frozen conditioning embedding. When your clip is longer than the ~124-frame chunks the model was trained on, you chunk it; the loop nodes are for when a long run is expensive enough that losing it to an OOM or a crash would actually hurt. The README's own guidance: use the loop even for two chunks if you can't afford to lose the run.
What it does
This node never samples. It takes the cond_set from Viggle-Animate Conditioning (H3, Windowed), whose window count is the loop count - you never set the number of iterations anywhere. It creates the run folder, initializes the loop state at chunk 1, and hands that state onward.
Inputs
cond_set- from the windowed conditioning node. The plan: window geometry, per-chunk conditioning, canvas.run_name- checkpoint folder name. Checkpoints go tooutput/viggle_chunks/<run_name>/, created automatically. Use a fresh name per project or take; reuse the same name (withresumeon) to pick up where a run left off. It's restricted to 1–64 letters, digits, underscores or hyphens - and don't try a reserved Windows name likeCONorNUL.resume- on by default. On re-queue it restores saved chunks whose checkpoint fingerprint still matches the current graph, models and settings. Change something and the run writes new checkpoint files under new names; your old takes stay on disk.initial_state- leave this disconnected. It's how the loop feeds the previous iteration's state into the next Start when Loop End expands the graph. Wiring it by hand is how you break the loop.
Outputs
Three: loop (VIGGLE_LOOP) which connects directly into Loop End's loop input - that raw wire is how Loop End finds the loop to expand; state (VIGGLE_LOOP_STATE) which feeds Viggle Sample Chunk; and status (STRING), a plain text output like "Chunk 1 of N" you can show or ignore.
Installing and wiring it
The whole loop lives in one pack, so:
cd ComfyUI/custom_nodes
git clone https://github.com/Saganaki22/ComfyUI-Viggle-Animate-H3
or grab ComfyUI-Viggle-Animate-H3 from ComfyUI Manager, then restart and refresh the browser (the pack ships a frontend extension for live progress). No pip install needed - it runs on ComfyUI core MiniMax-H3 support - but do update ComfyUI itself if it predates MiniMax-H3 nodes, and have the model files ready: the ref2va diffusion model (~21 GB pruned), the DMD LoRA, the frozen text conditioning in models/text_cond/, and the H3 video VAE.
The wiring recipe, once: Start state → Sample Chunk state, Start loop → Loop End loop, Sample Chunk chunk → Loop End chunk, and Start's initial_state empty. Then Sample Chunk's latent goes through your own VAE Decode, whose images feed Loop End's images - that's what forces each chunk to finish decoding before the next one starts sampling. Start sits at the top of the loop body, so it also re-runs each iteration; that's expected. When the loop completes, Loop End hands its chunks collection to Viggle Assemble Chunk Latents for the one final decode. It's an experimental corner of the pack, so expect to check the console log the first time - the node is chatty about the run folder and chunk plan, and the noise is usually informative.
One thing that trips people up: this is the fragile-looking part of the pack and it isn't. Start just makes a folder and reads a plan; all the recovery logic lives in Sample Chunk's checkpoints and Loop End's barrier. If a run dies at chunk 3, re-queue with the same run_name and resume on and Start happily reopens the folder - matching chunks restore, the rest resample.
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| cond_set | VIGGLE_COND_SET | — | |
| run_name | STRING | viggle_take_01 | Checkpoints go to output/viggle_chunks/<run_name>. Use a different name for separate projects. |
| resume | BOOLEAN | true | Load matching saved chunks; changed settings get new checkpoints. Completed chunks are decoded/saved again. |
| initial_stateopt | VIGGLE_LOOP_STATE | — |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| loop | VIGGLE_LOOP | — |
| state | VIGGLE_LOOP_STATE | — |
| status | STRING | — |