AD_scail2_generate

SCAIL-2 is the interesting one out of Z.ai: a human motion-transfer model built on a Wan 2.1 base that threw away the pose skeleton. You hand it a reference image, a driving video and colored masks, and it does the transfer - which is why it works on animals and multiple characters where the skeleton-based tools don't. It also shipped into ComfyUI core (comfy_extras/nodes_scail.py), not into someone's node pack, which is the reason AD_scail2_generate is thin rather than enormous: it's orchestration on top of core's WanSCAILToVideo.

What it adds on top of core

Length. One SCAIL-2 call gives you one clip, and long clips fall apart or don't fit. This node runs a stage loop: each execution generates one segment, and instead of dragging the whole previous clip into the next one, it carries only the tail frames - previous_frame_count, five by default, because that's what SCAIL-2 was trained with. Every segment is written out as its own MP4 under .apt_stage_bridge/<run_id>/segments/, and on the final stage the node concatenates them all into a _final.mp4. That's the whole pitch, and it's a good one: the memory cost stays flat as the clip gets longer.

The stage bookkeeping lives in the pack's other nodes. flow_stage_begin hands out a FLOW_STAGE_INFO telling each run which stage it is and how many there are; this node reads that, and optionally reports back with stage_info_data1.

The inputs you'll actually touch

The node refuses to start without a populated RUN_CONTEXT (model, clip, vae, width, height, steps, cfg, sampler, scheduler) - that's the pack's whole design, one wire instead of forty. Then:

• positive / negative - text. positive defaults to "reference motion ", which is a SCAIL-style hint, not a prompt you should keep.
• length - output frames per segment, step 4. Reads 81 out of the box.
• segment_count - leave it at 1 and it takes the stage total from flow_stage_begin; set it above 1 and it must match that total or the node throws.
• previous_frame_count - the carry-over. Five is the trained value; if you grow the clip with multi-segment runs, length must be at least this.
• replacement_mode - the black-vs-white mask background switch. False is animation mode, True is replacement mode.
• clip_vision_name, seed, fps, transfer_color, pose_strength - the usual. Color transfer (reinhard_lab by default, or mkl_lab/histogram) only applies when you've connected a reference image, and the node will tell you so if you enable it without one.

On the optional side: pose_video and pose_video_mask take either an IMAGE batch or a file-backed VIDEO - and the VIDEO path is the one you want, because the node decodes only the window each stage needs instead of a whole driving clip into VRAM at once. reference_image takes the identity view (followed by any extra angles), reference_image_mask takes its colored masks, and stage_info_data1 wires to the stage scheduler.

Four outputs: context (into the next stage), bridge_image (the tail frames, as an image), segment_video (this stage's segment), and merged_video - which only produces anything on the last stage. Earlier stages block it, deliberately.

Installing it

ComfyUI Manager → ComfyUI-Apt_Preset, or:

cd ComfyUI/custom_nodes
git clone https://github.com/cardenluo/ComfyUI-Apt_Preset
pip install -r ComfyUI-Apt_Preset/requirements.txt

Restart after. Two of the pack's dependencies matter here specifically: SCAIL-2 support comes from ComfyUI core, so you need a build recent enough to have comfy_extras.nodes_scail and the comfy_api.latest module this file imports - otherwise the node just doesn't appear. And if you're using a reference image, you need clip_vision_h.safetensors in your models folder, which is a plain git clone away from most people's already-downloaded Wan stash.

Where people get burned

Replacement mode. The most common confusion around SCAIL-2 in the wild is exactly the toggle this node exposes: flip it the wrong way and the character gets replaced instead of animated, and the background either survives or turns to mush depending on which mode you meant. If your background looks degraded after a replacement-mode run, you're in the wrong mode, not in a broken workflow.

Indexing math. Because segment_count and flow_stage_begin.total have to agree, changing the total on one node and forgetting the other produces a validation error rather than a nice long video. Same for length vs previous_frame_count on multi-segment runs.

Source frames run out. If a stage has no source frames left - because your driving video is shorter than length × total - the node says so and tells you to reduce the total. That's a feature; the alternative is a frozen final segment.

Payload types. Pose inputs must be IMAGE tensors or file-backed VIDEO objects; an in-memory video object from some other node raises a TypeError instead of quietly working. And merged_video is only live on the last stage, so if you queue stage 1 of 6 and nothing comes out of it, nothing is wrong.