WanAnimatePlus LoraSelectMulti
Five LoRA slots in one node, and why you still shouldn't max them all out
- prev_lora
- blocks
- lora
LoraSelect chains LoRAs by daisy-chaining prev_lora between nodes. That works, but a three-LoRA stack means three nodes and a line of wires. LoraSelectMulti is the same idea compressed into one node: five parallel slots - lora_0 through lora_4, each with its own strength_0 through strength_4 - and one lora output in WANVIDLORA form for the WanAnimatePlus ModelLoader.
The pattern it serves is the standard Wan stack: an identity/character LoRA, a style LoRA, and a speed LoRA, all in one tidy panel. Each slot defaults to none, so unused ones are invisible until you pick a file, and the whole node's output feeds the model loader the same way a single LoraSelect would. The strengths here are per-slot, which is the real advantage over the chained version - you can see every weight at a glance instead of hunting across three nodes.
The settings that apply to everything. low_mem_load and merge_loras are the same flags as in LoraSelect, with the same quirks: they're global, not per-LoRA. merge_loras (default on) merges into the model weights at load; it's "always disabled for GGUF and scaled fp8 models," so on quantized weights your LoRAs load on the fly no matter what the toggle says. low_mem_load slows loading to save VRAM and touches every LoRA in the pack. The blocks input takes a SELECTEDBLOCKS object to scope LoRAs to particular transformer blocks - niche, but there if you need it. The one thing this node does not have that LoraSelect does is a prev_lora input, because it is the multi - if five slots somehow aren't enough, chain a LoraSelectMulti into a LoraSelect via... well, no. Five is plenty; this is already overkill for most workflows.
The honest advice on stacking. The community's repeated lesson is that LoRA stacks degrade faster than they help. One identity LoRA plus one style LoRA, both under 1.0, beats four at full strength - past a certain point you're just fighting your own LoRAs for control of the output. Speed LoRAs deserve special care: they change CFG behavior (down toward 1.0) and eat quality, and on Wan 2.2 the best practice is applying them only to the low-noise pass. Set a plan, not a maxed-out slider panel.
Install via ComfyUI Manager (search "WanAnimatePlus") or git clone https://github.com/wuwukaka/ComfyUI-WanAnimatePlus into custom_nodes, restart, and make sure your LoRAs are .safetensors files in ComfyUI/models/loras - the node only sees those. Keep the chain on WanAnimatePlus nodes so the WANVIDLORA type matches what your ModelLoader expects.
Inputs (14)
| Name | Type | Default | Description |
|---|---|---|---|
| lora_0 | COMBO | none | 1 options: none |
| strength_0 | FLOAT | 1.0000-10–10 | LORA strength, set to 0.0 to unmerge the LORA |
| lora_1 | COMBO | none | 1 options: none |
| strength_1 | FLOAT | 1.0000-10–10 | LORA strength, set to 0.0 to unmerge the LORA |
| lora_2 | COMBO | none | 1 options: none |
| strength_2 | FLOAT | 1.0000-10–10 | LORA strength, set to 0.0 to unmerge the LORA |
| lora_3 | COMBO | none | 1 options: none |
| strength_3 | FLOAT | 1.0000-10–10 | LORA strength, set to 0.0 to unmerge the LORA |
| lora_4 | COMBO | none | 1 options: none |
| strength_4 | FLOAT | 1.0000-10–10 | LORA strength, set to 0.0 to unmerge the LORA |
| prev_loraopt | WANVIDLORA | For loading multiple LoRAs | |
| blocksopt | SELECTEDBLOCKS | — | |
| low_mem_loadopt | BOOLEAN | false | Load the LORA model with less VRAM usage, slower loading. No effect if merge_loras is False |
| merge_lorasopt | BOOLEAN | true | Merge LoRAs into the model, otherwise they are loaded on the fly. Always disabled for GGUF and scaled fp8 models. This affects ALL LoRAs, not just the current one |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| lora | WANVIDLORA | — |