H3 RefCap Bake Pack
Freeze your cast into one file and stop re-picking
- pack
- STRING
Why you'd bother
Once you've built a chain of H3 RefCap Select nodes that gets the elf, the dwarf and the cavern right, you will rebuild that exact chain every single render. Each rebuild is a fresh chance to pick view 11 instead of view 12, and if you save the workflow in a slightly different state you won't notice until the dwarf's nose looks odd in clip nineteen.
H3 RefCap Bake Pack writes the current selection out as one view set file in ComfyUI/models/refcaps/. Same cast, one dropdown entry, no chain. From then on the shot is H3 RefCap Replay View Set with select = all, or nearest if you want it picking angles per shot. The chain becomes an authoring tool you use once, not plumbing you keep in the graph.
It's also the only node in the pack that produces a file you'd hand to someone else. A baked cast is self-contained - pixels, latents, clips, audio - so it travels.
What it actually writes
The bake is a copy, not a re-encode. It walks the pack, lifts each selected view's stored pixels and latent straight out of the source RefCaps, and writes them into a fresh version-3 view-set file with new numbering, keeping each view's yaw and stamping a label like elf_ranger.safetensors view 12. Clips keep their frame count, latent and timestamps; soundtracks and standalone audio keep their audio latents.
Two consequences fall out of "copy, not re-encode", and they run in opposite directions.
Good news: it's fast and it's exact. Nothing goes through the VAE or the text encoder, so the baked file replays identically to the chain it came from - verified end to end through Replay View Set.
Bad news: the bake is a snapshot. Re-capture elf_ranger with better photos and the baked cast still holds the old pixels. You have to re-bake. The author says this in as many words, and it's the one maintenance chore this node creates.
Inputs and outputs
pack- the output of your last H3 RefCap Select. Required.name- the file stem inmodels/refcaps/, defaultcast. Same filename rules as everywhere else here: letters, digits,_,.,-. A space or a slash throws.description(optional, multiline) - stored in the file's metadata. Leave it empty and the node writes a summary of what went into it, which is genuinely more useful than a blank field.
The output is a STRING, and it's an output node, so you get a summary line on the node after queuing: view count, clip count, audio count, total reference tokens, file size. Read the token number - that's your per-render cost if you attach all of them.
The cap doesn't apply here, on purpose
This is the detail that makes bake more than a convenience. Replay Pack and Replay View Set stop at the native node's 9 images / 3 clips / 3 audio, because that's what MiniMax H3 Reference to Video takes. Bake doesn't enforce those caps. A baked file can hold more than nine views - a face set plus a body set, say - and Replay View Set then picks up to nine of them per shot.
That's the whole argument for the node in one paragraph: your library can be bigger than any single render. Capture thirty angles, bake them all into one cast file, and let select = nearest choose the four that match the angle your prompt is describing.
Install
cd ComfyUI/custom_nodes
git clone https://github.com/AEmotionStudio/ComfyUI-RefCap.git
Or through ComfyUI Manager (ComfyUI-RefCap). No pip dependencies. The H3 model stack is still required for anything that renders, and H3's weights are territory-restricted - US, EU, UK and South Korea are outside the licence's Applicable Territory. That's true of every node in this pack, but it's the sort of thing you want to read before you invest in a cast library.
Bake appears muted in the pack's own H3 RefCap 7 - Two characters template - unmute it there to see a working chain feeding it.
Where it goes wrong
"has no stored pixels" - one of the RefCaps in your chain was captured without its photos wired in. Those files carry latents only; a bake needs pixels, so it refuses. Re-capture with the images connected.
Stale cast. You improved a source RefCap and the shot got worse. The bake is holding the old copy. Re-bake to the same name - it overwrites - and the workflow picks it up after a browser refresh.
Baking a chain you didn't check. The label guide on Replay Pack is your proof-read before baking. If <Picture 4> names the wrong character there, it'll be wrong forever in the baked file, and debugging it later means opening the file's metadata rather than reading a node.
Is it worth the extra node?
If you render one character once, no - Replay is enough. If you have a cast you return to, yes, and the reason isn't convenience, it's that the pack format lets a file be wider than a render. Capture generously, bake once, and let the replay node do the angle-choosing. That's the workflow the whole pack is built around, and Bake is the step that turns it into a library.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| pack | REFCAP_PACK | — | |
| name | STRING | cast | — |
| descriptionopt | STRING | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| STRING | STRING | — |