Smplify Motion Data

Every motion the pack generates - from MotionGPT, MotionDiffuse, MDM, ReMoDiffuse - comes out as raw joint positions: a dancing skeleton with no body around it. Smplify Motion Data is the bridge that fits a full SMPL mesh to those joints. It's the slow, sometimes fiddly step between "I have a motion" and "I have a renderable, exportable body," and it's the prerequisite for the good OpenPose output, so it's worth understanding before the pack surprises you.

The name comes from SMPLify, the classic optimization method: instead of predicting body parameters with a network, you fit them. You hold the joint trajectory fixed and adjust SMPL's pose and translation until the mesh's joints line up with the target positions.

How it works

Under the hood this runs joints2smpl from the mogen motion library. It's a gradient-descent optimization, and the two knobs it exposes are straight out of training land:

• num_smplify_iters (default 20, up to 1000) - the optimization iterations. Think "training steps." More iterations usually means a better fit, but linearly more time.
• smplify_step_size (default 0.1, from 0.0001 to 0.5) - the step size, i.e. the learning rate. The README is unusually candid here: it says a good loss lands around 1–15 for the camera-translation stage and 1e+6 to 2e+6 for the second stage, and suggests you can lower step size and raise iterations "similar to training ig."

You also pick the smpl_model (SMPL_NEUTRAL.pkl default, plus male/female/FLAME variants) - this determines the base body the optimizer fits, so the female model gives you a female-typed mesh.

The single SMPL output feeds the render nodes, the exporters, or Save SMPL so you only pay this cost once.

Installation

Part of Fannovel16/ComfyUI-MotionDiff. ComfyUI Manager → search "ComfyUI MotionDiff" → install, or git clone https://github.com/Fannovel16/ComfyUI-MotionDiff into ComfyUI/custom_nodes, install requirements, restart. Linux users want sudo apt-get install libglfw3-dev libgles2-mesa-dev freeglut3-dev for the render half of the pack.

Where people get burned

This is one of the pack's slowest nodes - it's genuine optimization, not a forward pass, and it runs on the GPU while holding the motion in memory. Don't be surprised if the first run takes a while on 196 frames.

The quality knob is the iters/step_size pair. Crank num_smplify_iters to 50–100 and drop smplify_step_size to 0.05 if your rendered body's hands or feet are drifting off the skeleton. But watch the loss, not just the visuals - the README's loss numbers are the real diagnostic, and if it explodes toward NaN you've overshot the step size.

One more honest caveat: this is "version 1" territory. Real-world users report the fitted bodies are decent but not perfect - joints occasionally jump on individual frames, which shows up in the rendered OpenPose. For previewing a motion cheaply, skip the body entirely and use Motion Data Visualizer's fast pseudo-OpenPose instead; reserve SMPLify for when you actually need the mesh.