MotionMatching: a Unity package that grew out of a master thesis

A thesis project that became a package

The README explains the origin before it explains the software. The project originated from the author's master thesis, titled Motion Matching for Character Animation and Virtual Reality Avatars in Unity, and the thesis itself is offered for download as a deep dive into both the technique and the workings of this specific package. That framing tells you what kind of artefact this is. It is not a studio-grade animation system with a support SLA, it is a teaching implementation that happens to be packaged and usable, and the README says the project is a work in progress aiming to offer a comprehensive solution for Unity, useful as a resource for those who want to learn or implement their own motion matching solution or extend this package. A separate documentation site covers the project in more depth, and the repository holds the package under com.jlpm.motionmatching/ with a minimalproject/ directory alongside it.

Installing it as a git package in the Unity editor

Installation goes through the Unity Package Manager rather than a tarball or a registry. The README lists the steps: have Unity 6 or later installed, which the README notes is untested on other versions, open the Package Manager from the Window menu, use Add package by git URL, and paste the repository URL with the package subdirectory as the path:

	https://github.com/JLPM22/MotionMatching.git?path=/com.jlpm.motionmatching

The path parameter matters because the repository root is not the package, the package lives in the com.jlpm.motionmatching directory. Two optional steps follow for anyone who wants to see it working. The sample scenes are imported from the Motion Matching entry in the Package Manager through Samples and Examples and Import, and the scenes then appear under Examples/Scenes/ in the Project Window. There is one pipeline caveat in the README that is easy to miss: all the sample scenes use the Universal Render Pipeline, so conversion may be necessary if your project is on a different render pipeline.

From motion capture files to a pose and feature database

The directory layout explains the data flow of the system. Samples/Animations holds the motion capture files and the MMData files that define the animation database for the motion matching system, and the README has a detail that will confuse you the first time you open the folder: the motion capture files carry .txt extensions even though they were originally .bvh files. StreamingAssets/MMDatabases holds the processed pose and feature databases along with the skeletal information, and that directory is created automatically when you generate databases from an MMData file. So the pipeline has two stages. You point the system at a description of the animation database, and it produces a derived artefact, the pose and feature database plus skeleton information, which is what the runtime then uses. Keeping the derived data in StreamingAssets rather than in the asset folder is a deliberate choice for something that is generated and potentially large.

Two GameObjects carry the behaviour

The demo scenes are built around two primary GameObjects, and separating them is the clearest statement of the architecture. The Character Controller creates trajectories and imposes positional constraints, such as limiting the maximum distance between the simulated and the animated character position. That is the part that keeps a matched animation from sliding away from where the character actually is, and it exists as a separate object so the constraint behaviour can be adjusted independently of the matching itself. The MotionMatchingController handles all the motion matching operations, and it exposes adjustable parameters for enabling or disabling features such as inertialize blending or foot locking. Inertialize blending and foot locking are the two names a Unity developer will look for first, and the README explicitly invites you to tweak both controllers to build an understanding of how the system responds, which is the intended learning path.

Unity 6 and URP are hard constraints, and the roadmap is still ahead

The project is explicit about where it stands. The README asks for Unity 6 or later and says it is untested on other versions, which for a package that reaches into the animation internals is a reasonable line to draw but also means you cannot drop it into an older project. The sample scenes are all Universal Render Pipeline, and the roadmap section points to a detailed list of upcoming features and improvements hosted with the documentation, with the author noting that contributions and suggestions are welcome as the project moves toward a comprehensive solution for Unity. The repository itself is small, with .github/, CITATION, LICENSE, README.md, the package directory and the minimal project, and there are no GitHub releases, so there is no version history to pin to and no changelog to read. The last push was on 2026-04-24, which is a fair sign of a project that moves in bursts around research milestones rather than on a release schedule.

Used by research projects, and the citation to use

The list of projects using the package is the strongest evidence of what it is good for, and the entries are academic rather than commercial. They include Environment-aware Motion Matching from SIGGRAPH Asia 2025, Motion Matching for VR, a paper on expected collision feedback in crowded virtual environments, a Ragdoll Matching thesis, a social crowd simulation paper, a poster on improving motion matching for VR, and XR4ED. The citation section is unusually opinionated: if the package is useful, the README asks you to cite the SIGGRAPH Asia 2025 paper as the recommended citation, and keeps the 2022 master thesis as background and extra detail. The licence is MIT, and the citation file at the repository root, along with the CITATION file, means the academic lineage is treated as part of the package rather than an afterthought.

Editorial conclusion

Adopt MotionMatching if you are prototyping character animation in Unity, you want to understand the motion matching technique end to end rather than download a black box, and you are on Unity 6 with the Universal Render Pipeline. Do not adopt it for a production character pipeline, since the author describes the project as a work in progress with a roadmap still in front of it, and do not plan around a different render pipeline, since every sample scene uses URP and conversion may be needed. Verify first that your Unity version is 6 or later, import the sample scenes through the Package Manager to see the two controller GameObjects in action, and read the documentation site and the linked thesis before you commit, because the package carries no GitHub releases and the last push was on 2026-04-24.

Frequently asked questions

Official sources

1. Issues
2. JLPM22/MotionMatching on GitHub
3. License: MIT
4. Project website
5. README