SMP · Clothing Builder (legacy)

The SMP (StructPromptMaker) pipeline builds structured prompts as a stack of typed dictionaries, and this node is the one that says "this outfit belongs to this person." FVM_SMP_ClothingBuilder takes an OUTFIT_DICT (from the SMP outfit generator or combiner) and attaches it to a specific subject inside your PROMPT_DICT - specifically, at prompt_dict.outfits[subject_id]. The downstream StructuredPromptAssembler reads that exact location when it splits the outfit into a regional prompt.

It's one of the three SMP "builders" (Clothing, Environment, Subject), and its job is identity assignment: in a multi-character scene, each character gets their own outfit attached under their own subject_id, so the regional assembler can route "this garment set" to "this part of the image." That's the classic multi-character-consistency problem again, solved the SMP way - by keeping each character's data in its own named slot.

Inputs and outputs

Required: outfit_dict (the OUTFIT_DICT to attach) and subject_id (default subject_1) - the key under which the outfit lands in outfits[...]. Optional: prompt_dict_in, the PROMPT_DICT you're building up. If you don't connect it, the node starts a fresh document. Output: the updated prompt_dict, which you'd pass along to more builders or to the aggregator.

The simple usage is one character: connect your outfit dict, leave subject_id as subject_1, and the node produces a prompt dict with that outfit in place. The multi-character version is where it shines: build character A's outfit and attach it as subject_1, then character B's as subject_2 - either by chaining builders (each taking the previous prompt_dict via prompt_dict_in) or by building them separately and merging with the Aggregator.

Installing

cd ComfyUI/custom_nodes
git clone https://github.com/ping1979ping/comfyui-FVMtools

No extra dependencies. Restart ComfyUI; it's under FVM Tools/SMP/Builders.

Legacy context, honestly

This is part of the pack's superseded SMP suite - the JB pipeline replaced most of it, and if you're starting fresh, JB · OutfitBlock + JB · Stitcher does the "outfit for a named character" job with fewer moving parts and string types that feed ordinary encoders. The SMP path demands you assemble the whole dict stack: generators emit typed dicts, combiners resolve colors, builders attach subjects, the aggregator merges, and the StructuredPromptAssembler finally renders. It works, it's stable, and existing SMP workflows still run - but only reach for it when you're already inside that world (or you specifically need the regional-assembler integration), not as a first choice for new work.