Motionctrl Cond

This is where MotionCtrl's whole premise lives. The paper's selling point was that it controls two different kinds of motion independently: camera motion (where the camera moves, expressed as 3D camera poses) and object motion (where the subject moves, expressed as a 2D path across the frame). Motionctrl Cond is the node that takes your prompt plus those two motion strings and turns them into the conditioning tensors the sampler needs. It's the middle of the pipeline - everything upstream of it feeds it, and everything downstream consumes its outputs.

Think of it as the video-era cousin of what ControlNet did for images: instead of conditioning on edges or depth, you condition on motion. The two preset nodes and the pack's two web tools (draw.html for trajectories, index.html for camera moves) all exist just to produce the strings this node eats.

How it works

You feed it a camera string and a trajectory string - both JSON. The camera string is a list of per-frame 3×4 rotation-translation matrices (12 numbers per frame), padded or truncated to match the model's frame count. The trajectory string is a list of [x, y] points, which get scaled to a 0–1024 canvas and converted into optical-flow features. Your prompt gets encoded into CLIP embeddings, and - depending on infer_mode - the node builds the right combination of camera pose embeddings and trajectory features.

The inputs that actually matter

• prompt - your text, plain and simple. Defaults to "a rose swaying in the wind".
• camera - the JSON camera pose string. You'll rarely type this by hand; Load Motion Camera Preset outputs the correct format.
• traj - the JSON trajectory string, same story; Load Motion Traj Preset or the drawing tool produce it.
• infer_mode - three choices: control camera poses, control object trajectory, or control both camera and object motion. Pick "both" when you want the full effect; the single-mode options are for isolating what's causing a janky result.
• context_overlap - 0 to 32, default 0. More on this in the sampler article; briefly, it's the sliding-window knob for chaining clips longer than the model's native frame count.

The outputs, and what they wire into

Seven outputs, and six of them are pass-through ingredients for Motionctrl Sample Simple:

• positive and negative (CONDITIONING) - the encoded prompt and a hardcoded negative prompt. You don't get to edit the negative; the pack bakes in a long "blur, bad anatomy, mutated hands…" string and appends "Ultra-detail, masterpiece" quality tags to your prompt. Worth knowing before you fight it.
• traj_list, rt_list, traj, rt (TRAJ_LIST, RT_LIST, TRAJ_FEATURES, RT) - the trajectory points, the camera poses, and their extracted features, in the order the sampler wants them.
• noise_shape (NOISE_SHAPE) - the latent shape the sampler generates into.
• context_overlap (INT) - echoes your input back out to keep both ends of the chain in sync.

In the base workflow every one of those plugs straight into Motionctrl Sample Simple.

Common issues

Malformed JSON is the classic. The camera field must be a list of lists of twelve numbers ([[1,0,0,0, 0,1,0,0, 0,0,1,0.2]]), and the traj field a list of two-number points. If you paste from a preset node you're already in the right format; if you hand-edit, one stray character and you'll get a parse error rather than a video.

One trap worth knowing: if context_overlap is above 0, this node writes camera.json and traj.json state files into the pack's folder to remember the previous chunk. If results start looking wrong after you've been experimenting, those stale files are a prime suspect - delete them and re-run.