Nodes/AnimoFlow/Resample Motion FPS (AnimoFlow)
ComfyUI Node

Resample Motion FPS (AnimoFlow)

The node that keeps your animation from playing at the wrong speed

By AnimoFlow·Created 2 months ago·Updated about a month ago· 1
Resample Motion FPS (AnimoFlow)
  • npz_b64
  • npz_b64
input_fps20
output_fps30

This is the least glamorous node in the AnimoFlow pack and the one most likely to be quietly doing essential work in your workflow. AnimoFlow_Resample changes the frame rate of a generated motion - and stamps the authoritative fps key into the NPZ so every downstream stage agrees on how fast the animation plays. Skip it and your motion doesn't just look wrong; it plays at the wrong speed, and the bug is maddening because nothing on screen tells you why.

The need exists because the pack's generators don't agree on frame rate. MDM, priorMDM, and MoMask all generate natively at 20 fps; Kimodo generates at 30 fps. The downstream Blender retargeter (AnimoFlow_Rig) derives its scene FPS from the BVH header, which in turn comes from the resampled NPZ's stamped fps key. The pack's curated workflows enforce the chain for you - the README notes the stage library is the single source of truth for this - but if you're hand-building a graph and you wire a generator straight into AnimoFlow_IK without a resample in between, you've introduced a speed mismatch that only shows up in the exported animation.

The three fields

  • npz_b64 - the ANIMOFLOW_NPZ pose tensor from any generator node.
  • input_fps - 1–120, default 20. Tell it what frame rate the motion was generated at. The generator's native_fps output is there for exactly this: wire it in and you can't get it wrong.
  • output_fps - 1–120, default 30. What you want it to become. 30 is the pack's default output rate and the right target for most video work - Wan-based video models want it too (more on that in the AnimoFlow_OpenPoseRender article).

The output is a single npz_b64, the same ANIMOFLOW_NPZ type, now time-resampled with interpolation. It drops into AnimoFlow_IK or AnimoFlow_SmplToOpenPose3D exactly where the generator's output would have gone.

The honest take

It's a pure utility node - 45 lines of interpolation logic in the pack's shared stage library, no model, no Docker, no weights. That's not a criticism; it's why it's reliable. The only real question is whether to reach for it or to just set everything to one frame rate and delete the node from your graph. Answer: keep it. The generators are pinned to their native rates and you can't change that, so resampling is the seam where all the frame rates get reconciled. It's also where you'd convert a motion to a higher rate for smoother playback in a Blender scene running at 30 or 60 fps.

One gotcha to know: because it's a native node running in the ComfyUI process (not an HTTP client), it needs nothing but numpy/scipy from the pack's requirements.txt - which ComfyUI Manager installs for you. If you cloned manually, make sure pip install -r comfyui-animoflow/requirements.txt ran against ComfyUI's Python, or this node (and AnimoFlow_IK, AnimoFlow_Rig, the filters) will fail to import even though your model containers are all healthy.

CategoryAnimoFlow/Motion

Inputs (3)

NameTypeDefaultDescription
npz_b64ANIMOFLOW_NPZ
input_fpsINT201–120
output_fpsINT301–120

Outputs (1)

NameTypeDescription
npz_b64ANIMOFLOW_NPZ