Nodes/ComfyUI-WanAnimatePlus/WanAnimatePlus LoraSelect
ComfyUI Node

WanAnimatePlus LoraSelect

How to stack style and identity LoRAs on Wan

By wuwukaka·Created 4 months ago·Updated about a month ago· 409
WanAnimatePlus LoraSelect
  • prev_lora
  • blocks
  • lora
lora
strength1.0000
low_mem_loadfalse
merge_lorastrue

Wan's superpower is its LoRA ecosystem - character, style, speed and control LoRAs - and this node is how you get them onto a WanAnimatePlus model. LoraSelect picks one .safetensors LoRA from ComfyUI/models/loras, applies a strength, and hands it downstream as a WANVIDLORA object that you feed into the lora input on WanAnimatePlus ModelLoader.

The two knobs. lora is a dropdown populated from your loras folder (the tooltip is specific: files with a .safetensors extension). strength defaults to 1.0 and the tooltip gives you the escape hatch - "set to 0.0 to unmerge the LORA." The range goes to ±1000 but you will never need that; the Wan ecosystem's practical band is roughly 0.3–1.0 for identity and style LoRAs, with speed LoRAs (LightX2V and friends) usually at lower strengths because they trade quality for speed.

Chaining for multiples. Stacking several LoRAs is the norm - a character LoRA plus a style LoRA plus a speed LoRA. That's what prev_lora is for: feed the previous LoraSelect's output into the next node's prev_lora, and you build a chain. LoraSelectMulti exists for the same job with five built-in slots if you prefer one node over a row of them.

The two loading behaviors you should know. merge_loras (default on) merges LoRAs into the model weights at load time. Off means they load on the fly during sampling instead. The tooltip carries a warning that matters: merging is "always disabled for GGUF and scaled fp8 models" - so if you're running quantized weights, this setting silently stops applying, and LoRAs load the other way. low_mem_load trades load speed for VRAM (slower loading, less memory), and it affects all LoRAs, not just this node's - so toggle it once, not per-node. The blocks input takes a SELECTEDBLOCKS object if you want to restrict which blocks a LoRA applies to, which is how people target a LoRA at specific transformer layers.

Where people get burned. Dropping a Wan 2.1 LoRA into a 2.2 model and getting mush - most 2.1 LoRAs are forward-compatible per the community, but not all are, and quantized models handle them differently. Second: stacking too many LoRAs at full strength until the character stops looking like anything. The recipe that survives contact with the community is one identity LoRA plus one style LoRA, both below 1.0, and a speed LoRA only on the low-noise pass if you're on 2.2.

Install via ComfyUI Manager (search "WanAnimatePlus") or git clone https://github.com/wuwukaka/ComfyUI-WanAnimatePlus into custom_nodes, restart, and drop your LoRAs into ComfyUI/models/loras. Keep the chain WanAnimatePlus end to end - the WANVIDLORA type is the fork's own, and mixing wrappers is the classic way to watch your LoRAs do nothing.

CategoryWanAnimatePlus

Inputs (6)

NameTypeDefaultDescription
loraCOMBOLORA models are expected to be in ComfyUI/models/loras with .safetensors extension
strengthFLOAT1.0000-1000–1000LORA strength, set to 0.0 to unmerge the LORA
prev_loraoptWANVIDLORAFor loading multiple LoRAs
blocksoptSELECTEDBLOCKS
low_mem_loadoptBOOLEANfalseLoad the LORA model with less VRAM usage, slower loading. This affects ALL LoRAs, not just the current one. No effect if merge_loras is False
merge_lorasoptBOOLEANtrueMerge 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)

NameTypeDescription
loraWANVIDLORA