A Forgotten Neutrino, a Flat-Screen Bottleneck, and the Case for Walking Inside a Protein at Human Scale
In 1979, a physicist named John Learned published a short paper arguing that a cubic kilometer of deep Antarctic ice could catch neutrinos by watching for the faint blue flash of Cherenkov radiation. The paper was largely ignored. The detectors that followed — Kamiokande, IMB, later Super-Kamiokande — were built in tanks of heavy water and mineral oil, not ice. Ice was considered too noisy, too opaque, too messy. But the idea never fully died. A few stubborn researchers kept citing Learned's paper, and a decade later, the IceCube Neutrino Observatory broke ground at the South Pole with 5,160 optical sensors buried between 1,450 and 2,450 meters deep. The first detection of a high-energy cosmic neutrino came in 2013.
The thing that has always fascinated me about IceCube isn't the physics. It's the reconstruction problem. A single neutrino interaction produces a shower of secondary particles, and the sensors only see the timing and intensity of photons that happen to reach them. From that sparse data, you have to infer direction, energy, and flavor. It's a needle-in-a-haystack problem where the haystack is a cubic kilometer of ice and the needle is a probability distribution.
I bring this up because I spent the last three months working on a very different kind of reconstruction problem, and the shape of the challenge felt eerily familiar.
I'm a developer at a small computational chemistry shop. We build tools for structural biologists — the people who use cryo-EM and X-ray crystallography to figure out where every atom sits in a protein. A typical structure has a few thousand atoms, sometimes tens of thousands. The data is messy. Resolution varies wildly across the map. Side chains flop around. Ligands sit in ambiguous density. And the software that handles this — PyMOL, ChimeraX, Coot, Mol* — is built for a specific workflow: load a structure, rotate it, zoom in, click on an atom, check a distance, repeat.
That workflow is fine if you're on a workstation. It falls apart the moment you try to run it in a browser on a laptop with integrated graphics.
I found this out the hard way. Last October, a collaborator at a university in the Midwest emailed me a 4.2 Å resolution structure of a membrane protein they'd been struggling with for months. They wanted to do a virtual walkthrough with a group of students — share a link, let everyone explore the density map together, point at things. I said sure, I'll throw it on our web viewer. I spent a weekend trying to get it to render without melting my MacBook.
The problem wasn't the geometry. It was the bottleneck between the CPU and the GPU. Every time the user rotated the scene, we were re-uploading vertex buffers, re-computing bounding volumes, re-culling, re-sorting. For a protein with 50,000 atoms, that's a lot of round trips. The frame rate dropped to single digits. The fans spun up. The students would have been better off with a physical model made of pipe cleaners.
I tried everything. I moved the culling to a compute shader. I batched draw calls. I compressed the atom data into texture buffers. It got better, but not good enough. The fundamental issue was that I was treating the protein as a static mesh and the camera as the only thing that moved. But that's not how structural biologists think. They think in terms of residues, secondary structure, binding pockets. They want to walk inside the protein, not orbit around it.
So I started over. I built a new renderer around a different assumption: the camera is fixed at the origin, and the protein moves. Instead of transforming vertices on the GPU, I transform the view on the CPU and upload a single matrix. The protein becomes a static point cloud in world space, and the camera is just a coordinate frame. This is the same trick used in planetarium software and, as it happens, in neutrino telescopes. The detector is fixed. The sky moves.
The performance difference was immediate. I went from 8 fps to 60 fps on the same hardware. The memory footprint dropped by 40% because I stopped duplicating vertex data across draw calls. And the code got simpler — fewer shader variants, fewer state changes, fewer bugs.
But the real win was something I didn't expect. Once the camera was fixed, I could do something I'd never been able to do before: I could let the user walk through the structure at human scale. Not zoom in from outside, but stand at the origin and move through the density map like a corridor. At 1 Å per step, a 50 Å wide binding pocket becomes a room. A helix becomes a spiral staircase. A ligand becomes a piece of furniture.
I tested it with the collaborator's membrane protein. I loaded the structure, set the scale to 1 Å = 1 meter, and pressed play. I walked down the central pore. I turned a corner and found myself inside a hydrophobic pocket, surrounded by the faint ghostly density of side chains. It was disorienting and beautiful and completely unlike any molecular visualization I'd ever seen.
The students loved it. They spent an hour just wandering around. One of them said it felt like exploring a cave. Another said it made the protein feel real in a way that a 2D diagram never could.
I'm not going to pretend this is a solved problem. There are still issues with level-of-detail, with occlusion, with the fact that most proteins are not hollow tubes but dense blobs. But the core insight — that you can get massive performance gains by inverting the camera-model relationship — feels generalizable. It's the same insight that made IceCube possible: instead of trying to track every particle, you build a fixed detector and let the universe do the work.
If you want to try it yourself, the tool is called MolWalk. You can load a PDB file, set the scale, and walk through any structure in your browser. It runs on a five-year-old laptop. No GPU required. No install. Just a URL and a few seconds of loading.
The first time I walked through a protein, I felt like I was standing in a cathedral. I hope you feel the same.
