Zura · Continue Motion Preparation

Here's the failure this node exists to prevent. You split a long take into 81-frame sections. In one section the pose detector loses the subject's legs - it's a wide shot, the body is small, the detector's whole-body pass doesn't fire. WanAnimatePreprocess has a fallback for that, and it works fine within a section. But the fallback's state doesn't survive the section boundary, so section two starts with no body pose at all, and your actor suddenly has no lower half for 81 frames.

Zura · Continue Motion Preparation carries that fallback state forward from one window to the next.

Inputs

• pose_data - the POSEDATA from the native detection pass for this window.
• window - the ZURA_WAN_WINDOW descriptor from the section decoder. This is what tells it which section it's looking at and where it sits in the shot.
• clip_details - the reviewed-clip record. It's checked against the window: if the recorded total frame count doesn't match the window's total, you get "Wan pose carry window does not match the reviewed full clip."
• reference - the character reference image. Its hash goes into the identity pins, so the carry state is tied to the reference you actually used.
• cache_key - the preparation cache key, 64-char hex. Ties the carry chain to one preparation run.
• scope - person or head. The replacement area. A person-scope chain and a head-scope chain are different identities and don't mix.
• Optional speech_guide_key and speech_guide_sha - if you're on the audio-driven route, these pin the carry to the verified facial-performance guide.

Outputs

Two, and you need both:

• pose_data - the corrected pose payload. Wire this into the rest of the preparation branch in place of the raw detection output.
• carry_state - the state object the next window's node needs. Feed it forward and you've built a chain across the whole clip.

How the carry actually works

The node loads the previous window's carry state from disk, verifies it against the same identity pins - source hash, review hash, reference hash, footage metadata, the render cache pin - and then applies the fallback behaviour on top of this window's pose data. The result is a pose stream where a lost body detection inherits the previous window's body context instead of dropping to face-only. It writes a new state record with the outgoing carry hash, and that file is written atomically (temp file, then hard link, no partial writes) and refuses to overwrite an existing part: reuse a cache key and you get "This Wan preparation part already exists. Use a new preparation cache key."

The window length check is exact - pose_metas_original must cover precisely the bounded window's frame count, no more and no less. If inference ran on a different range than the one you decoded, you find out here rather than in the output.

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

Manager install: search Zura Nodes, publisher ZURAVFX, restart. What this node really needs is its neighbours: ComfyUI-WanAnimatePreprocess supplies the OnnxDetectionModelLoader, PoseAndFaceDetection and DrawViTPose nodes that produce the POSEDATA and the body fallback in the first place, and the detection model files (detection/vitpose-l-wholebody.onnx, detection/yolov10m.onnx) have to be where that pack looks for them.

Common issues

"Apply the verified Wan pose carry before saving a preparation part." You skipped this node on the way to the section saver. The saver requires a carry state from this node; it won't accept a raw pose payload.

Carry chain rejects the previous state. The identity pins changed between windows - different source file, different reference image, edited mask, different scope, different speech guide. The chain is deliberately brittle because a carry across changed identity is worse than no carry: you'd inherit a body pose from a shot that no longer exists. Re-run preparation from the first window with the new inputs and a new cache key.

A window where the subject genuinely leaves frame looks wrong. The carry is doing what it says: it holds the previous body state when detection fails. It cannot tell "detector dropped out" from "actor left the shot," and neither can anything else at this layer. If you have honest empty frames, this is a case for splitting the shot rather than carrying.

Everything re-runs every queue. The node reports itself as always-changed, so it can't be cached. That's intentional for something whose validity depends on files on disk, but it means a preview re-run does re-execute the whole per-window chain.