H3 Character Sheet Designer Multi Reference

Most "character reference" setups treat extra images as a vague pile of vibes: the model gets four pictures and is told, essentially, make it look like these. This node does something more specific. Each optional extra reference carries a role - face, clothing, hands, footwear - and the compiler writes the prompt so that photo is only allowed to influence the panels where that part is actually visible.

It's a genuinely different bet from the pack's current node.

Where it sits in the pack

Multi Reference is the previous 13-view node. Same view catalogue, same compiler, same GUI. What differs is the plumbing: two optional extras instead of three, four image slots going into H3 instead of five, seven outputs instead of eight, and a state format that is also called schema 3 but is not interchangeable with the current node's schema 3. The author keeps it for existing workflows and says so plainly.

So why reach for it? If your reference material is part-crops rather than more views of the whole character - a tight face shot, a flat-lay of the jacket, a clean picture of the shoes - the role field is the reason. In the pack's current Reference13 node those same photos are treated as generic same-character supplements, which is fine but blunter.

How it works

state_json is the single source of truth: views, size, part_prompts, reference_roles, hand_state, clothing_mode. You set it through the UI; the JSON is just what it serialises to.

reference_roles has two keys, reference_image_1 and reference_image_2, each accepting same_character, face, head, clothing, clothing_front, clothing_back, hands or footwear. Both default to same_character, which gives you the old dumb-but-safe behaviour until you change something.

The compiled prompt reads like a shot list: it defines <Subject 1> from your character image, then names every wired picture by number and role, and appends a scoped instruction - apply this dedicated reference only to the panels where that surface is visible. If both extras carry the same non-baseline role, it uses them together for different angles and lets the second win any design conflict. There's an explicit priority ladder in the output: hand-coverage override, then your named-part directives, then dedicated role references, then same-character supplements, then the baseline image.

hand_state takes reference, bare or gloved; clothing_mode takes worn or garment. Set garment, and the clothing panels ask for the garments alone with nobody inside them - the layout guide blanks those panels too.

Inputs and outputs

Required: state_json and character_image. Optional: reference_image_1, reference_image_2, use_layout_image (default off), and style (ten rendering choices; none is the default and the sane starting point).

Outputs are prompt, width, height, layout_image, character_image, reference_image_1, reference_image_2 - all single values. Wire the first three into Core's MiniMaxH3ReferenceToVideo after converting those widgets to inputs, then route the images to ref_images.ref_image_0 through ref_image_3 in order: character, layout, extra one, extra two. Picture numbers skip None, which matters here - leave the layout off and your extras are <Picture 2> and <Picture 3>, and the compiler numbers them that way for you.

Keep the layout_image wire connected even with use_layout_image off. The output is None and H3 quietly skips it.

Install

ComfyUI Manager → search "H3 Character Sheet Designer", or:

cd ComfyUI/custom_nodes
git clone https://github.com/ukr8b3g-cmyk/H3-Character-Sheet-Designer.git

Restart, then hard-reload the browser tab so the widget JS refreshes. No Python package to install - the project ships zero runtime dependencies.

You still need the usual H3 stack, which the node does not supply: a diffusion model, a Qwen3-VL-class text encoder, and a video VAE. The bundled Multi Reference workflow is a GUI JSON, not API format; drag it onto the canvas, then reselect every loader for your own filenames. Its saved diffusion-model name contains a Windows-style subfolder and won't resolve on Linux.

Real problems, honestly

The one that wastes an evening: pasting a state JSON from the current Reference13 node into this one. Both are version 3, the keys differ, and the compiler is strict about exact keys - you get a validation error rather than a quiet guess. Same in reverse. Don't port states between variants; open each variant's own workflow.

Second: batched images are refused. The validator wants one [1,H,W,3] float tensor per slot and tells you to use separate Load Image nodes instead of an ImageBatch. That's a feature dressed as an error message.

Third: Manual width/height values must sit on the 32-pixel grid - the compiler rejects off-grid numbers instead of rounding.

And the expectation to manage: roles steer wording, not geometry. Nothing here inspects your pixels or verifies that the face crop got respected - H3 infers the rest, and the author makes no success-rate claim. If a role reference is being ignored, tighten the matching body-part prompt before you assume the wiring is wrong.