DEV Community

Cover image for The ISS Tested Vision Rehab in Orbit. Structural Biology's Bigger Problem Is Still Flat Screens.
Ashish
Ashish

Posted on

The ISS Tested Vision Rehab in Orbit. Structural Biology's Bigger Problem Is Still Flat Screens.

The ISS Tested Vision Rehab in Orbit. Structural Biology's Bigger Problem Is Still Flat Screens.

In 2024, astronauts aboard the ISS began testing a vision-rehabilitation protocol designed for long-duration spaceflight. The experiment matters for a specific, unglamorous reason: in microgravity, roughly 70% of crew members develop Spaceflight-Associated Neuro-ocular Syndrome (SANS) — optic-disc edema, globe flattening, hyperopic shifts — likely driven by cephalad fluid shifts and elevated intracranial pressure. The protocol isn't a cure; it's a test of whether targeted visual stimulation plus tracking can slow or partially reverse neuro-ocular remodeling. Fine. Space medicine is a hard problem. But watching the coverage, I kept thinking about a different hard problem, one that lives much closer to the ground and rarely makes headlines: structural biology has spent three decades getting very good at generating data and very bad at letting humans actually see it.

I'm not an astronaut. I'm a computational biologist, or at least I was for six years before I switched to building tooling. Let me tell you about a Tuesday that broke me, because it's the honest reason I care about any of this.

It was late October, and the lab windows had that grey Seattle drizzle that makes every monitor look like it's glowing from inside a fish tank. I was trying to explain a conformational change in a membrane protein to a postdoc who had joined us three weeks earlier. On my screen: four docked windows, a PyMOL session, a ChimeraX session, a terminal tailing a 12 GB trajectory, and a browser with three tabs of literature. I was gesturing at a loop region on one structure and saying "so when the ligand binds, this moves here," except the "here" was in a different window and at a different orientation, and the postdoc was politely nodding while clearly lost. I remember the exact moment — my cursor hovered over a residue label that was clipped by a window edge — and I thought: this is absurd. We have cryo-EM maps at 2.1 Å resolution. We have MD trajectories that would've filled a Cray in 2004. And I'm explaining it with a hand-wave and a tiled desktop like it's 1998.

That night I went home and did what any stubborn engineer does: I started looking for the thing that should already exist.

What I found, eventually, was MolStar Studio — not a toy viewer, a full structural-biology workbench that runs in the browser and treats 3D as a first-class citizen instead of an afterthought. I'm not going to pretend it solved everything in one afternoon. It didn't. But it did three things that changed how I work, and I want to be precise about them because precision is the only thing that matters to this audience.

First, it renders real molecular scenes — not thumbnails, not static images, actual interactive 3D with proper lighting, ambient occlusion, and depth cues — directly in a browser tab. That sounds like a rendering detail. It isn't. When you can rotate a structure and the depth reads correctly, your visual cortex does the spatial reasoning for you. That loop I couldn't explain? The postdoc saw it in about ninety seconds once we could orbit it together on one screen.

Second, it's scriptable. The Mol* engine exposes a proper API, and the Studio layer lets you build reproducible scenes — representations, selections, camera states, annotations — as code. For someone coming from the scripting world of PyMOL .pml files and ChimeraX .cxc commands, this is the natural move: your figure is a script, your script is a git artifact, your colleague pulls it and sees exactly what you saw. No "which version of the session file did you send me." No silent drift.

Third — and this is the one I didn't expect to care about — it's shareable as a link. A scene is a URL. You paste it into Slack, into a grant application, into a reviewer response. The reviewer opens it in a browser and manipulates the actual structure. I've had reviewers who have never once replied to a supplementary figure PDF, and one of them replied to a Mol* link within a day. I don't have a controlled study for that. I have an anecdote and a raised eyebrow, which is the honest version.

Here's the engineering trade-off, because I want to be fair. Browser-based rendering is not free. You're paying for GPU-accelerated WebGL (or WebGPU where available), memory for the scene graph, and the cost of shipping geometry over the wire. For a 2.1 Å map with a few hundred thousand atoms, you'll notice. The Mol* team has done serious work on level-of-detail, instancing, and out-of-core handling of large structures — that's why it's used by the RCSB PDB and PDBe for their own viewers — but if you're trying to push a million-atom assembly through a laptop integrated GPU on hotel wifi, you will feel the wall. Native desktop tools still win on raw throughput for the heaviest MD playback. The right framing isn't "browser beats desktop." It's "the browser is finally good enough for 90% of what scientists actually do, and the remaining 10% is a much smaller slice than the community admits."

I'll give you the concrete thing, because this is a tech blog and you came for the concrete thing. In my current project — a small internal tool for annotating ligand-binding pockets across a family of homologs — we use Mol* as the viewer layer. A scene is defined by a small JSON spec: which structure, which selection, which representation, which camera. We generate that spec from our pipeline. The frontend is maybe 200 lines. We didn't build a renderer. We didn't build a selection language. We didn't build a camera model. We built the thing our lab actually needed, on top of a foundation that had already solved the parts we'd have botched. That's the trade: you give up some control and some peak performance, and in return you stop rebuilding molecular graphics from scratch every time a new project starts. If you've ever written your own OBJ loader for a lab tool, you know exactly what I mean.

The ISS vision experiment and this are not unrelated, even if they look it. Both are about humans operating inside environments that are hostile to human perception — one is microgravity wrecking your optic nerve, the other is a flat screen flattening a three-dimensional object into a two-dimensional puzzle. In both cases the fix isn't more data. It's better interfaces between the data and the person trying to think with it.

I'm not going to oversell this. I don't know if Mol* is the final answer. I don't know if browser rendering will ever fully replace native for the heaviest workloads. I do know that the Tuesday I described — the one where I couldn't explain a loop to a postdoc across four windows — hasn't repeated in the same way since. And I know that when I sent that postdoc a link last month, he opened it on his phone on the bus, rotated the pocket with his thumb, and texted back "oh, now I see it."

That's the whole thing, really. Not a benchmark. Not a headline. A person, on a bus, finally seeing the structure.

If you're tired of explaining three-dimensional molecules with two-dimensional tools, open MolStar Studio and build the scene you've been describing out loud. Your future postdoc will thank you.

Top comments (0)