OpenPose Render (AnimoFlow)

This is the last node in the AnimoFlow video chain, and the one that produces something you've almost certainly seen: the little stick-figure skeleton video that pose-conditioned video models (and ControlNet pipelines) eat as input. AnimoFlow_OpenPoseRender takes the 3D pose keypoints from AnimoFlow_SmplToOpenPose3D and the camera from AnimoFlow_Camera, and rasterizes them into actual frames - a ComfyUI IMAGE batch in the exact drawing convention that controlnet_aux/DWPose outputs use. Draw a character, film it, render the skeleton: that's the whole branch in three nodes.

Why the drawing convention matters: pose-conditioned video models are trained on OpenPose/DWPose outputs - skeletons rendered with specific colors, line widths, and joint order. If your rendering doesn't match that convention, the model treats it as unfamiliar conditioning and the result degrades. This node draws in that exact style, so your generated motion plugs into a Wan-style pipeline as if it had come off a real DWPose detector. That's the whole trick of the demo branch, and it's why the pack ships the text_kimodo_video workflow as the reference: it drives a Wan 2.2 Fun-Control generation off this node's output.

The settings

• pose3d_b64 - ANIMOFLOW_POSE3D from AnimoFlow_SmplToOpenPose3D.
• camera_b64 - ANIMOFLOW_CAMERA from AnimoFlow_Camera. These two have to come from the matching stage of the chain; you can't mix a pose from one run with a camera from another and expect the keypoints to land in frame.
• occlude_face - default true. Hides nose/eyes/ears when the head faces away from the camera, which matches what DWPose actually detects on real footage (a person facing away has no visible face). Leave it on; turning it off produces faces floating on the backs of heads, and a controlnet will happily condition on that nonsense.
• max_frames - default 0 (all frames), max 1024. Trims the batch to N frames. The tooltip is the pro tip: Wan models want 4n+1 frames, e.g. 81. The text_kimodo_video workflow resamples to 16 fps and clamps to 81 frames for exactly this reason. If you're feeding a Wan model, this is where you make the count legal.

Outputs

images - an IMAGE batch (the frames), and fps - an INT telling the downstream video pipeline how fast to play them. Feed images into a VHS-style loader or directly into your video model's conditioning input, and fps into whatever plays the result.

Using it

It's a native node, but it does have a real dependency: opencv-python-headless, which ships in the pack's requirements.txt. The node falls back to PIL drawing if cv2 is missing and produces near-identical frames, but the README recommends installing opencv in the ComfyUI venv for pixel-exact controlnet_aux parity - so if your control videos look subtly different from what DWPose produces, that's the first thing to check. Install is the standard nodes step (Manager, search "AnimoFlow", or git clone https://github.com/AnimoFlow/comfyui-animoflow.git), and only the generator feeding the chain needs Docker. One honest caveat: the whole video branch is a demo in the pack's own framing - genuinely useful, but it exists to show the capability (and it's what makes the Wan workflow possible), not as the main product path.