VACE Final Loop Assemble

VACE Final Loop Assemble is the finishing move of the pack's "make a loop" path. By the time you reach it, VACE Final Loop Prep has already carved your single clip into a retained middle section (loop_body) and your VACE pipeline has generated the tail-to-head transition that will turn it into a seamless loop. This node's one job: glue loop_body and loop_transition together in the right order and hand you the completed loop.

How it works

It's a validated concat. The node takes the two IMAGE batches, checks they share the same resolution and channels, and returns them concatenated - loop_body first, then loop_transition. That ordering matters: the loop is "your original clip, minus the replaced edges, plus a freshly generated transition that carries the tail back into the head." Put them in the wrong order and you get a loop that starts mid-transition instead of at the body.

There's a debug toggle (default false) that prints both input frame counts and the output total, which is genuinely useful the first time you wire this up - it's the fastest way to confirm the transition didn't come back the wrong length.

Inputs and outputs

• loop_body (IMAGE) - the retained middle frames, straight from VACE Final Loop Prep
• loop_transition (IMAGE) - the generated tail-to-head transition (your VACE decode output)
• debug (boolean, default false)

Output is a single images batch - the finished loop. From here it's VAE decode → video save, same as any other generation.

Installing it

Part of the comfy-vace-automation pack, no extra pip dependencies:

cd ComfyUI/custom_nodes
git clone https://github.com/EnviralDesign/comfy-vace-automation

Restart ComfyUI, or install via ComfyUI Manager (search "comfy-vace-automation").

When it bites you

• Resolution mismatch between loop_body and loop_transition. The error names both shapes, and the usual culprit is the VACE side upscaling or downscaling the generated frames. Keep the decode consistent with the prep's width/height.
• A transition that's too long. Nothing here trims - what you feed in is what you get out. If your loop comes out longer than expected, check the frame count you generated on the VACE side rather than expecting this node to fix it.
• Empty or near-empty loop_body. If the original clip was barely longer than context + replace on each end, Prep's loop_body can be tiny and the "loop" is mostly transition. That's a source-clip problem, not an assemble problem - give it a longer clip.

Is this node exciting? No. It's a two-input stitch that exists so the loop path stays explicit and debuggable instead of hiding the join inside a bigger node. When your loop looks wrong, the frame-count prints in debug mode tell you quickly whether the problem is upstream (generation) or here (assembly).