Nick Dodd || Certified Geek Blog

Revisiting a 10-Year-Old Kinect Head Tracker

A while back I came across an old Kinect head-tracking project whose last meaningful commit was nearly ten years ago. The idea was solid, the math was fine, and the output was useful — but it wasn’t particularly stable when used for more than a few minutes, or if it lost your face.

I’ve been spending more time in my racing and driving simulator lately. While I have a solid cockpit setup with a single 42" display, not being able to naturally look around the car felt limiting. I knew there were webcam-based solutions, but I couldn’t find mine — what I did find was a Kinect 360.

The Kinect isn’t just a camera; it provides depth data. That led me down the path of looking for Kinect-based head tracking, which is how I discovered this old GitHub project.

This post documents why I forked it, what I focused on fixing, and how that work became Kinect Head Tracker V2.

Context: An Old but Useful Project

I wasn’t involved in the original development. The project was already done and essentially abandoned when I found it. The Kinect v1 SDKs haven’t changed much over the years, so the underlying approach was still valid.

The issue wasn’t functionality. The issue was reliability.

In real use — especially for sim racing or driving games — the application could run into problems after extended runtime: tracking would stop updating correctly-and the app would crash, memory usage would creep (and eventually crash), or the face-tracking pipeline would quietly fail and the app would, you guessed it, crash.

What I wanted was a head-tracking data source that could be run continuously without needing attention. I specialized in Windows application development for a lot of years so I knew this was a foundation I could work with and build this app right!

What I Focused On

Instead of adding new features, the work focused almost entirely on making the existing functionality dependable. Most of the effort went into areas that aren’t obvious from the outside:

Memory and resource management: tightening up image handling and unmanaged resources so the process doesn’t degrade over time.
Face-tracking recovery: ensuring that losing a face — due to movement, lighting changes, or occlusion — doesn’t leave the system in a null state or another bad state.
Long-session behavior: validating stability over extended runtimes rather than short test runs. This was a crucial to validate the memory management, tracking engine stability and recovery over time and power event changes.
Clear separation of responsibilities: keeping tracking logic isolated from networking and output.

None of this changes what the software does — it changes how reliably it does it.

Kinect Head Tracker V2

The result of that work is Kinect Head Tracker V2. Functionally, it’s still a Kinect 360 face-tracking application that outputs head-pose data. In practice, it’s far more predictable under real-world use.

One architectural decision that made a meaningful difference was maintaining a strict boundary between:

The tracking engine — responsible only for Kinect initialization, face tracking, and pose extraction.
The transport layer — optional UDP streaming, controlled explicitly, with no tracking logic mixed in.

That separation keeps the data source clean and makes failures easier to reason about when they do occur.

v2.1: Refinement

v2.1 builds on the stable base from v2.0 with incremental improvements rather than major changes. The focus here was refinement: cleaner control flow, clearer UI behavior, and fewer edge cases that require restarting the application.

At this point the tracker behaves like a product rather than a prototype — something that can be run and left alone.

The Public Fork

My fork of the project is available here:
https://github.com/tensioncore/KinectHeadTrackerV2

It’s published so others can use it, inspect it, or build on it without having to rediscover and fix the same stability issues I found.

What’s Next

v2.2: Signed Windows Distribution

V2.2 will ship as properly code-signed Windows application with an installer.

The basic settings in the GUI now will all be functionally complete. Being able to ship the product as an installer and being properly code signed will allow anyone to download and run it without an security warnings about Unknown developer - The code will be timestamped and code signed, and you won't need to build it from source!