MotionDiff Simple Sampler

If the MotionDiff pack has a KSampler, this is it. MotionDiff Simple Sampler is the node that runs the actual diffusion loop over your motion - it takes the model, the text conditioning, and the blank motion, and returns the finished MOTION_DATA. Everything else in the text-to-motion pipeline (loader, text encode, empty motion) is setup; this is the moment the movement gets denoised into existence. Wire a visualizer or the SMPL path onto its output and you're done.

It's the "simple" sampler in a very literal sense: no step-count dial, no CFG scale, no scheduler curve. It runs the model's built-in sampling procedure with the sampler name you pick and hands you the result. That's a feature for beginners - one knob, one seed - but it does mean the model's own defaults are in charge of quality.

How it works

The motion diffusion model was trained to denoise joint-position sequences. The sampler starts from your motion_data (the blank/noise sequence from Empty Motion Data), conditions on the text embedding from MotionCLIP Text Encode, and iteratively refines. Two samplers are offered:

• ddpm - the full Markov-chain denoising schedule. The "original" way, more faithful per step, slower.
• ddim (default) - the accelerated, deterministic-style sampler. Faster and usually visually indistinguishable for this kind of content; it's the right default.

The inputs that matter

• md_model - from MotionDiff Loader.
• md_clip - the matching CLIP, same loader.
• md_cond - the conditioning from MotionCLIP Text Encode.
• motion_data - the empty motion; its frame count sets the output length.
• sampler_name - ddim or ddpm.
• seed - variation control. Change it to get a different take on the same prompt.

Output: MOTION_DATA → Smplify Motion Data or Motion Data Visualizer.

Installation

Part of Fannovel16/ComfyUI-MotionDiff. Install via ComfyUI Manager (search "ComfyUI MotionDiff") or clone into ComfyUI/custom_nodes, install requirements, restart. First run triggers the model download (checkpoint plus dataset files from HuggingFace), so expect a long first queue.

Gotchas

The lack of a step count trips people up - you can't crank "steps" to fix a rough result the way you would in image sampling. If a motion comes out janky, your levers are the seed, the prompt, and (occasionally) switching sampler to ddpm. Also keep the 20 fps dataset reality in mind: 196 frames is ~9.8 seconds, and longer clips come from stitching batches, not from one giant sample. For that music-video workflow people feed the output depth maps into an image ControlNet - the depth-map darkness and banding you see in renders is a downstream node's issue, not this one's.