GPU LayerStyles TwoBatchBridge

This one is a pure plumbing node, and it's honest about it: give it a batch and a frame count, and it hands you back the two ends of that batch as separate, independent batches. The point is the workflow it enables - generating a bridge across a loop point or a clip join, rather than crossfading one.

What it does

Two inputs, no maths:

• images - the batch.
• blend_target - how many frames to take from each end. Default 15, minimum 1, and it must be less than the length of the batch, otherwise there's nothing left in the middle and the node errors with your numbers in the message.

Three outputs, all independent contiguous copies with the input's dtype, device and pixel values:

• bridge_first - the last blend_target frames, in original order.
• bridge_last - the first blend_target frames, in original order.
• first/last - a two-frame batch: the first frame of bridge_first followed by the last frame of bridge_last.

That third output is the one people squint at. Read it as the outer bracket of the junction: the earliest frame of the outgoing material and the latest frame of the incoming material. It's the pair you hand to something that wants exactly two endpoint frames for conditioning, while bridge_first and bridge_last - the longer overhangs - are what you actually push through a video model to generate the frames that connect the two ends.

The slices are allowed to overlap: set blend_target above half the batch length and bridge_first and bridge_last share frames. That's not a bug, it's a legitimate setting when a clip is short and you want generous handles on each side. And note there are no execution controls on this node - no output_device, no batch_size - because there's nothing to chunk. It's clone() calls on slices, and the memory cost is the copies.

Where it fits

The loop-and-stitch family, which is the current answer to "how do I get a video that loops". The KB's read on this is that seamless looping used to be AnimateDiff's one remaining niche, and it isn't anymore: the Wan-side answer is to generate or morph a transition and splice it in, either with a joiner node's Make Loop toggle or by assembling the pieces yourself. TwoBatchBridge is the "assemble it yourself" half of that - you decouple the preparation of the ends from the assembly, so the bridge generation can be a separate graph (or a separate model entirely) that just takes two batches in.

The typical shape: clip A and clip B both in hand, take the ends with this node, run a generation that turns the tail of A into the head of B, then join all three with TwoBatchLoop or CrossFade. Because the node hands out copies, whatever you do to a bridge output can't corrupt the source batch anywhere else in the graph - which, with a 300-frame batch, is a real thing to be careful about.

Install

ComfyUI Manager → search the pack title GPU LayerStyles. Or:

cd /path/to/ComfyUI/custom_nodes
git clone https://github.com/lany42/gpu-layerstyles
# restart ComfyUI

No dependencies install - the runtime dependency list is empty - and there are no models or keys involved. Requires Python 3.13+ and a recent ComfyUI with the comfy_api node schema (this pack is written in the newer style, so no NODE_CLASS_MAPPINGS to find). AGPL-3.0-only.

Getting burned

blend_target must be smaller than the batch. That's the only hard rule and it's easy to trip: a 15-frame-wide window on a 12-frame batch gets you an error, and short clips are exactly where you're tempted to reach for a big window.

Second, don't expect this node to do any of the joining. It doesn't interpolate, trim, or blend - the description is explicit that assembly is a different node's job. If you were hoping it would also stitch the bridge back in, that's TwoBatchLoop, and if you just want the two clips melded, that's CrossFade.