Inochi2D SDK for Realtime 2D Character Animation

Why Inochi2D Exists for Rigged Character Software

Inochi2D addresses a specific rendering problem: making layered 2D artwork appear to have depth and movement without replacing it with a full 3D character pipeline. The README describes the core technique as runtime deformation of 2D meshes created from layered art. Parameters influence the deformation, and the resulting changes produce the appearance of motion and depth to the viewer.

The repository is an SDK and the reference implementation of the Inochi2D Puppet standard. It is aimed at developers who need a rendering and model-processing foundation, including applications written in D or other languages connected through a C FFI. It is not the complete workflow for creating or presenting characters. The README points model riggers to Inochi Creator and VTuber users to Inochi Session, while stating that this repository is not useful as an end-user application.

That boundary matters when evaluating adoption. A team looking for an editor to prepare rigging data will not find that workflow in this repository. A team embedding puppet animation into a renderer, game or desktop application can use the SDK as the low-level implementation. The standard and SDK are related, but they serve different layers of the product stack.

Runtime Mesh Deformation and Integration Boundaries

The documented architecture begins with layered artwork that has been converted into 2D mesh data. At runtime, parameter-driven deformation changes that mesh. The renderer then submits the deformed vertex data through its graphics backend. The visual effect depends on the application supplying or wiring the model, animation parameters, renderer and update loop.

The SDK supports D projects and non-D projects. In D, the project is added as a DUB package. In C, C++, Rust and other languages, the documented route is a dynamic build that exposes a C FFI. A C header is copied to the output directory, and the README says that custom bindings must use the `cdecl` calling convention on every platform. That convention requirement is a concrete compatibility condition for anyone writing a binding.

The vertex layout can also affect integration. The `IN_VEC3_POSITION` build option changes `VtxData` so that the `POSITION` portion uses a 3D vector. The README recommends this when the target graphics library does not allow 2D vectors when passing position data to the GPU. The SDK therefore exposes a build-time choice rather than requiring every renderer to accept the same vertex representation. An adopter should compare that choice with the target graphics API before integration.

Building the Dynamic SDK for a First C FFI Check

The README directs non-D integrations to build the SDK with the D compiler `LDC2` and the `dub` build system. The documented first build command creates the dynamic library configuration:

dub build --config=dynamic

This command builds the SDK rather than launching a character viewer. The README says that a C header will be copied to the output directory, with the header located in `include/`. The application can then inspect that header and expose the SDK through its own binding layer. The repository includes examples under `examples/`, including `examples/basic-gl/` and model-oriented files, but the README does not provide a complete standalone first-run command for a new application.

For a D consumer, the documented approach is simpler. Add Inochi2D as a package in the project's `dub` file. The README does not show the exact dependency declaration, so this article does not invent one. The build configuration determines whether the result is a static D-only library, a `nogc`-only library, a dynamic C FFI library, a WebAssembly module or a unit test runner.

If the target renderer needs the alternate vertex representation, add `--d-version=IN_VEC3_POSITION` as a build argument.

The flag changes storage for `POSITION`; it does not turn the SDK into a 3D animation system.

Godot Integration Requires a Separate Binding Build

Inochi2D has an official Godot binding based on GDExtension and `nugodot`. The build requires either the target Godot executable to be available through the `PATH` environment variable, or a full executable path supplied through `GODOT_PATH`. The documented build command is run from the repository root:

dub build :godot

The resulting GDExtension is written to `modules/godot/out/`. The README instructs users to move the contents of that directory into a Godot project under a subfolder named `inochi2d`, then reload the project. After that setup, the project should be able to load `.inx` and `.inp` model files.

This path is narrower than the general SDK build. It assumes a Godot project and the matching binding toolchain. The README does not say that the general `dynamic` build alone creates a Godot module, so the two workflows should not be conflated. It also does not document model conversion or rigging in this repository.

The official SDK bindings list currently identifies Unity as well, but the README does not give build steps for that binding. A Unity adopter would need to consult the separate binding repository rather than infer a procedure from the Godot commands.

Platform Constraints and Build Option Trade-offs

The documented system requirements specify an x86-64 CPU with SSE4 or an Aarch64 CPU with NEON. The repository calls for at least 1 GB of RAM for larger models. GPU requirements depend on the selected renderer backend, which means the SDK cannot be evaluated independently of the application that will draw the deformed meshes.

Inochi2D has no dependencies on non-D libraries other than a POSIX-compliant C standard library. The README nevertheless recommends `glibc` on UNIX-like platforms until the transition to `nogc` is complete. That recommendation is a direct compatibility boundary, not a claim that other libc implementations are unsupported. It does indicate that the current transition state may affect the experience on UNIX-like systems.

Optimization depends on build type. The README states that SSE and NEON optimizations are enabled only in `release` and `release-debug` builds. The `debug` configuration provides no optimization and full stacktraces, while `release-debug` is optimized with some stacktraces. This gives an integrator a practical debugging choice, but it also means performance-oriented instruction paths should not be assumed in a debug build.

Other configurations include `static`, `static-nurt`, `wasm` and `unittest`. The `IN_NO_LEGACY` option disables legacy features. The README does not enumerate those legacy features, so the exact compatibility cost of that option is not documented there.

WebAssembly, Examples and Upgrade Boundaries

WebAssembly is supported as a build configuration, but the path is more specialized than the D or C FFI path. The README says that web use currently requires a patched `druntime` source tree. On Linux, it points to `sdk-toolchain` releases for obtaining that tree. It also states that precompiled release and debug SDK versions are available in nightly releases, with availability from main releases starting with 0.9. JavaScript wrappers and related files are located in `dist/`.

The repository contains technical documentation under `tech-docs/`, which the README says is shipped with the SDK. Examples are under `examples/`. These locations provide a starting point for inspecting data structures and integration patterns, but the README does not document a browser demo, a complete deployment procedure or a model authoring workflow.

For teams needing a prebuilt binary, the README identifies the Releases page as the source for precompiled SDK versions. Recent release information includes `v0.8.7` from 2024-10-02 and nightly builds from 2025-09-18. The repository is not archived, and its last push was on 2026-10-03, but those dates do not by themselves describe API stability or upgrade compatibility. Upgrade planning should inspect the release contents and technical documentation for the specific version being adopted.

Editorial conclusion

Adopt Inochi2D when an application needs to load and animate Inochi2D models through D or a C-compatible FFI, and when renderer support and platform constraints are acceptable. Do not adopt it as a standalone VTuber client or creator application. Verify renderer compatibility, target language bindings, model files and the exact build configuration first. The repository is not archived, and its last push was on 2026-10-03.

Frequently asked questions

Official sources

1. Inochi2D/inochi2d on GitHub
2. License: BSD-2-Clause
3. Project website
4. README
5. Releases