Roadmap¶
GlyphViz isn't trying to be Matplotlib, Plotly, or ParaView — those tools already do 2D statistical charts and massive scientific pipelines better than GlyphViz ever will. GlyphViz is aimed at something more specific: the idea that a data hierarchy can be a navigable 3D space rather than a diagram of one — see Core Concepts. That's a narrower, stranger niche, and it's also mostly unoccupied. This page sketches where it's headed. None of it is a committed schedule — treat it as direction, not a promise.
Already underway¶
A browser-based renderer — live today. GlyphViz Web is a from-scratch WebGL rewrite (Three.js/TypeScript), not a stripped-down port, reading the same native gv_ scene format as desktop — and it's closed most of the gap: node creation and editing, selection, tags, Channels animation, color palettes, and cross-eye stereo 3D all already work in-browser. It exists to remove the biggest real barrier GlyphViz has had: installing anything at all. A URL you can open is worth more than a better renderer nobody launches — and it's also what's letting this documentation push get done faster, since a browser tab is a much easier thing to point someone at while writing about it than an installer.
VR in the browser — live today. The thing this section used to list as "near-term" has shipped: GlyphViz Web has a WebXR immersive mode. Open the URL in a headset's browser, press Enter VR, and you are standing in the scene — thumbstick flight, one-handed grab-drag and two-handed resize, controller-ray picking, in-scene billboard labels, a wrist-mounted control panel, and Channels playback. Confirmed on hardware on a Meta Quest 3; any WebXR-capable headset browser should work.
That answers the open question the roadmap used to pose. A headset can open a URL, and no app store, sideload, or PC-VR link stands between someone and a scene you send them — which is a categorically lower barrier than the alternative, so the browser is where immersive GlyphViz lives.
The earlier OpenXR spike (glyphviz_xr, built on the same glyphviz_core kernel as the desktop app) proved the model on a tethered Quest 3 and is where the interaction vocabulary was worked out — the flight speed, turn rate and grab behavior in the browser are ported from it directly. It stays an internal spike; it is not being developed toward a packaged release.
Near-term¶
Deeper in the headset. Immersive mode is v1. The agreed order from here: passthrough AR (immersive-ar, so a scene sits in your actual room — small now that the rig exists, and the demo that impresses people), then hand tracking, comfort options (snap turn, vignette), and authoring gestures — Draw Mode with a controller is the natural first one, since the drawing code already takes a ray. Rendering performance is the real ceiling: batching would lift both the headset and the flat browser app, and is its own project.
The AI-to-topology bridge. Right now, turning a CSV into a well-chosen GlyphViz scene means knowing the vocabulary yourself — which topology fits a hierarchy with strong community structure, when a Surface beats a Point cloud, how ratio and facet actually behave. That gap between "I have data" and "I have a scene" is exactly the kind of structure-to-suggestion mapping language models are already good at: describe your data, or point at a CSV, and get back a proposed topology/geometry encoding with the reasoning attached, not just a rendered image. Nothing here is built yet, but the shape of the tool is clear enough to name.
A stable, documented Python API. glyphviz_core already has everything a scripting API would expose — CSV I/O, the topology/placement math, the channel engine — but it's shaped for GlyphViz's own internal use, not for external callers to depend on. A published glyphviz_core API (and the pip install glyphviz / glyphviz CLI referenced in Installation) is real but deliberately low-priority: most people generating scenes today are far better served by the Claude Skill or by editing the CSV directly than by writing against a Python interface that would need to hold API-stability promises this project isn't ready to make yet.
The longer view¶
Some of the more speculative ideas in this space — data mapped to sound as well as sight, spatial encoding chosen by the meaning of the data rather than its shape alone — aren't purely hypothetical for GlyphViz specifically: the music-synesthesia examples already drive node position, color, and geometry directly from audio analysis, which is a working instance of exactly that idea in miniature. Extending that further — collaborative multi-user scenes, richer non-Euclidean topologies for data whose natural structure isn't well served by a sphere or a grid, genuinely 4D-and-beyond navigation — is where this heads if the nearer-term steps land. None of it is scheduled. It's the reason the nearer-term steps are worth doing.