Motionctrl Sample Simple

Motionctrl Sample Simple is where the pack actually does its work. It's the sampler half of the split pipeline: Load Motionctrl Checkpoint loads the model once, Motionctrl Cond encodes your conditions once, and this node runs the DDIM denoising pass that turns all of it into frames. It's called "Simple" because it's the composed version - everything is pre-wired as inputs, so the node itself has almost nothing to think about. It's also what the bundled base workflow uses, so it's the version you should start with.

Why the split at all? Because the alternative - the pack's other sampler, Motionctrl Sample - reloads the whole model on every run. Here you can burn one load, then iterate seeds and steps without paying that cost again. That's the difference between tuning a workflow and re-watching a loading bar.

How it works

The node builds the latent noise in the shape Motionctrl Cond handed it, then runs DDIM with classifier-free guidance at 7.5, injecting your trajectory features as features_adapter and your camera poses as pose_emb at every step. The denoised latents get decoded through the VAE and come out as an IMAGE tensor holding the whole clip. It sets the seed via pytorch-lightning's seed_everything, so that input behaves like you'd expect.

The inputs that matter

Most of the required inputs are plumbing - model, clip, vae, ddim_sampler, positive, negative, traj_list, rt_list, traj, rt, noise_shape, context_overlap - all of them come from the loader and Cond nodes, and you just wire them in order. The ones you actually touch:

• steps - default 50. More steps, cleaner results, slower. 50 is the pack's own sweet spot.
• seed - default 1234. Your reproducibility knob.
• context_overlap - default 0. Set it above 0 to chain runs into a longer clip: the sampler saves its last frames and the next run seeds from them. This is the pack's answer to the 16-frame wall, and it genuinely works, though it's fiddly.
• draw_traj_dot and draw_camera_dot - debug overlays. Turn them on to see the trajectory point (and a little camera-pose diagram) burned into the output so you can check your conditions actually matched.
• traj_tool - not a control at all, just a convenience link to the trajectory drawing web app. Ignore it.

The output

One IMAGE tensor with the whole clip in it. In the bundled workflow it goes straight to a PreviewImage. For an actual file, route it through something like VideoHelperSuite's VHS_VideoCombine - this node hands you frames, not an mp4.

Common issues

Two gotchas, both grounded in how the node actually runs. First, when context_overlap is on, it saves pred_x0.pt and x_inter.pt into the pack folder as state between runs. Those files persist. If you change your camera or trajectory and the output still looks like the previous clip's ending, delete those two files and re-run.

Second, the overlays. If you toggle draw_traj_dot and see a red dot wandering across your subject, that's the trajectory being drawn literally - it's a debugging aid, not a render effect, and people get briefly alarmed by it. Turn it off for clean output. And remember the honest baseline: this model outputs 256×256, ~16 frames, at 10 fps. Great for motion control, not for 4K hero shots.