The first thing on the docket today was writing up yesterday’s dev log. I usually intersperse coding and writing so that by the time the day is done, the blog post is ready to go, but that just didn’t happen yesterday. Thankfully, I was able to carefully trace through my development progress by rereading my Claude Code chat logs.
When it comes to wrapping up this runtime animation curve editor, there are a few small bugs I need to fix and a bit of testing I need to do before merging it into the main build.
2 prompts and 2 fixes. No more bugs that I can see. Now on to the next thing. I noticed while running a grammar check on yesterday’s entry that the agent suggested corrections for inline quotes, something I thought I’d instructed it not to do. It turned out that the regex checker wasn’t accounting for curly quotes and was only looking for straight ASCII quote characters. Easy enough. 3 prompts, 3 fixes. One last thing—fully removing my deprecated CurveSettings scriptable object and updating the docs. 4 prompts…you get the idea😉
It’s finally time to merge my animation curve branch into my master.
Stupid, silly me! I forgot to pull the five most recent commits to my local repo from the origin before I branched off to work on the animation curve editor. Ergo, we now have conflicts. The worst part is that in one of those missing commits, I ran a CSharpier format on all the scripts in my project.
That actually wasn’t so bad. I migrated the settings files for my CSharpier formatting from master to the new branch and then proceeded with the merge. There were only five files with conflicts, and I went through each carefully. Then, after fixing the conflicts, I attempted to run a CSharpier format. I had to update my custom VSCode formatting tasks to invoke charpier instead of dotnet-csharpier, but after doing that, the formatting went through. Finally, I ran the Unity scene to ensure there were no errors. All looked good, so I merged.
It was time to tackle a critical task I’d put off for a few days—testing the 850nm IR lights I bought from Amazon in order to enhance hand tracking in poorly lit environments.
I needed a way to easily turn on the IR lights from across the room, but unfortunately, I had no spare power strips to use. Luckily, I remembered the DIY motion-activated outlet sitting in one of my cabinets that I’d rigged together years ago using ultrasonic sensors and a mini Arduino. It was still intact and, most importantly, still functional. I grabbed an extension cable and ran it from my custom outlet to the IR light across the room, sitting below the Kinect.
Next, I loaded up Kinect Studio on my computer and activated the 3D point cloud scene. I turned off the lights in my room, and nothing on the screen seemed to change. Hmmm. I mean, that made sense considering IR light is not on the visible light spectrum, but since ChatGPT had convinced me that adding scene lighting could indirectly improve depth stability by increasing material IR reflectance, it was not a good sign that nothing happened. I theorized that perhaps this was because my bright computer monitors were providing enough light, so to test, I started a screen recording in OBS Studio, turned off my monitors, and walked to my outlet to test triggering the light.
That empty black box in the bottom right of the image is the color stream. As you can see, my room is completely dark. Also, as you can see, triggering the IR light contributed absolutely nothing to the depth data.
Below, you can see an IR stream of me triggering the light via motion. Clearly, it has no effect.
I’m left with more questions than answers. Did ChatGPT hallucinate when it recommended buying IR lights that emit at 850nm, the same frequency as the Kinect V2? And if the IR sensor tracks my hands completely fine in the dark, then why did I run into tracking issues at Love Burn?
It looks like I need to do more research. Also, there’s a certain Amazon return I need to make.
Tags: debugging claude kinect github vibe-coding hand-tracking lighting