kimodo.cpp: running NVIDIA's Kimodo text-to-motion model in C++ with GGML
Animate skeletons with natural language; NVIDIA's Kimodo ported to C++/GGML
At a glance
- What is it?
- A C++/GGML port that turns text prompts into skeleton animation on CPU or Vulkan, with native GGUF weights for the SOMA and Unitree G1 checkpoints. The port is narrow on purpose, and the SMPL-X checkpoint is not in the downloader.
- Who is it for?
- Adopt kimodo.cpp if you want Kimodo inference inside a C or C++ program with GGML, on CPU or Vulkan, and you only need the SOMA or G1 skeletons. Do not adopt it if you need the 77-joint SOMA presentation skeleton, skinned-mesh GLB export, quantised models, or general constraint input; the README lists all four as not implemented yet.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 18 days ago.
- What is it written in?
- Mainly C++, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 16, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What kimodo.cpp actually gives you
kimodo.cpp is a GGML/C++ implementation of NVIDIA's Kimodo text-to-motion model. It takes a UTF-8 prompt, or a precomputed LLM2Vec embedding, and produces local rotations plus root translations. That is the whole output: a skeleton, posed over time, with no mesh attached.
The five released Kimodo motion checkpoints are supported. SMPL-X RP v1 predicts 22 joints. SOMA RP and SEED v1.1 predict a compact 30-joint control skeleton. G1 RP and SEED v1 predict 34 Unitree G1 joints. The text encoder runs in eight-layer Vulkan chunks by default, and KIMODO_TEXT_LAYER_CHUNK accepts values from 1 to 32 if you need to trade VRAM against speed.
The audience is narrow and worth naming. This is for engineers embedding motion generation into a C or C++ application, or into a Go service through the demo, who would rather link a library than call a Python model server. If your pipeline is already Python and PyTorch, the port adds a conversion step and a second runtime for no gain.
How the C API and GGUF loading fit together
The C API lives in include/kimodo/kimodo_capi.h. Model loading checks the motion GGUF and the text bundle before any inference runs, so a mismatched bundle fails at load time rather than halfway through a generation. That is the right place for the check.
Two entry points matter. kimodo_generate_embedding takes 4096 F32 values, the LLM2Vec embedding, and skips the text encoder entirely. kimodo_generate takes text and runs the encoder for you. Both return the selected model's root translations and local XYZW rotations.
The README is explicit that you should query the joint count from the result rather than assuming a fixed skeleton, which follows from having three different skeleton shapes behind one API. Sampling is DDIM. The pipeline is: prompt or embedding, text encoder, motion model, root translation and local rotation streams. Conditioned multi-prompt transitions are included, so you can chain prompts rather than restarting from scratch.
CPU and Vulkan parity tests ship with the tree, which is the useful signal here: the port is asserting that the two backends agree, not merely that both compile.
Installing kimodo.cpp and generating a first animation
The build targets Linux. You need a C++23 compiler, CMake 3.25 or newer, Ninja, Python 3 with the Hugging Face CLI, and the Vulkan loader and headers if you want Vulkan support. GGML is a pinned Git submodule, so initialise it first, then pull a model and build the debug preset.
git submodule update --init --recursive
scripts/download_gguf_weights.sh --output "$PWD" --model soma-rp-v1.1
cmake --preset debug
cmake --build --preset debug
ctest --preset debugThe installer verifies each published manifest and SHA-256 hashes. The test suite requires the local motion GGUF, text bundle, and fixtures, and per the README it never downloads weights by itself, so run the download step before ctest or the suite will not have what it needs. You can install several checkpoints by repeating --model.
For the browser demo, build the debug preset and run the Go server:
go run ./demo -addr 0.0.0.0:8094Open http://localhost:8094. The left sidebar holds the prompt and a persistent history; selecting a previous animation restores its prompt so you can regenerate from it. Each successful run writes a standalone animation.glb next to its raw streams at demo-output/<animation-id>/animation.glb. That file contains the animated node hierarchy and no mesh, which is what makes it droppable into a Three.js scene. It is also served at /api/animations/<animation-id>/animation.glb while the demo runs.
If you prefer not to manage system packages, Nix is optional and reproducible:
nix develop path:. --command cmake --preset debug
nix develop path:. --command cmake --build --preset debugThe 77-joint gap and other things that are not implemented
The most consequential limitation is a skeleton mismatch. NVIDIA's Python API expands SOMA's predicted 30 joints to a relaxed-hand 77-joint presentation skeleton. The native API returns the 30 joints the model actually predicts. If your downstream rig expects the 77-joint presentation skeleton, kimodo.cpp does not produce it, and the README lists 77-joint SOMA expansion among the unimplemented items.
The same list rules out general constraint input, skinned-mesh GLB export, and quantised models. Skeleton-only GLB export is what exists, so a pipeline that needs a bound mesh has to bind it elsewhere. Quantised models being absent also means you cannot shrink the footprint by dropping to a lower-precision GGUF.
There is a build-side constraint too. The GGUF parser fuzzer requires Clang, and the sanitizer preset disables leak detection because Vulkan loader and driver allocations are global to the process. That is a reasonable explanation, but it does mean asan-ubsan runs will not catch leaks in Vulkan paths. The asan-ubsan invocation also needs LD_LIBRARY_PATH pointed at the built ggml and ggml-vulkan directories, which the README spells out.
Weights, and why SMPL-X is not in the installer
The published weights live under the Hugging Face LocalAI-io organisation, not the GitHub localai-org organisation. The Llama-3-Kimodo-GGML text encoder is reusable and separate from the four redistributable motion repositories, each of which keeps a one-to-one relationship to its NVIDIA upstream: Kimodo-SOMA-RP-v1.1-GGML, Kimodo-SOMA-SEED-v1.1-GGML, Kimodo-G1-RP-v1-GGML, and Kimodo-G1-SEED-v1-GGML.
SMPL-X RP is deliberately absent from that installer. Its upstream terms are the NVIDIA Internal Scientific Research and Development Model License: internal, non-production R&D only, no commercial use, and derivative model redistribution prohibited. The README's position is that converting the checkpoint to GGUF is a new runtime representation of the same weights and does not replace its licence, so you must obtain the upstream checkpoint under its gated terms and convert locally.
That reasoning is worth taking seriously rather than treating as boilerplate. Skeleton names, parent links, and the Apache-2.0 port source do not by themselves make the SOMA or G1 checkpoints non-commercial, and the README says as much. It also notes that the SMPL-X Hugging Face metadata, model card, and access terms identify the internal-R&D licence, and that an apparently inconsistent LICENSE file has appeared in that upstream repository. The stated guidance is to treat the restrictive terms as controlling. The text bundle includes converted Meta Llama 3 material and keeps its own separate terms.
For a precomputed 4096-float LLM2Vec embedding, use --motion-only to skip the text side. Regenerating the bundle is only needed to reproduce a conversion, and both the SMPL-X checkpoint and the Llama base model are gated:
nix develop path:. --command hf auth login
scripts/download_weights.sh --output "$PWD/models" --with-text \
--model smplx-rp-v1 --model soma-rp-v1.1 --model soma-seed-v1.1 \
--model g1-rp-v1 --model g1-seed-v1How this differs from running the Python model
The obvious alternative is NVIDIA's own Python API. The difference is not speed, it is what you get at the end of the pipeline. The Python API expands SOMA's 30 predicted joints into the 77-joint relaxed-hand presentation skeleton; kimodo.cpp stops at the 30 the model predicts. If your consumer wants the presentation skeleton, the Python path already does work that the C++ path leaves to you.
The trade runs the other way on deployment. kimodo.cpp is a C++23 library with a C API, GGML as a pinned submodule, and CPU or Vulkan execution. There is no Python runtime in the loop, and the demo is a single Go server on port 8094. For a C++ application that would otherwise embed a Python interpreter or run a separate model service, that is a real difference in operational shape.
A second alternative is to stay in Python and export motion yourself. That keeps the 77-joint expansion and the mesh tooling, at the cost of the deployment model you were trying to leave. The honest framing is that kimodo.cpp trades upstream feature coverage for a native runtime, and the README's not-implemented list is the price list.
Licence and the cost of staying current
The C++ port and its original tooling are Apache-2.0. GGML and the model weights keep their respective licences, so the port's licence tells you nothing about whether you may ship a given checkpoint. The README's table is the thing to read: SOMA RP/SEED v1.1 and G1 RP/SEED v1 are under the NVIDIA Open Model License with commercial use permitted by the model licence, while SMPL-X RP v1 is internal, non-production R&D only with derivative redistribution prohibited. This is a description of the stated terms, not legal advice; the model cards and upstream agreements govern.
On maintenance, the last push to the default branch was on 2026-09-01. The repository is not archived. There are no retrieved releases, so there is no tagged version to pin against; the practical upgrade unit is the commit plus the pinned GGML submodule.
Upgrade cost concentrates in two places. First, the GGUF weights and the text bundle are separate artefacts with their own repositories, so a model refresh and a code refresh are independent operations. Second, the sanitizer and fuzz presets add build configurations you will want to keep working if you carry patches. The downloader verifies manifests and SHA-256 hashes, which makes reproducing a known-good weight set straightforward, but the README does not document a rollback path if a newer checkpoint regresses on your prompts.
Editorial conclusion
Adopt kimodo.cpp if you want Kimodo inference inside a C or C++ program with GGML, on CPU or Vulkan, and you only need the SOMA or G1 skeletons. Do not adopt it if you need the 77-joint SOMA presentation skeleton, skinned-mesh GLB export, quantised models, or general constraint input; the README lists all four as not implemented yet. Do not adopt it for SMPL-X unless you have obtained the upstream checkpoint under its gated internal-R&D terms, because the published-weight installer deliberately omits it. Before committing, build the debug preset, run ctest with the local motion GGUF and text bundle in place, and confirm that the joint count returned by kimodo_generate matches the skeleton you intend to animate.
Frequently asked questions
What is NVIDIA Kimodo?
It is NVIDIA's text-to-motion model, which generates skeleton motion from a natural language prompt. kimodo.cpp is a GGML/C++ implementation of it that accepts a UTF-8 prompt or a precomputed LLM2Vec embedding and returns local rotations plus root translations.
Is Kimodo free?
The kimodo.cpp port and its original tooling are Apache-2.0, but the weights carry their own terms. SOMA RP/SEED v1.1 and G1 RP/SEED v1 permit commercial use under the NVIDIA Open Model License, while SMPL-X RP v1 is internal, non-production R&D only and prohibits derivative model redistribution.
How do I install NVIDIA Kimodo?
For the C++ port, initialise the GGML submodule, run scripts/download_gguf_weights.sh with a --model such as soma-rp-v1.1, then configure and build with cmake --preset debug and run ctest --preset debug. The test suite needs the local motion GGUF, text bundle, and fixtures, and does not download weights itself.
Is nvidia kimodo open source?
The kimodo.cpp port is Apache-2.0 and its source is public. The model weights are separate: SOMA and G1 are published under the NVIDIA Open Model License, and SMPL-X RP v1 is under NVIDIA's Internal Scientific Research and Development Model License, which is why it is not in the published-weight installer.
Community notes