ai a research survey assembled by Claude — not Ivan's prose.
Volume 01
The small, stubborn branch of the field that insists the visual primitive should be the actual code you can read — not a building, not a node, not a metaphor. Maybe six serious prototypes in fifteen years. Almost none open-sourced. This is the one that matters.
Most of "3D code visualization" — the whole CodeCity / IslandViz / ExplorViz tradition in Volume 02 — does not render code. It renders statistics about code, shaped like buildings. That is a legitimate, well-studied idea. It is not this idea. This volume collects the projects that pointed at a source file and said: render that, the real characters, and let me move through them in space.
The list is short, and it gets shorter once you require "and it shipped." Volume 06 collects the structural reasons for that. For now: the ancestry, in roughly the order it accreted.
Before anyone tried to do this in 3D, two ideas had to exist: that a thumbnail of source is itself navigable, and that you can compress a whole file to a column of colored lines and still find your way around. Both are 2D. Both are load-bearing.
Each line of source becomes one pixel-row, colored by some attribute — age, author, churn. A whole 50,000-line system fits on a screen as a stack of thin colored bars, and a "reading window" surfaces the real text under the cursor. It is the first time anyone treated "the entire codebase, laid out so you can see all of it at once, with the real text one gesture away" as a research goal. Every minimap you have ever used is a great-grandchild of this paper.
Shrink every source file to a legible-ish thumbnail, lay the thumbnails out in a stable spatial arrangement, and let programmers navigate by spatial memory rather than by filename. The finding — that people genuinely remember "the file with the funny-shaped block in the lower left" — is the cognitive premise underneath every spatial code tool that followed, including this one.
If thumbnails work, why have files at all? Put everything on one unbounded surface, zoom for detail, and let the layout be the index. This is the most commercially successful branch — it's the only one that ever shipped in a product you've heard of.
A single infinite pan-and-zoom plane holding every document in the project, each one editable in place, with semantic zoom (zoom out far enough and a file collapses to its outline; zoom out further and it's a labeled box) and translucent overlays for call graphs, search hits, debugger state. This is, conceptually, the closest thing in the literature to "the IDE as a map of itself." It was never shipped as Code Canvas — but the debugger-overlay half of it became Debugger Canvas for Visual Studio 2010 (now dead), and the spatial-outline half visibly informed VS's Code Map feature. The full vision sat in a four-page NIER paper for fifteen years.
Instead of files, working sets: drag a method into a "bubble" — a small, fully editable view of just that fragment — and arrange related bubbles spatially across a large pannable surface. The bubbles reflow, connect with lines, and persist as a named layout you can return to. It won a CHI best-paper honorable mention, got a working public prototype, and is the canonical citation for "real code, in unbounded space, arranged by hand." JetBrains shipped a Code Bubbles plugin; Microsoft's Debugger Canvas was built directly on the idea (ICSE 2011). The pure research line stopped there, but no spatial-code paper since fails to cite it.
A Google-Maps-style zoomable treemap of an entire codebase: directories nest as regions, files tile inside them, and at sufficient zoom each file shows its actual semantically-highlighted source. Pan around, follow cross-references, watch the whole repo's structure resolve into readable code as you descend. It is 2D and it is mostly forgotten, but in terms of fidelity at scale — real text, whole monorepo, smooth navigation — it is the nearest ancestor to what glyph3d-js does, just without the third dimension. Part of Padioleau's pfff static-analysis suite.
The Code-Bubbles idea, rebuilt on a modern VS Code fork: functions and classes appear as cards of real, editable source on an infinite canvas, with "go to definition" spawning the target card right next to the call site so a navigation trail becomes a spatial layout. 2D, chunk-granularity rather than whole-repo, and closed — but the most recent serious attempt to make "code as cards in space" a product programmers actually use.
A narrower Code-Bubbles cousin: source files tile into a horizontal "ribbon" you scroll along, so your reading history is preserved as a left-to-right strip rather than a stack of throwaway tabs. Worth knowing as a data point in the "spatial working set" family.
And then there's the branch that did go fully spatial — code on the walls of rooms, on the faces of cubes, on panels floating in a headset. This is the branch glyph3d-js's nearest sibling sits in, and the one where the "abandoned Unity thesis prototype" failure mode is most common. Note how few of these can be opened today.
This is the UCF project. Each class in a codebase becomes a 3D room. Its member variables and methods are laid out on the room's walls as syntax-aware "wallpaper" — real source, highlighted in the Visual Studio dark theme. You walk through it in first person. Roslyn parses real C# projects; you can edit, compile, and run from inside the environment. Pooya Khaloo's master's thesis under Joseph LaViola.
It is — almost beat for beat — a 2017 Unity ancestor of what glyph3d-js does: real source text, as the spatial primitive, walkable, at project scale. And it went exactly the way most of this list goes: a paper, a YouTube video, a 17 MB thesis PDF, and then nothing. No public repo. Khaloo went to industry. If you remembered "some students at UCF did this a few years back" — you remembered this, and you remembered it correctly.
A VR "house": rooms arranged inside a virtual cylinder, each room holding a module's actual source, with an integrated debugger so you can step through code while standing inside it. Same instinct as Code Park, in a headset, from a corporate research lab. It produced one paper and a demo video and then vanished — a recurring pattern you'll notice across this whole volume.
Augmented reality rather than VR: a HoloLens 2 places editable code panels in the physical room around you, paired with a normal JetBrains IDE running on a desktop — the AR space becomes "extra monitors that wrap around you" plus spatial anchoring for where things live. The Trier group has a small cluster of work in this neighborhood (see also CodeSparks below). No public binary surfaced.
Argues against the dominant approach — projecting a flat 2D editor onto a surface in VR — and builds a structured Smalltalk editor where you manipulate the program's syntax tree directly with your hands in 3D. The text is still there and still real, but the interaction is native to the medium rather than a port. Conceptually one of the more interesting members of this list; practically, a pilot study.
Pharo and Python source rendered on the faces of "code cubes" floating in infinite VR space — a full Smalltalk-style browser, inspector, and playground, plus Roassal graph visualizations, all reachable by reaching out and grabbing. The closest thing to an open-source, runnable, 3D, real-text code environment that exists. It's Unity, it's a one-developer thesis project, and it stopped in 2021 — but the repo is right there and it builds.
Parses code into an AST and lays it out as a 3D scene graph you walk through in VR, with language-server integration for the semantic layer. Ambitious stack — bespoke Rust/Vulkan renderer rather than a game engine — which is probably why it never quite finished. A Florida connection, if you're keeping score on the UCF memory, though it's CSU/FIU, not UCF.
The closest thing to a technical sibling. Primrose is a syntax-highlighting text editor that renders to an HTML5 Canvas and then textures that canvas onto arbitrary 3D objects in a WebVR scene — so you get real, editable, highlighted code on a curved panel, on a cube, wherever. It's the same family as glyph3d-js — rasterize highlighted glyphs, put them on a mesh — taking a different path: a full rasterized canvas blitted onto a quad, rather than GPU-instanced per-glyph quads. It's a single editor, not a repo-scale layout — but it's open, maintained, browser-loadable, and it's the one library in this whole survey you could actually npm install and build on.
A JavaScript editor pane positioned in 3D space with a live three.js sketch running beside it — change the code, the world changes, in the headset. Tiny in scope, but it's the demo that put "edit real code while standing in your scene" in front of a lot of people in 2014, and it got a WebXR rewrite a decade later.
One more shape: don't move the code into space — bring the space into the code. Inlay visualizations directly into the editor, at the line they describe.
An IntelliJ framework for rendering small glyph-based visualizations inlaid into the actual source code — profiler heat, test coverage, complexity, whatever — so the visualization lives at the line it's about rather than in a separate panel. Not spatial in the 3D sense, but it belongs here because it shares the core conviction: the real text is the canvas, and you decorate that, you don't replace it with an abstraction. Closest in approach to glyph3d-js's highlight and overlay layer, in 2D.
Fair question, and one this volume should answer honestly rather than hand-wave. The evidence base is small but it exists, and it is genuinely mixed — which is useful, not damning.
The closest thing to a real answer. Programmers can comprehend code displayed in immersive 3D — accuracy held up — but the study also found higher cognitive load in the VR condition than on a plain desktop. The honest reading: 3D doesn't automatically help, and a naive "the 2D IDE but bigger and in a headset" makes things worse. The interesting design space is the part that isn't a port — spatial layout that earns its keep, not novelty for its own sake. It's the closest the field has to a controlled answer here, and the most-cited empirical reference under the rest of this volume — useful in both directions: it supports the "this can work" reading and the "a naive port makes it worse" one.
Not about code, but load-bearing for anyone who wants to: it establishes how fast people read, and how comfortably, with text at various positions in a head-mounted display. The short version is "slower and more tiring than a monitor," which is exactly why the screen-based, look-around-don't-strap-in approach glyph3d-js takes is a reasonable hedge — you keep the spatial layout and skip the headset tax.
Belongs to the city tradition — buildings, not text — but worth a line here because it's one of the few rigorous "VR vs. flat screen" comparisons in software visualization, and it found VR faster at comparable accuracy for the city-navigation task. Useful as a counterweight to the Clemson result: the answer to "does 3D help?" really is "depends what you're doing in it."
The far edge of the idea: source code (in Realtalk, a Lua dialect) is physically printed on sheets of paper and pinned to walls and tables; ceiling-mounted cameras and projectors make the room itself the computer, and the code's spatial arrangement is the program's structure. Not something you can load up, and not trying to be — but it's the purest statement of "the layout is the index, the text is the substance" that exists, and it's worth knowing as the philosophical extreme of the line glyph3d-js sits on.
Where this volume lands. Real source text as the spatial primitive, at codebase scale: roughly six research prototypes since 2005 — Code Canvas, Code Bubbles, Code Park, CodeHouse, IDEvelopAR, HPI's VR-Native. None are open, maintained, and openable today. Add the runnable-but-dormant tier — VRIDE, code-vr, Primrose, Codemap/pfff — and nothing is GPU-instanced, repo-scale, browser-loadable, and alive at once.
→ Volume 02: the much larger branch that sidestepped the rendering problem by drawing buildings. Volume 06: what that leaves open, and what occupies it.
Continue → 02 · The City Tradition