The localai-org repository on GitHub has released skin-tokens.cpp — a C++23 and GGML port of the SkinTokens/TokenRig auto-rigger from VAST-AI-Research. The system automatically builds a skeleton and skinning weights for a static GLB mesh, but, unlike the original, which required an NVIDIA GPU with at least 14 GB of VRAM and PyTorch, it runs on CPU or Vulkan without Python dependencies. Weights are distributed in GGUF via Hugging Face, and binding to an existing skeleton preserves the animation hierarchy in the exported GLB.

image
image
image

What happened

The skin-tokens.cpp project has been published in the localai-org repository on GitHub: the repository was created on 2026-02-08, and the last commit is dated 2026-08-31. The tool takes a static GLB mesh and generates a skeleton with skinning weights for it, or binds the mesh to an existing skeleton, preserving the animation hierarchy in the exported GLB. The entire original pipeline — the Michelangelo mesh encoder, the TokenRig autoregressive policy on Qwen3-0.6B, FSQ-VAE, and the chunked SkinVAE decoder — has been rewritten for GGML and runs on CPU or via Vulkan without PyTorch and a Python runtime. Weights are distributed in GGUF F16 and F32 formats via Hugging Face (LocalAI-io/SkinTokens-GGUF). An optional end-to-end chain is available: trellis2cpp generates and remeshes a humanoid, Kimodo animates it, and skin-tokens.cpp binds the mesh to the animation skeleton; an experimental SOMA30→Mixamo52 retargeting is also implemented.

Context

Auto-rigging addresses one of the most manual stages of 3D production: for a static model to move, it needs a skeleton and correct skinning weights, which are usually placed manually by artists or via cloud services. The scientific novelty of the approach — autoregressive rig generation through a compact token representation — belongs to the original VAST-AI-Research work, described in the SkinTokens paper (arXiv 2602.04805); the original code is distributed under the MIT license. The value of skin-tokens.cpp is different: it is an engineering port of a ready-made method to the GGML stack, removing the hardware barrier. A separate point of interest in the architecture is the "small" LM policy TokenRig on Qwen3-0.6B for a structured 3D task instead of a large model. The port fits into a broader pattern: scientific 3D pipelines are gradually being moved to GGML and consumer hardware, closing the local loop of model generation and animation.

Why this matters for the industry

Previously, automatic rigging was either manual work or a task for a CUDA/PyTorch stack with a server GPU, which excluded local tools. skin-tokens.cpp turns it into an embeddable C++ component: through a flat C API (skintokens.h), auto-rigging can be embedded in local tools, game pipelines, and DCC plugins without Python dependencies and without a VRAM requirement. The combination of trellis2cpp + Kimodo + skin-tokens.cpp closes the full local loop "mesh → skeleton → motion → animated GLB" on consumer hardware. For cloud auto-riggers, this is pressure on the moat, but it is too early to talk about established commoditization: it implies confirmed quality on diverse meshes, and so far there is only the claimed decoder equivalence from the README. If the community reproduces the metrics and independent benchmarks appear, plugins for engines and DCC tools, batch rigging services, and the first products on the trellis2cpp + Kimodo + skin-tokens.cpp chain are likely.

Why this matters for users

The port can be tested even without a discrete graphics card: it is enough to download the GGUF weights from Hugging Face, build the CLI (CMake + Ninja, optionally Vulkan), and run your static GLB through the rig or skin command on CPU. For a quick evaluation without building, there is a Go/WebGL web demo that works directly in the browser, and for integration into your own tools — a C API (skintokens.h). The most reliable scenario today is binding ready-made meshes to existing skeletons and batch processing of ready-made models; unconnected skeleton generation should still be considered an experimental feature, not a replacement for manual rigging in production.

What is still unknown / limitations

All port metrics are self-reported from the README: the claimed closeness to the PyTorch reference (relative L2 of the decoder 3.6e-6 on CPU and 9.1e-4 on Vulkan, top-4 bone match per vertex) is a metric of inference equivalence, not rigging quality against ground truth. There are no independent benchmarks against baselines like UniRig and Puppeteer in the provided sources. Unconnected skeleton generation is marked as experimental, SOMA30→Mixamo52 retargeting is also experimental, and no quantitative metrics have been published for the Trellis2 + Kimodo end-to-end chain. For verification against the PyTorch reference, F32 conversion of the official checkpoints is proposed — an advanced path for verifying reproducibility.

Sources

Author

Look at AI, editorial team