WAN Curvature Guide (LRW)

Before you generate a WAN2.2 First-Last Frame clip, wouldn't it be nice to know how hard the transition is going to be? That's the entire job of WAN Curvature Guide: it looks at your first and last latents, computes how "far apart" and how "curved" the gap is, and tells you how many geodesic keyframes to use. No pixels are generated, no images come out. It's the pack's planning node.

What it computes

It's deliberately cheap. It takes latent_start and latent_end (VAEEncoded first and last images), flattens them, and computes two statistics: a normalized latent distance (‖z1−z0‖ / ‖z0‖) and the angle between them via cosine similarity. Then it maps the angle to a recommendation:

• angle > 60° → 5 keyframes (clamped to 3 for 16GB workflows)
• angle > 30° → 3 keyframes
• otherwise → 2 keyframes

The metric input is required for API symmetry with the rest of the pack, but this node never builds a dense metric or touches a Jacobian - the README's whole point is that it's O(D), not O(D²). It's a distance/curvature heuristic dressed up in metric clothing, and that's fine, because it's a heuristic you can actually afford to run on a big WAN latent.

The outputs and how to use them

Three outputs, all useful:

• curvature_info - a STRING with the full diagnostic dump: angle, normalized distance, recommended count, and a human hint.
• mean_curvature - the FLOAT distance stat. Treat it as a relative signal, not an absolute truth.
• recommended_keyframes - an INT you can literally wire into the n_keyframes input of LRW_WanGeodesicKeyframes. The pack designed this handoff on purpose.

So the practical chain is: first+last latents → LRW_WanTemporalMetric → this node → its recommended_keyframes straight into LRW_WanGeodesicKeyframes. One read of the info string and you know whether your pose change is a gentle drift (2 keyframes, breeze) or a hard cut (3, be careful). The one thing to note: the recommendation is clamped to 3 regardless, because that's what the author found practical on 16GB - on a bigger card with GGUF quantized models you can push higher.

Context and expectations

This node exists to solve the WAN FLF "delayed motion" problem the author documented in his r/comfyui launch thread: FLF clips tend to hold the first frame, then transition late and abruptly on big pose/framing changes. The LRW branch's whole job is to nudge intermediate motion. This node is the sizing tool for that branch - it tells you how aggressive to be. It won't fix your video by itself; it just informs the keyframe count. Set expectations accordingly and it's genuinely handy.

Install

Search comfyui-lrw-nodes in ComfyUI Manager, or git clone https://github.com/lajjadred/comfyui-lrw-nodes into ComfyUI/custom_nodes, pip install -r requirements.txt, restart. Real deps: latent-riemannian-world >= 0.3.0, torch >= 2.4, Python 3.12+. The demo workflow also wants ComfyUI-GGUF, WanFirstLastFrameToVideo, and VideoHelperSuite. Early pack builds had a registration bug that showed nodes as broken/UNKNOWN - git pull + full restart, single copy in custom_nodes. License is BSL-1.1.