HY OmniWeaving Conditioning

In a stock HunyuanVideo 1.5 workflow, conditioning and latent creation are boring, well-trodden steps: an EmptyLatentVideo sized to your resolution, a couple of CLIP text encodes, done. OmniWeaving breaks that assumption because it's a task model - text-to-video, image-to-video, first-and-last-frame interpolation, reference-to-video, video editing, even image-plus-video editing (tiv2v) - and each task injects your reference pixels into the latent in a different way. HY OmniWeaving Conditioning is the node that does that task-aware injection and hands you ready-to-sample conditioning plus the empty latent.

Think of it as the conductor for everything visual in the workflow. It takes the text conditioning you produced with HY OmniWeaving Text Encode, prep's your reference images with the same Lanczos resize + center-crop the official repo uses, VAE-encodes them, and writes them into the latent as anchored frames - the first frame for i2v, the first and last for interpolation, the whole clip for editing. It then stamps concat_latent_image, concat_mask, and guiding_frame_index into both the positive and negative conditioning, plus forwards the Redux clip_vision_output into the conditioning for non-text tasks so the model can see what the reference looked like.

The inputs that matter

• task - the combo that changes everything. t2v, i2v, interpolation, reference2v, editing, tiv2v. Use the same task here as on HY OmniWeaving Text Encode - the text node sets the system prompt, this node sets how latents get injected. Mismatch is the single most common cause of nonsense output.
• positive / negative - wire them from Text Encode. This node augments them, not replace.
• vae - from HY OmniWeaving VAE Loader.
• width / height / length / batch_size - your canvas. Defaults are 848x480, 81 frames, batch 1, and they follow the same 16x/4x latent math as Hunyuan 1.5 (length 81 → 21 latent frames). Length steps by 4.
• reference_images - for i2v, interpolation, reference2v, tiv2v. condition_video - for editing and tiv2v (a video tensor; in the community port you feed frames into it).
• clip_vision_output - optional, from HY OmniWeaving Redux Vision Encode. Ignored for t2v (keeps text-only generation isolated), forwarded otherwise.

Three outputs: positive and negative conditioning for the KSampler, and the latent - which, unlike stock, is pre-populated with your anchored reference frames, so don't add an EmptyLatentVideo on top of it.

How it fails

The node raises a clear ValueError if a task demands inputs you didn't give it - i2v needs at least one reference image, interpolation needs two, editing needs a condition video. That's friendlier than most ComfyUI errors, so read it before assuming the pack is broken.

Installing it

It's in the hy_omniweaving_comfyui_unofficial pack. ComfyUI Manager (search "hy_omniweaving") or:

cd ComfyUI/custom_nodes
git clone https://github.com/Shiba-2-shiba/hy_omniweaving_comfyui_unofficial

Restart. No pip deps, but recent ComfyUI required (the pack uses the comfy_entrypoint API). Model files and their exact download links are in the README - diffusion model, Qwen + ByT5 encoders, SigLIP/Redux vision pair, and the fp32 VAE.

The honest part

Community testing found OmniWeaving needs CFG and a serious step count - 30–50 - to look good, and it's slow even on an RTX 6000. The payoff is that prompt-following and reference fidelity are genuinely good, especially paired with an LTX second-stage upscaler for resolution. Start with the pack's own workflow_i2v.json / workflow_t2v.json rather than hand-rolling; the task wiring is fiddly, and those files encode exactly the validated path.