VMagicMirror, a VRM avatar driven by your keyboard and mouse

An avatar that moves because you moved

VMagicMirror is described as VRM software for Windows that moves an avatar with minimal devices, and the feature list in the project documentation is short enough to state in full.

It loads a VRM and displays the avatar's upper body. It reflects keyboard and mouse operation as motion. And a variable chroma key can be applied.

That is the entire product, and the third feature is the one that tells you the audience. A chroma key is a green or magenta background that a streaming platform removes, which is the technique for putting a synthetic character into a video feed. So the application is built for a specific job: appearing on stream as a VRM avatar whose body reacts to the streamer typing and moving the mouse, on a green screen, with no headset and no tracking hardware.

The documentation says exactly which situations this suits, and the reasons are all about not having to set up equipment. Streaming when preparing the equipment is a hassle. Making noise and movement during a live coding session. And a desktop mascot.

The third of those is the one that changes the scale. A desktop mascot is an avatar that sits on your screen while you work, and the fact that the same tool does both means the input model is deliberately coarse. Keyboard and mouse input is coarse by nature. It has no joint angles, no depth, no confidence values and no calibration. A tool built for a desktop mascot is not going to pretend to have those, and the absence of them is a design constraint rather than a limitation of the current implementation.

The version in the documentation is v5.1.1, dated 2026-09-30, and the project is by the author who uses the name Baku, with the English readme linked from the Japanese one at the top of the repository. The primary language is C#, the licence is MIT, and the default branch is `master`.

Where to get it, and what the source repository is for

The distribution and the source are different things here, and the documentation is clear about it.

Downloads come from a Booth page, and the application works on Windows 10 and Windows 11 environments. Operating instructions are in the manual at the documentation site, which is a Jekyll site, and there is a separate English readme in the repository for the developer-facing parts.

The repository is therefore the build source rather than the distribution channel. That is unusual for a desktop application, and it reflects that the project is distributed commercially through a marketplace while the code is open. The README points out that FinalIK is a paid asset, and the other paid items are named as well, which is the practical reason a build is not just a clone and a compile.

The top-level entries show the shape of it. There is `VMagicMirror/`, which is the Unity project, and `WPF/`, which is the configuration application. There is `Batches/` and `Batches_Test/` for the build scripts, `Commands/`, `BuddySample/`, `docs/` and `docs_buddy/`, a `docker-compose.yml`, `about_localization.md`, `vmm.ico` and a `pull_request_template.md`.

The `WPF/` directory is the more interesting of the two application roots, and it appears twice in the documentation, once as the project to open in Visual Studio and once as the path to a licence text resource at `WPF/VMagicMirrorConfig/VMagicMirrorConfig/Resources/LicenseTextResource.xaml`. The configuration app is a .NET desktop application, and the licence text the user sees in the GUI is managed as a XAML resource in it.

The `about_localization.md` file at the root, and the `l10n` idea behind the WPF app, indicate that the interface is localised. The documentation has a section on localisation at the end of its table of contents, so a translator or a user looking for the language list has a place to look.

For questions there is a Twitter account listed rather than a forum or an issue tracker, which is consistent with a project whose user-facing artefact is a downloadable application rather than a service.

Two projects, two toolchains, one build

The build instructions open with a piece of advice that saves a lot of confusion: place the repository in a suitable folder and avoid a folder path containing whitespace.

Then the two projects. You open the Unity project, which is the `VMagicMirror` folder in the repository, with Unity 6.3, and you open the WPF project in Visual Studio 2022.

The maintainer's environment is listed precisely, and the components matter more than the versions. Unity 6.3.13f1 Personal, and Visual Studio Community 2022 at 17.14.29, with the .NET Desktop component installed and the desktop development with C++ component installed, the latter being the setup required for Unity's Burst compiler.

That last detail is the one to note. A Unity project that uses Burst compiles a subset of C# to native code through a C++ toolchain, so a machine without the C++ desktop workload will fail at a point that has nothing to do with the code you are building. It is a setup dependency that is easy to miss and awkward to diagnose.

The version coupling between Unity and the WPF app is worth understanding too. The publishing instructions for the WPF side specify a target framework of `netcoreapp3.0` and a target runtime of `win10-x86`, in a Release | x86 configuration, with self-contained deployment mode. That is an unusual combination for a 2026 application, and it is a consequence of the Unity side: the Unity runtime and the configuration app have to agree on the process architecture and on how the two communicate, so the configuration app is published as a 32-bit self-contained build to match.

After publishing, the output files, which include `VMagicMirror.exe`, are copied into `Bin/ConfigApp/`. The documentation says the folder layout can be checked against the actually distributed VMagicMirror, which is a practical instruction for anyone who wants to know what the final arrangement looks like.

The asset list, and the parts that are not free

The asset section is the longest part of the build documentation, and it is the honest measure of how much this project leans on other people's work.

From the Unity Asset Store there are two. DOTween, and FinalIK. And FinalIK is noted as a paid asset, which is the one real cost in the list.

From elsewhere, the list runs to Oculus LipSync Unity Integration v29 for lip sync, VRMLoaderUI v0.3, SharpDX.DirectInput 4.2.0, RawInput.Sharp 0.0.3, Fly,Baby. ver1.2, LaserLightShader, MediaPipeUnityPlugin at v0.16.3 or later, and Roslyn Scripting.

Two of those optional purchases are called out explicitly. Fly,Baby. and LaserLightShader are sold on BOOTH, and they are not required for the build, but without them some of the typing performance does not work.

The MediaPipe plugin is the face and hand tracking component, and it has a manual step. The model data files, which are `.bytes` files, have to be moved into a `StreamingAssets/MediaPipeTracker` folder. Three of them are named: `face_landmarker_v2_with_blendshapes.bytes` and `hand_landmarker.bytes`, plus a third model file for whole-body tracking. The blendshapes file is the one that carries the mouth shapes, which is what makes lip sync possible, so the presence of MediaPipe is the reason the Oculus LipSync integration is also in the list.

The raw input libraries are installed manually rather than through a package manager, and the instructions are precise about it. For SharpDX, you download the `.nupkg` file from two NuGet galleries using the Download package link, expand each as a `.zip`, and take `SharpDX.dll` and `SharpDX.DirectInput.dll` from the `lib/netstandard1.3/` folder, then add them to a suitable place in the Unity project. RawInput.Sharp is nearly the same, with `RawInput.Sharp.dll` from `lib/netstandard1.1/`, placed under a folder called `RawInputSharp` beneath Assets.

The Roslyn scripting setup is the longest, with a full directory layout given for `Assets/CSharpScripting` holding the plugins from `Microsoft.CodeAnalysis.CSharp.Scripting-v4.8.0` and `System.Runtime.Loader-v4.0.0`. The documentation notes that NuGetForUnity might be able to install those packages, but that this was not confirmed at the time of writing, which is a candid way of flagging a shortcut that might not work.

There is one piece of housekeeping advice that saves a lot of noise later. Folders added directly under `Assets` should be moved into an `Assets/Ignored` folder, which is excluded from source control. The Unity Package Manager list completes the dependency set, with Zenject at v9.3.1, NuGetForUnity, UniVRM at v0.121.0, R3, UniTask, KlakSpout, a fork of MidiJack, uWindowCapture at v1.1.2 and uOSC at v2.2.0, plus R3 and NAudio pulled through NuGetForUnity.

Building it, and the documentation site

The build section is command-line first, and the batch scripts are the interface.

Building is done from the commands in the `Batches` folder, and the argument syntax for the batch files is documented in comments inside the files themselves.

build_wpf.cmd standard dev

build_unity.cmd standard dev

create_installer.cmd standard dev v1.2.3

job_release_instraller.cmd

The `standard` and `dev` arguments are the configuration and the target environment, and the version argument to the installer script becomes the version in the produced installer. The last script, `job_release_instraller.cmd`, uses the version value written in `version.txt` and runs the build and the installer creation in one go, which is the release path.

Two constraints on the Unity side are stated. The Unity project requires that all of the assets have already been installed, and the Unity version used for the build is specified in `build_unity.cmd`. If you need to build with a different editor version, you change the Unity path in that file. And creating the installer requires Inno Setup to be installed.

The documentation site is built with Jekyll, and the repository has a compose file for it, which is a small but pleasant detail.

services:
  service_jekyll:
    image: jekyll/jekyll:stable
    container_name: local_jekyll
    volumes:
      - ./docs:/srv/jekyll
    command: jekyll build --watch

The compose file runs Jekyll in watch mode over the `docs` directory and serves the built site from an Apache httpd container on port 80, with the site directory mounted from `docs/_site`. So the manual, the credit page and the documentation are all served from the same repository, and a contributor can see the site locally without installing Ruby.

The `Batches_Test/` directory alongside `Batches/` is the parallel build scripts for testing, which is the usual arrangement in a project where the release build and the test build need different steps.

Licensing, credits, and the piece of data that is not in the repository

The licence section of the documentation is unusually thorough, and it covers three separate things.

The first is the open source licences. The application shows the licences in its GUI, and the text of that screen is managed in a file, the `LicenseTextResource.xaml` in the WPF configuration project. The list of licences used, including those used in the past, is published on the credit and licence page on the documentation site. And a note says that some of the images in the repository were created using the Otomanopee font, with the clarification that the font itself is not redistributed and the mention is only supplementary information.

The second is the models included under a Creative Commons licence. Two are named: `Gamepad.fbx` by Negyek, and `CarSteering.glb` by CaskeThis. The documentation says that in VMagicMirror a shading model is applied to the original models, to keep consistency with other devices, and that the textures are applied for customisation.

The third is the licensing of the third-party assets, which is where the paid FinalIK and the BOOTH assets live, and where the note about a different licence for third-party commissioned work appears.

And then there is the gap, which is the thing a builder needs to know about. The sub-character feature introduced in VMagicMirror v4.0.0 uses preset asset data set in `BuddyPresetResources.asset`, and that data is not included in the published repository, so following the build instructions exactly will not load it correctly.

The reason given is that the preset sub-characters were commissioned from a third party and their licence is different. That is a coherent reason, and it does mean a self-built binary is not identical to the distributed one. The documentation offers a workaround: apply dummy assets to the `Texture Binary` and `VRM Binary` slots, namely a suitable png of about 256 by 256 pixels renamed to `.bytes` for the texture, and a lightweight VRM file renamed to `.bytes` for the model.

So the overall picture is a project that is genuinely open at the code level, and that carries real third-party constraints at the asset level. The MIT licence covers the repository's own code, the Unity Asset Store terms cover the paid plugins, the BOOTH terms cover two of the optional assets, and the Creative Commons terms cover two of the models, and a commercial developer building this needs to be comfortable with all four rather than just the first.

Editorial conclusion

VMagicMirror suits a streamer or developer who wants a VRM avatar on screen without setting up a VR headset, a mocap suit or a face-tracking camera, and it suits anyone who wants to read a Unity and WPF application that produces a native Windows binary. It does not suit a Mac or Linux user, and it does not suit a build environment without Unity, Visual Studio with the C++ desktop workload, and paid Unity Asset Store packages. Verify first that you have the asset licences the build needs, notably FinalIK, that the MediaPipe model files are in place, that the sub-character preset data is missing from the public repository and needs dummy assets, and that the Unity version in the build script matches the one you have.

Frequently asked questions

Official sources

1. License: MIT
2. malaybaku/VMagicMirror on GitHub
3. Project website
4. README
5. Releases