Vix Dynamic Lora Definition

VixDynamicLoraDefinition is the node in the ComfyUI-Visionatrix pack that says "here is where a LoRA goes - and let the Visionatrix UI choose which one." Its official description is clear: it allows dynamic selection of any supported LoRAs from CivitAI in the Visionatrix UI. Wire your MODEL and CLIP in, describe what kind of LoRA belongs at this spot, and a Visionatrix user gets a LoRA picker instead of you hardcoding one.

The important thing to understand - and the thing that trips people up - is that this node does not load a LoRA itself. It passes the MODEL and CLIP straight through untouched. Its job is to declare a slot in the workflow and provide the metadata Visionatrix needs to fill that slot at runtime from the user's CivitAI library.

Inputs that matter

• model (MODEL) - the diffusion model the LoRA will be applied to. Wire this from your checkpoint/UNET loader. It comes out the other side, unmodified.
• clip (CLIP) - the CLIP model alongside it, same pass-through.
• base_model_type (STRING) - "The base type of model in CivitAI format," per the author's tooltip. This is what filters which CivitAI LoRAs are compatible: name the base like "SDXL 1.0" or "FLUX.1" (CivitAI's base-model taxonomy), and Visionatrix only offers LoRAs that match. Get this wrong and users can pick a LoRA that doesn't apply to your model.
• description (STRING) - "Brief explanation of LoRA functionality at the added place." This is user-facing: tell the person picking a LoRA what it's for ("character LoRA", "style", "detail enhancer"). A real description makes the flow usable; leaving it blank makes the picker guesswork.

Outputs

MODEL and CLIP, passed through from the inputs - "The modified diffusion model" / "The modified CLIP model" per the output tooltips, though nothing is actually modified in this node. In a Visionatrix run, the platform inserts the chosen LoRA's loading between this node's input and output; in plain ComfyUI, model and clip just flow straight through and no LoRA is applied.

How it works

The mechanism is a declaration plus a pass-through. In plain ComfyUI, do_it returns (model, clip) unchanged, so the node is inert. In Visionatrix, the platform reads the node, sees the base_model_type and description, and replaces the pass-through with an actual dynamic LoRA load from the user's CivitAI downloads. That's why it works "in the flow" but looks like a no-op locally.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/Visionatrix/ComfyUI-Visionatrix

Restart ComfyUI, or install ComfyUI-Visionatrix via ComfyUI Manager. No model downloads; deps are torch, pillow, numpy.

Gotchas

The main misunderstanding is expecting this to load a LoRA when you test in plain ComfyUI - it won't, because the LoRA loading lives on the Visionatrix side. Test it there, or you'll think the node is broken. Second, base_model_type matters more than it looks: an SDXL-vs-Flux mismatch means users pick incompatible LoRAs. And the pass-through is truly pass-through - if you need a LoRA applied locally, use a real LoraLoader; this node is for flows you're publishing to Visionatrix, not for your own tinkering.