🧍 Kimodo Model (dropdown)

Kimodo is the pose-and-motion side of the stack - it produces SOMA-format motion data that then gets baked onto a rig. Its loader takes a model_name, which sounds friendly and is a trap: it's a bare name that gets resolved against a directory you set somewhere else entirely. KimodoModelDir is the dropdown that lists the checkpoints that actually exist in that directory, so you stop guessing at folder names.

The quirk that makes it worth a node

This is the one picker in the pack that returns a name instead of a path. Most directory pickers give you an absolute path because the downstream node wants one. Kimodo's loader doesn't: load_model resolves its model_name argument against CHECKPOINT_DIR, so if you hand it a full path you get a load failure that reads like a missing model rather than a malformed argument. So this node enumerates the subdirectories of your checkpoint root, shows you their names, and hands back the name you picked - nothing else.

Small thing, big difference in frustration. It also means the node is only meaningful alongside the Kimodo nodes; on its own the output string is just a directory name.

How it works

The root comes from the CHECKPOINT_DIR environment variable if it's set, otherwise from a built-in default path baked into the pack. The node lists the immediate subdirectories of that root, hides dotfile entries, sorts them, and builds a dropdown. If there's nothing there, you get a single placeholder row and a refusal that names the variable to set.

It's built from the same factory as the HY-Motion and See-Through pickers in this pack, which is why the three look and behave almost identically: same one-widget dropdown, same model_path output name, same mtime-based change check on the root. The only differences are the root variable, the default path, and the expansion rule - here, "don't expand, return the bare name."

Inputs and output

model_dir - the dropdown. Despite the internal name, every entry is a checkpoint name. Pick one; the first entry is selected by default.

model_path - a STRING containing that bare name (the pack keeps the output named model_path across all three pickers for consistency, even here where it's a name). Wire it into KimodoLoader's model_name input.

Installing it

cd /path/to/ComfyUI/custom_nodes
git clone https://github.com/JayDataEngineer/melite-utility-nodes.git

Restart ComfyUI, or install Melite Utility Nodes from ComfyUI Manager. The pack declares matplotlib and av - for its plot and media-decode nodes, not this one.

Then point it at your checkpoints, in the environment ComfyUI is actually launched with:

export CHECKPOINT_DIR=/path/to/kimodo/checkpoints

The pack's fallback default is a container path from the author's own estate, so if you're not running that image, the environment variable isn't optional. The node listing nothing is the giveaway that you never set it.

Where it bites

• You can't tell paths from names by looking at the node. Both this and the HY-Motion picker have a dropdown called model_dir and an output called model_path; one returns a name, one returns a nested path. Check which node you dropped before you debug the loader.
• The dropdown is a parse-time snapshot. Install a checkpoint while ComfyUI is running and you'll need to refresh the node or reload the page before it appears.
• Non-recursive. If your checkpoints are nested one folder deeper than the root you configured, the dropdown will be empty or full of the wrong things. Move the root up.
• CHECKPOINT_DIR is a dangerously generic name. It's not a ComfyUI convention; other tools use similarly named variables, and if something else in your environment exports it, this node silently resolves against the wrong root. If your dropdown is listing models that have nothing to do with Kimodo, that's the reason.
• Almost nobody has written about these models in ComfyUI terms. There's no community thread, no shared workflow, no wrapper pack to compare against - the Kimodo line is a private-ish pipeline that happens to ship its utilities publicly. So there's nothing to google when something goes wrong; the failure messages from these nodes are unusually explicit and are genuinely the fastest path to the answer.