I drafted a capture-and-prune guide the day before this post. It read clean: shoot your own video, train it, prune hard, then A/B the result against the original in a viewer. The hero-NPC capture pipeline was the biggest unknown left in the build, and that doc was how I planned to take the risk out of it.
Next I built the thing that would actually run it: a side-by-side comparison view. Both scenes preload through the existing splat LOD ladder, the swap is an entity-enable flip, the camera is shared. Auto-flick the two at a couple of hertz and anything that diverges jumps out at you — your visual system can't help but see the motion. A snapshot button burns both halves into a labelled side-by-side PNG for the numbers table.
Then I went to verify the install steps the guide would tell people to run. The canonical PUP-3DGS repo (the CVPR 2025 paper authors' own implementation) consumes the on-disk directory shape of the original graphdeco-inria 3DGS trainer: a folder with point_cloud/iteration_30000/point_cloud.ply plus cameras.json and cfg_args. Not Nerfstudio's output. Not gsplat's. Not Postshot's. All three of the trainers my doc had listed as compatible don't feed the pipeline directly at all.
Worse, the prune ratio isn't the single flag I'd written. It's a fixed two-round shell script: round one drops 80% with 35k iterations of fine-tune, round two drops half of what's left, about 90% net. Anyone following my first draft would have spent half an hour standing up the wrong trainer, opened the prune CLI, and hit a file-not-found on the wrong directory shape.
So I rewrote the doc. The trainer recommendation flipped, the prune step became two passes instead of one flag, and the wall-clock estimate went from a hopeful 30 minutes to a realistic hour and a half on a first run. The commands in it now match what the repo actually runs.
The comparison view didn't care — it doesn't know where the .ply came from. The phone checklist I'd written for recording (manual shutter, locked exposure, loops not lines) was right from the start, because those rules sit below the trainer choice. The only half of the work that turned out wrong was the half that named specific external tools.
The lesson is narrower than "always read the source." The doc was drafted in good faith from project pages and paper abstracts, which is exactly what you should read to plan this kind of thing. The miss was that it encoded specific CLI commands, and the only authoritative source for a CLI command is the script that runs it. Building the tool forced me to check each command before I wrote it down, which caught the gap before anyone hit it.
Validate before you validate. The thirty minutes saved aren't mine; they're whoever does this next.