Kimodo Save NPZ
When you want data, not a render
- motion
- file_path
Most export nodes in the Kimodo pack hand you a ready-to-use file for some other tool. Kimodo Save NPZ does the opposite: it saves the motion as data, a NumPy NPZ archive, so you can do whatever you want with it that no exporter anticipates. If you're scripting, training, comparing generations, or building your own pipeline, this is the node that gets you the raw goods before anything gets baked into a character skeleton.
What you get
Inputs: the motion from Kimodo Sampler and a filename_prefix (default kimodo_motion). It writes into ComfyUI's output directory and returns the saved file_path as a string.
Each NPZ bundles the motion's full representation (arrays are [time, joint, ...]-shaped):
posed_joints- joint positions[T, J, 3]global_rot_mats- joint rotation matrices[T, J, 3, 3]root_positions- root trajectory[T, 3]foot_contacts- foot-contact labels[T, 4]global_root_heading- root heading angle[T]
If you generated multiple samples (num_samples > 1), it writes one NPZ per sample with an index suffix, so a 4-sample batch gives you four files. Single sample gets one clean file.
Why you'd use it
Honestly, most people will skip straight to BVH/FBX and never touch this node. But it earns its place in three situations:
- You're going back to the source. NPZ is the canonical Kimodo output format - the same arrays the model produces, unsugared. If you want to eyeball the actual foot-contact predictions or root heading, this is where they live.
- You have downstream code. Blender scripts, analysis, retargeting you want to do yourself - loading
posed_jointsin numpy beats re-parsing an FBX any day. - Archiving experiments. It's the lossless keep-it-all format; exporters discard info (BVH loses a skeleton's flavor, FBX bakes into someone's rig).
Install and notes
Ships with Kimodo Motion Bridge (Manager → search the pack title, or clone + pip install -r requirements.txt + python install.py, restart). Node under Kimodo. Upstream it inherits the pack's heavy first-run reality - model auto-download and roughly 17GB VRAM for generation.
Two small things: filenames get a timestamp + short UID appended, so repeated saves never clobber each other (good - you'll thank it later). And remember this node saves the motion as-is: if you want the foot-skate-clean version, feed it the output of Kimodo Post Process rather than straight off the sampler.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| motion | KIMODO_MOTION | — | |
| filename_prefix | STRING | kimodo_motion | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| file_path | STRING | — |