Releases, performance work, and what we learn watching people debug systems we didn't write.
Layouts can now be pushed to a running viewer without restarting it, which turned out to matter far more than we expected: it makes the viewer scriptable from a notebook. We also rewrote the chunk scheduler so recordings stream from Hub with the same latency profile as a local file, and cut cold open time on multi-gigabyte files by roughly 70%.
Instanced draws only get you so far. The rest is a chunk layout that lets the GPU skip everything the camera can't see, and a decision to stop uploading data we already uploaded.
We sat with a deployment team and watched how they actually triage a failed pick. Half our roadmap assumptions did not survive the first afternoon.
H.264 and AV1 streams now decode on the GPU inside the viewer. Recordings that used to cost 40 GB of raw frames land closer to 900 MB.
Time-indexed, append-mostly, wildly heterogeneous data. We tried three designs before admitting that Arrow had already solved most of it.
A user opened a recording with 400,000 entities and the viewer took nine seconds per frame. The fix was small. Finding it was not.
We looked at 60 real recordings. The teams that could answer questions fast had one thing in common, and it wasn't the tooling.
Header-first, CMake and Bazel targets, and the same schema as everything else. Plus a Jetson build that doesn't need a cross-compiler.
Debugging tools have to be trustworthy, and trust means being able to read the thing. Here's where we draw the line between the SDK and Hub, and why.
WebGPU, a shared render backend, and the handful of places where we had to keep two code paths after all.
No drip campaign. Just what changed and what we learned.