Zura · Load Wan Motion and Character

One widget, four outputs, and a whole preparation stage's worth of tensor work avoided. Give it the right cache key and it hands the Wan sampler everything it needs - frames, mask, pose reel, face reel, scope, and the character reference - without running pose detection again.

It's the read half of the pack's preparation cache. Something upstream prepared the shot (detection, masking, the pose carry chain) and wrote it to disk; this node loads it. The write halves are Zura · Cache Wan Motion and Character for whole-shot preparation and the section saver/merge pair for the bounded path. If you're on a long take with 81-frame windows and a file-backed cache, use Zura · Load File-Backed Wan Motion or Zura · Load Wan Motion in Sections instead - this one pulls the whole thing into RAM.

Inputs and outputs

cache_key is a string, default empty, and it is not free-form. It has to be a 64-character lowercase hex digest. Anything else raises "Invalid Wan preparation cache key." The key is the identity of a preparation run - its payload includes the source interval, review pin, reference hash, recipe and scope - so it isn't something you invent, it's something a preparation node handed you.

Outputs:

• footage - the ZURA_FOOTAGE payload for the sampler. This is the one that matters.
• character_view - the reference image, forwarded.
• width, height - ints, taken from the stored frames.

The cache file lives at ComfyUI/output/genj/wan_conditioning/<cache_key>.pt, written with torch.save and loaded with weights_only=True - so no arbitrary pickle execution, which is the correct instinct even for a file your own pack wrote.

The caching detail worth knowing

This node implements IS_CHANGED by returning the cache file's mtime and size as a tuple. That's a smart choice for a loader: the node re-runs when the file on disk actually changes, and is skipped when it doesn't. Compare that to the windowed loader, which declares itself always-invalid and re-executes every queue.

Practical consequence: if you overwrite a preparation cache in place, this node notices. If you overwrite it with a byte-identical-size file and the filesystem doesn't move the mtime - rare, but possible on some mounts - it won't. When in doubt, use a new key. The pack's own tooling treats keys as one-shot identities and refuses to overwrite an existing part, which is the same instinct.

Every load also runs the payload validation: version tag (a stale format gets "Prepare this Wan shot again"), RGB frames present, mask matching the frame count, pose/face/reference tensors present and correctly shaped, values finite, scope one of the two supported values. It also verifies that the contained frames actually have some non-zero mask coverage.

Install

Ships with the pack:

cd ComfyUI/custom_nodes && git clone https://github.com/ZURAVFX/ComfyUI_zura_nodes
pip install -r ComfyUI_zura_nodes/requirements.txt

Or Zura Nodes in ComfyUI Manager (publisher ZURAVFX), then restart. No models are downloaded here and nothing heavy is imported - but the cache directory has to be the same one ComfyUI writes to, so if you've pointed --output-directory somewhere unusual, this node follows it and a cache written under a different output path will simply not be found.

Common issues

"Invalid Wan preparation cache key." The key isn't 64 hex characters. A common version of this: you copied the key from the section saver's output, which is a receipt path, not the key. Or you pasted a Studio project id, which is 32 characters and a different thing entirely.

"Prepare this Wan shot again." The file exists but its format version doesn't match what this build expects. Updating the pack moved the cache format. Re-run preparation - there's no migration, because a stale cache that half-matches is worse than a re-run.

File not found, or the loader returns yesterday's shot. Check ComfyUI/output/genj/wan_conditioning/ for the exact <key>.pt. The most common cause is a cache generated in a different ComfyUI install or a different output directory.

Everything downstream is slow anyway. This node loads a whole clip into CPU memory as float32. On a 30-second 1080p take that's substantial - gigabytes of RAM before the sampler starts. That's exactly the case the sectioned, file-backed loaders exist for; they read windows instead of the whole thing.