🌀 BV Regional LoRA

Regular ComfyUI gives you one LoRA stack per model at a time. BV Regional LoRA is where that stops: it attaches an immutable LoRA capability to your Regional V3 context, so different named regions can pull different LoRAs - a character LoRA on the subject, a style LoRA on the background, nothing bleeding across the boundary. It's the LoRA half of the same regional story the pack's LUT nodes tell on the color side.

You use it when your regional prompt already names distinct regions and you want each one's identity to come from a LoRA rather than just words. It chains: it takes a BV_REGIONAL in, transforms it, and hands a new BV_REGIONAL out, so you can stack several of these (or other regional transforms) along a chain before the context gets compiled.

How it works

The node is structured as a capability transform with three controls: operation, config_json, and the resource providers.

• operation - replace (default), merge, subtract, or clear. These operate on the LoRA capability already attached to the regional context: replace swaps it, merge combines, subtract removes, clear wipes it entirely. "Immutable" is the design word - each transform produces a new context, it never edits the one it received.
• config_json - the capability payload, defaulting to {"version":3,"entries":[],"steps":[]}. In v3, entries carry per-entry id, a source (native - a directly-specified LoRA - or external, referencing a runtime resource provider by collector_id and resource_id), and targets that say which region(s) each entry applies to and at what scope. This is where "which LoRA goes where" is declared.
• resource_provider_1…resource_provider_20 - where named LoRA stacks from BV LoRA Registry plug in. If your config's sources are external, the materialization step resolves them against these providers at execution time.

The node also validates that every target region actually exists in the regional document - a reference to a deleted region errors out instead of silently doing nothing, which keeps silent no-op LoRAs from poisoning your renders.

Output: regional, the transformed context, ready to feed the next transform or the regional compiler/attention backend.

The inputs and outputs that matter

• regional - in and out; chain it.
• operation - reach for merge when adding a LoRA to an existing capability, replace to start fresh.
• config_json - the v3 entries; the pack's UI builder writes this, and it's worth letting it.
• resource_provider_* - the named stacks; you'll usually wire just the one from a single BV LoRA Registry.

How to install

Part of BV Node Pack:

cd ComfyUI/custom_nodes
git clone https://github.com/BlackVortexAI/bv_nodepack.git

Restart ComfyUI and hard-refresh. Or ComfyUI Manager → "BV Node Pack". No models to download - the LoRAs come from your existing models/loras folder via the registry.

Common issues

• "LoRA target references a missing region" - the config points at a region that isn't in the regional document (or the document id changed). Rebuild the config from the editor after editing regions.
• A LoRA does nothing - either its stack is disabled in the registry, the entry is scoped to a region that's empty/absent, or you set strength so low it's invisible. Check enabled flags in the registry config and the entry's target.
• "cannot clear a missing LoRA capability" - you used subtract or clear on a context that has no LoRA capability attached. Use replace to set one first.

Regional LoRA is genuinely powerful and genuinely fiddly: the payoff is mixed-style images that stay coherent, the cost is you now manage per-region stacks. For a single-LoRA workflow it's pointless - but that's not what it's for.