VRGDG LongShot Collect 4 Keyframes

The unglamorous node that keeps the four-shot plan honest

Four coordinated stills is the shape the entire LongShot idea rests on. Chunk 1 starts from image one. Chunk 2 has to end on image two. Chunk 3 ends on image three, chunk 4 on image four - and each chunk's assigned still has to be generated at the same resolution and aspect ratio as the others, or the concatenated video is a mess of rescaled frames.

This node is the junction box for that. It takes four IMAGE inputs, asserts they agree, and re-emits them under names that state their role in the sequence.

How it works

It's about fifteen lines of Python, so here's all of it in prose. Each input is sliced to its first frame - keyframe_1[:1] - which means if you accidentally feed a batch of eight variations, you silently get frame one, not a keyframe explosion. Then the shapes are compared. If the four images don't share height, width and channel count, the node raises:

All four keyframes must have the same height, width, and channels to form a batch; received [...] . Generate every image at the same 16:9 resolution.

Then it torch.cats them into a single four-frame batch. No image processing, no resizing, no colour fixing. Its job is naming and validating, and it refuses to pretend otherwise.

Inputs and outputs

Inputs are keyframe_1 through keyframe_4, all IMAGE. That's it - no widgets, nothing to tune. That's a feature: this node is deterministic, so if the graph renders differently it's because something upstream did.

The outputs are the point:

• chunk_1_first_frame - the opening image for the first chunk.
• chunk_2_last_frame, chunk_3_last_frame, chunk_4_last_frame - the ending frame each later chunk has to land on.
• keyframe_batch - all four as a four-frame IMAGE batch, for a preview or save node.

The naming tells you the actual contract of the pipeline, which is easier to see here than in the LongShot description: chunk 1 has no supplied endpoint (motion continuity carries it forward), and chunks 2 through 4 each get a target frame to converge on. The Director Context node sets those global times as 0.000s for keyframe 1 and duration × 2, × 3, × 4 seconds for the rest - that node's reminders, this one's physical outputs.

Wire the four role outputs into your H3 / first-last-frame nodes, and keyframe_batch into a preview. Looking at all four side by side before you start generating is the cheapest quality check in the whole workflow, because a wrong wardrobe or a flipped screen direction is obvious in a contact sheet and invisible in four separate tabs. Continuity of identity and geography across separately-generated stills is the exact thing that goes wrong if you skip that check - same reason character work in this ecosystem always ends in "audit the set before you commit".

Install

Manager → search vrgamedev, or clone it:

cd ComfyUI/custom_nodes
git clone https://github.com/vrgamegirl19/comfyui-vrgamedevgirl.git
python -m pip install -r comfyui-vrgamedevgirl/requirements.txt

Restart, then hard-refresh the browser. This particular node has no dependencies of its own - no model files, no VHS, nothing to download - so if it's the only thing you want from the pack, you've still installed a fairly heavy requirements list to get it. If you're here for the LongShot chain as a whole, you were going to do that anyway.

When it goes wrong

• The shape mismatch error. You generated keyframes at different resolutions, or one of them came back from a model that rounded differently. Fix it upstream: 16:9 across the board, ideally the exact resolution your video model wants.
• Only one frame appears per keyframe. Expected. The node takes [:1] from each input by design.
• keyframe_batch looks right but the chunks drift anyway. The batch is a preview of what you fed in, not a guarantee the video model honoured the anchors. If a chunk ignores its endpoint, that's a denoise or guidance problem downstream, not this node.

Given how thin this node is, it's also the one you could replace with four Save Image nodes and some squinting. The reason to keep it is the validation: a hard error at the junction beats a stitched video that's mysteriously half a resolution off in chunk three. Worth noting this pack is a one-person project with a small but steady community footprint - the music-video workflows get posted and questions get asked in her Discord rather than in big forum threads - so when a node like this errors, the error message is the documentation.