Zura V3 · Assemble shots

Zura V3 · Assemble shots is the least glamorous node in the pack and the one you'll probably never wire by hand - which is exactly why it's worth understanding. When a multicam render comes out with shots in the wrong order, or one shot flashing to the source camera for twelve frames, this is the node that did it.

Its job: take the shot plan, take a pile of rendered takes, and return one frame sequence of exactly the source length.

Inputs

Two are required. source_frames is the decoded 24 fps source clip. plan_json is the plan string the angle gallery produced - it carries frame_count and frames_per_shot, which are the ruler this node measures everything on.

Then it accepts angle_1…angle_9 and shot_1…shot_60 as optional images, plus scene_frames. The distinction matters: an angle_N input is a full-clip take that gets sliced, while a shot_N input is already trimmed to that shot and is used whole. That's how the pack avoids re-generating an angle that appears in four separate shots - the H3 node renders it once and lets this node cut it up.

scene_frames gives the assembler a new-scene guide to align to; if it's present it's also the base frame sequence that original-camera shots are cut from, instead of the source.

The single output is IMAGE. Wire it to your video save node.

How it works

For each shot in the plan it picks its source: an explicit shot_N take if you connected one, else the source (or scene guide) for angle 0, else the matching angle_N take. It then concatenates and asserts the result is exactly frame_count frames long.

The bit that surprises people is the resolution handling. Before assembly it looks at one example frame - scene_frames if present, otherwise the first connected angle or shot - and if the base sequence is a different shape it centre-crops the base to match that aspect ratio, then bilinear-resizes. This isn't the node making aesthetic decisions; it's matching the generated canvas so the concat doesn't blow up. Final output size is still your business downstream in a plain ImageScale.

Angle takes also have to be long enough. If you connected an angle_N take shorter than the source, you get Angle N did not render enough frames for shot N (start:stop) - which in practice means the render failed partway, not that you mis-wired something.

Do you need to install it separately?

No. It ships in the same pack:

cd ComfyUI/custom_nodes
git clone https://github.com/ZURAVFX/ComfyUI_zura_nodes

Restart, done. Optional extras live in requirements.txt (requests, yt-dlp, ultralytics, face-alignment) and only matter for the parts of the pack that detect or download things.

When you'd actually reach for it

Zura V3 · H3 multicam render builds this node internally as part of its expanded graph, so in the normal flow you never touch it. You'd wire it yourself in two situations: you're hand-rolling the render branch and want the same assembly logic, or you're debugging. If you are debugging, feed it the source and the plan and exactly the takes you expect, and check that original-camera shots reproduce the source frames bit-for-bit. They should - the tests in the repo do precisely that assertion, checking that a source frame inside a 0 shot survives assembly unchanged.

One trap: assembly is strict on length but not on content, so a take rendered from the wrong angle will assemble cleanly and just look wrong. It will not save you from a bad plan.