VRCFaceTracking is the OSC bridge between tracking hardware and VRChat

What the bridge actually is

The repository description calls it an OSC App to allow VRChat avatars to interact with eye and facial tracking hardware, and the README states the purpose more directly: it provides eye tracking and lip tracking in VRChat by providing a bridge between your tracking hardware and VRChat's OSC server. That sentence sets the scope precisely. This is not a tracking application. It is not a camera pipeline, not an eye tracking SDK, not a face mesh solver. It sits on one side of a boundary and translates. The mechanism is OSC, the Open Sound Control protocol, which VRChat exposes as a server that avatar parameters and inputs can be addressed through. The application subscribes to whatever your tracking software publishes, and writes the corresponding parameter values to VRChat's OSC server. VRChat then applies those parameters to your loaded avatar. The audience is VRChat users with tracking hardware, most likely people who already run a webcam based eye tracker or a dedicated headset mounted system, and who want that output to reach an avatar rather than sitting in a separate application window. The result is that the interesting work in this ecosystem is split in two. The hardware and the tracking algorithm live elsewhere. What this project owns is the mapping layer, and it owns it well enough that the mapping is documented as a first class artefact with its own pages and its own wiki.

Parameters are the contract, and they are case sensitive

Once the bridge is running, everything depends on your avatar agreeing with it on parameter names. The README is clear that for the app to work you need an avatar with the correct parameters, or an avatar config file with the correct mappings. The system is designed to control your avatar's eyes and lips via simple blend states, but what the parameters control is completely up to you. That is an important separation. The application pushes a value, and whether that value means gaze direction, blink, or a mouth shape is decided by how you wire it into your avatar. The naming rules are strict. Similar to the setup of parameters with Unity Animation Controllers, the parameters are all case sensitive and must be copied exactly as shown into your avatar's base parameters. The eye tracking setup guide in the project wiki is linked from the README as the place to start, and the parameter list is published on the documentation site. There is a useful escape valve here too. The README notes it is not required to use all of these parameters, and that you do not need to use any of them if you intend to use VRChat's built-in eye tracking system. So this tool is optional by design, and someone who only wants eye tracking can rely on VRChat's own implementation. For lip and face tracking the parameter space is larger, and the documentation splits it into expression tracking parameters and a set of combined lip parameters, which are described as a way to group mutually exclusive face shapes.

Modules are how hardware support gets added

The extensibility story is a module registry, and the README describes it in two sentences: use the module registry to download addons and add support for your hardware. That is the answer to the obvious question about a bridge application. If it does not implement tracking, where does support for a specific tracker come from? From a module, fetched from a registry, rather than from a new build of the application. The repository layout backs this up. There are three project directories in the solution: VRCFaceTracking.Core, VRCFaceTracking.SDK and VRCFaceTracking.ModuleProcess, alongside the VRCFaceTracking project itself and a VRCFaceTracking.sln file. A dedicated process for modules means third-party code can run in its own process rather than inside the main application, which is a sensible boundary for something that executes downloaded add-ons. The ModuleProcess name is also a hint about the failure model. If a module misbehaves, the process boundary is where you would expect to notice it, rather than the whole application going down with it. The registry is therefore the load-bearing part of the design for new users. If your hardware has no module in the registry, the bridge has nothing to talk to, and the README does not document a way to write one from scratch.

The repository is a .NET solution with localisation built in

The source layout is conventional C# and worth a glance because it tells you what the project expects of its contributors and its build. At the root there is a VRCFaceTracking.sln, a Directory.Build.props and a Directory.Packages.props, plus a nuget.config. Central package management through Directory.Packages.props is the mechanism that keeps dependency versions in one place for a solution with several projects, and nuget.config controls where packages are restored from. There is a.vsconfig file, which is the Visual Studio component list used to pin the workloads and SDKs a contributor needs to install. The language is C#, and the build tooling is the standard.NET one. That combination is what makes the module boundary practical: a module can be distributed as a package and hosted in its own process without needing a native toolchain. One more entry stands out. crowdin.yml is at the root of the tree, which means translations are managed through Crowdin. For a project whose users are spread across languages, and whose output is largely user interface text and documentation, that is a reasonable way to keep localisation from being a pull request chore. The tree also carries a PRIVACY.md file alongside the LICENSE.

The documentation is spread across two places

If you are evaluating this project, the documentation is where the real information lives, and it is split. The README itself is short and mostly links. The getting started guide is at docs.vrcft.io/docs/intro/getting-started, and the README opens with a Get started here link to it. The documentation site also hosts the parameter list, with separate pages for eye tracking parameters and expression tracking parameters, and the README calls that list out with its own linked sections. The other half is the project wiki on GitHub, which holds the eye tracking setup guide under a page titled Eye Tracking Setup. The README encourages consulting the docs for a setup guide and more information about what each parameter does. That split is workable but it means an evaluation has to read both. The docs site explains the parameter protocol, and the wiki explains the avatar side, and neither is complete on its own. Two community channels are advertised. There is a Discord invite in the README, and the project publishes its releases through GitHub. The releases themselves are named in a way that tells you what changed. The 5.1.0.1 tag from July 2023 is a hotfix for binary param and mass-OSC sending, and 5.1.1.0 from the same month is the custom module installer, which lines up with the module registry story being a later addition rather than a feature of the first release.

Active code, stale release tags

The maintenance picture is the one thing to look at carefully here, and it is mixed. The repository is not archived and the last push was on 2026-10-16, so work on the code continues. The recent releases, though, stop much earlier: 5.2.3.0 on 2024-04-10, 5.1.1.0 on 2023-07-28 and 5.1.0.1 on 2023-07-27. So there have been commits in the years since the last tagged release, which means the binaries people are running come from an older point than the source tree. For an application whose whole job is talking to a live VRChat OSC server, that gap matters more than it would for a library, because VRChat adds parameters and changes its OSC behaviour over time, and a build from 2024 may not match the current client. The licence field on the repository says Apache-2.0, with a LICENSE file at the root. Apache 2 is permissive and includes an explicit patent grant, so redistribution inside a commercial project is straightforward provided the notice requirements are met. The practical advice is therefore narrow. If you are evaluating this for a deployment you will run today, check what version you can actually obtain and whether it matches the parameter set the current VRChat client exposes, rather than assuming the tip of the default branch is what everyone is using.

Editorial conclusion

Adopt VRCFaceTracking if you already own compatible tracking hardware and want its output to reach VRChat avatars, and expect to spend your time on the avatar parameter mapping rather than on software configuration. Do not adopt it as a tracking solution, since it neither implements the tracking nor provides the hardware, and do not adopt it for VRChat's built-in eye tracking, which the README says you do not need this tool for. Before building an avatar, copy the parameter names exactly as documented, because the mapping is case sensitive and a mismatch silently disables the feature.

Frequently asked questions

Official sources

1. benaclejames/VRCFaceTracking on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases