Zura V3 · Choose pass
One Dropdown That Keeps Your VRAM Alive
- ZURA_MULTICAM_STAGE
Zura V3 · Choose pass is a dropdown with one output. That's the whole node. It looks like filler until you understand what the rest of the pack does with it.
The V3 multicam flow has two passes. First you plan: generate nine candidate camera angles from your source frame and pick one per shot. Then you render: the model generates takes only for the shots that actually use a generated angle. Those two passes share a graph. Without a switch, running the render would also fire the nine angle generations, and running the plan would drag the H3 model into VRAM for nothing.
This is the switch.
Inputs and output
stage is an enum with two choices: 1 · Plan angles and 2 · Render multicam. The one output, ZURA_MULTICAM_STAGE, carries that string to every node that cares.
There's nothing else. No seed, no model, no image.
How the stage string actually controls execution
The type is a plain string on the wire. Consumers test it with startswith("1"), and three nodes in the pack change their behaviour:
- Pick camera angles - in pass 1 it requests all nine
candidate_Nimages through lazy inputs, so they generate. In pass 2 it wants none of them, and it checks that the saved manifest still exists and still matches your current look prompt. - Plan-only images - in pass 1 it passes your image through; in pass 2 it returns an
ExecutionBlocker, which prunes the entire branch behind it. - H3 multicam render - in pass 1 it returns blockers on both outputs and asks for no model, VAE, CLIP or geometry inputs at all. The expensive branch is never evaluated, not merely skipped at the end.
Wire the stage output into the stage input of every V3 node. That's it - one dropdown flips the whole graph.
Install
Same pack, no extras needed for this one:
cd ComfyUI/custom_nodes
git clone https://github.com/ZURAVFX/ComfyUI_zura_nodes
Restart ComfyUI, or find Zura Nodes in ComfyUI Manager. If you want ComfyUI Manager to keep it updated, install it that way instead of cloning.
Where it goes wrong
The trap is having more than one stage node in one workflow. Nothing stops you, and the moment your gallery reads pass 1 while the render node reads pass 2, you get errors that describe symptoms rather than the cause: Connect candidate 6 before running Plan angles when you thought you were rendering, or a perplexing silent render pass. Keep one switch, wire it everywhere, and keep it visible next to the gallery.
Second thing worth knowing: because this node is pure plumbing, it never appears in a support thread on its own. If you're debugging a V3 graph and the render node is claiming it has no models connected, check the stage value first.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| stage | COMBO | 2 options: 1 · Plan angles, 2 · Render multicam |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| ZURA_MULTICAM_STAGE | ZURA_MULTICAM_STAGE | — |