And for my second round of settings menu improvements, I did the following:
- Recategorizing all scene properties into sections and groups that make sense. No more separate “Style” and “Color” sections. The new categories (Space, Kinect, Ball, Hands, Particles, and Debug) are more intuitive. Everything now feels like it’s in its proper place.
- Sections on a sidebar. No more foldout-menu-ception.
- Range sliders get input fields just like the inspector. No longer will I have to finesse those sliders just perfectly to get a desired value.
- Style improvements. Before, this looked like something an engineer built as an afterthought. Now, I present to you…
At this point, it’s becoming increasingly easy to tackle complex tasks in this project, so I figured I’d point Claude at another one—syncing the particles’ framerate with the camera feed. Since the particles already render onto a separate render texture (this design is what allowed for their separate post-processing layer I added last week), Claude made it so that the particle output texture only updates when the Kinect camera delivers a new frame from its color stream, allowing for a truly perfect sync between particles and the color camera, lag and all. I made this feature an optional toggle in the Kinect scene settings that only shows when the color feed is enabled.
Speaking of lag, I’ve been experiencing quite a bit of it in the color stream on this computer, even when previewing from Kinect Studio. Weirdly enough, the point cloud doesn’t lag. I asked Claude about this and it reminded me of the obvious source of all camera issues (which should be a reflexive instinct by now)—the USB port. I switched ports and the color stream FPS jumped back up to 30. Apparently, the color stream has a heavier bandwidth than the point cloud stream, which is why only the former was lagging.
Talk about blog enhancements
- Fixing tagging system, then completely overhauling it
- Updating dangerous NPM packages
It was long overdue, and much needed, so I finally ran an audit on this blog’s code. I ran an npm audit and updated dangerous packages to less dangerous versions. I also had Claude take a look at the post pipeline I designed a long time ago and haven’t looked at in ages. The agent flagged quite a few things.
I’d originally given the LangChain harness multi-provider support, since I built in agent-integration at a time when I genuinely didn’t know whether to use Gemini, Claude, or ChatGPT for a given task. Nowadays I’m a Claude Max subscriber, so this LLM flexibility adds unneeded complexity to a closed-source project I solely maintain. Therefore, I had LangChain removed in favor of Anthropic’s SDK.
I ran a /checkup on the .md files in the repo, trimming AGENTS.md in half and fixing a rule that led to duplication of instructions (aka sources of doc drift).
I fixed multiple bugs in the media-renaming pipeline, one of which caused a webm in today’s post to get swapped for an older webm from a different post. I also ensured .DS_Store files in /media from my Macs could no longer end up getting synced by rClone.
Then I turned my agent toward my flawed auto-tagging system. Pretty much every post I auto-tagged with an agent in the pipeline would annoyingly end up with an “ar” hashtag. Turns out this was due to a substring bug which mapped a suggested tag to the first existing tag that was a substring of it. This meant that “#particles”, “#raymarching”, and “#architecture” all became “#ar”, “#gui” became “#ui”, “#containers” became “#ai”, and “#vfx-graph” collapsed to “#vfx”. No wonder. After fixing this bug, I decided to go all out and completely overhaul the system with new suggestions from Claude. It derived an entirely new tag lexicon, turning tags.txt from a line-separated list of tags into an instruction manual for when to use which tags. I spent about an hour tweaking things here to ensure that no hashtag ended up as a generalized blanket fallback tag all posts could use. I experimented with updating the tagging model from Sonnet 4.5 to Sonnet 5.5, and then even had my Opus session agent deploy some clones of itself to categorize my old posts. Opus tended to under-tag posts and Sonnet tended to ignore directions, so by the end, I did some manual pruning and tagging. I’m happy with the result now; post hashtags are much more relevant; perhaps they’re even useful. For future posts, I set the tagging agent to Haiku 5.5—we shall see how that goes.
I realized that one of the most off-putting things about the particle movement is the fact that particles emitted from the hands don’t really respect the motion of the hands.
My first thought was to give the particles an initial velo matching that of the hand which emitted them. This, unfortunately, did not add any coherence to their movement in any of the frames following their emission. My physics background doesn’t extend beyond high school (albeit AP level) courses, so I knew that I had to just describe the effect I wanted visually, rather than scientifically:
Claude Prompt
When I’m in the pool, and I wade my hand through the water, even water that’s further away from my hand follows its flow because the water molecules are all connected. I’m hoping for a similar experience here. It’s my understanding that the qi energy I’m trying to capture in this project similarly respects the motion of disturbing forces. So I ask you, am I designing this pull/push addition to the velocity all wrong? The sphere itself seems to adhere to these principles based on the physics I’ve given it, but the particles behave differently.
Lo and behold, that was enough to get things moving in the right direction.
Claude Response
What water does instead is pull each bit of fluid toward the velocity of the fluid around it. For a particle, that is velocity += (flowVelocity − velocity) × drag × dt, where flowVelocity is the hand’s velocity faded by distance from the hand. A particle near the hand quickly matches it, a far one barely feels it, and nothing overshoots the hand’s speed. This is the same shape as what makes your sphere feel right: forces plus drag, rather than raw velocity injection.
It took a wee bit of tweaking—in the first pass, Claude forgot to scale the drag it added by the hand’s speed—but now, this does indeed look more like water.
Tags: blog ui particles physics kinect prompting ai rendering