WanVaceToVideoLatent

Every other node in this pack takes your control video and reference as images, VAE-encodes them, and builds the VACE conditioning. WanVaceToVideoLatent skips the images entirely: it works in latent space. You feed it latents - a control latent and/or a reference latent - and it assembles the same inactive/reactive VACE stack the pack usually derives from pixels. The author's own README is refreshingly blunt about it: "probably not a good idea to begin with but if you want to experiment..." So this is a lab node. Read on if you already know why you want it.

What it does

The core trick: instead of encoding a real control video, it builds a neutral control from a tensor of flat 0.5-gray frames, encodes that through the VAE once to get the "inactive" side, and clones it for the "reactive" side. That gives you the 32-channel [inactive, reactive] control latent VACE expects - an empty control track. Then:

• control_latent_input - if you pass a latent, it gets spliced into the reactive side, replacing the corresponding frame range. So you can hand the node already-encoded control frames without re-encoding from pixels.
• reference_latent - a latent to prepend as the reference frames (padded to 32 channels with zeros). The trim_latent output tells you how many reference frames got added, and the mask is built accordingly (zeros over the reference, ones over control) so the model treats the reference region correctly.

The strength float (default 1.0) applies to the whole control track, and the node writes vace_frames, vace_mask, and vace_strength into both positive and negative conditioning. Outputs: positive, negative, a blank latent (zeros, sized to the clip) for continuity, and trim_latent.

The inputs that matter

Required: positive, negative, vae, width/height/length/batch_size, strength. Optional: control_latent_input, reference_latent. That's the whole surface - no per-frame lists, no phantom, no model patching (a patched model isn't needed for the basics here, though it doesn't hurt if your graph already has one).

Why you'd bother

Two honest use cases. First, pipeline flexibility: if your control data is already living as latents (say, from an earlier encode you want to keep untouched), this lets you avoid a decode/re-encode round trip. Second, pure experimentation - feeding hand-built or tiled latents directly. If neither applies to you, treat this node as educational reading: it's a clean, commented example of exactly what the pack does internally when it encodes control video, and it's a handy reference for understanding the other nodes. That alone earns its place in the pack even if you never put it in a production graph.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/drozbay/ComfyUI-WanVaceAdvanced
# restart ComfyUI

or ComfyUI Manager → "ComfyUI-WanVaceAdvanced". Deps are numpy + scipy. If you try it and the results look wrong, that's the expected first attempt - the author said as much. Keep a pixel-path node like WanVacePhantomSimpleV2 around as your control, and treat this one as the thing you test hypotheses with, not the thing you ship a workflow with.