Camera (AnimoFlow)

In the AnimoFlow video branch, your generated motion exists as 3D keypoints floating in space. AnimoFlow_Camera is the node that decides where the camera is - it takes those 3D keypoints and produces a per-frame pinhole camera so the next stage can rasterize the motion into 2D frames. It's the "how do we film this" step, and it owns all the cinematography: framing, distance, angle, and the output resolution of the eventual control video.

The two mode choices are the heart of it:

• track - the camera follows the character, looking at a smoothed mid-hip target with a constant auto-fitted distance. The smoothing is a Gaussian over frames, controlled by the smoothing input (default 5, in frames), which is what stops the camera from twitching at every step. This is the mode for action that moves around a lot.
• frame_all - one static camera fitted to the entire trajectory, so the whole motion stays in frame from a fixed vantage. Better for a staged, objective shot of a contained movement.

The rest of the inputs are classic camera controls: azimuth (0 = frontal; characters start facing +Z, per the tooltip), elevation (default 10°), fov (vertical field of view, default 40°), and distance in meters (0 = auto-fit to the motion). The two that catch people: width and height (default 832×480) are authoritative for the video output - they set the frame size the whole branch renders at, and your downstream video model's resolution has to match them, not the other way around. And margin (default 0.15) is the fraction of the frame kept empty around the subject - the headroom/footroom budget; drop it if the character feels tiny in frame.

Where it sits

AnimoFlow_SmplToOpenPose3D (pose3d_b64) → AnimoFlow_Camera (camera_b64) → AnimoFlow_OpenPoseRender (images + fps) → video model

The single output is camera_b64 (ANIMOFLOW_CAMERA), consumed only by AnimoFlow_OpenPoseRender. It's a pure native node - numpy math, no containers, no Blender - so it's cheap to add to a graph and safe to fiddle with.

Notes and gotchas

The tooltip on azimuth ("0 = frontal, camera on +Z; characters start facing +Z") is a reminder of the pack's one convention you have to respect: characters are born facing +Z, and the camera's frontal position sits on +Z looking back. If your character spins mid-motion, track mode handles it; frame_all won't, and that's fine - it's a locked-off shot by design.

The important integration detail, from the README: the reference frame for the video branch is generated pose-conditioned on the control video's first frame, and the image prompt states the character's orientation to the camera to match the camera azimuth. In other words, pick your azimuth before you generate the reference still, or the still and the motion can conflict. And since width/height here are authoritative, changing them downstream in AnimoFlow_OpenPoseRender won't do what you expect - the camera node is where resolution lives.