3D Data Visualization

Four cases where the third dimension carries real information:

• Networks and graphs. Nodes with dense interconnection have no good 2D layout past a few hundred edges; everything crosses everything. In 3D a force-directed layout has somewhere to put the tangle, and rotation reveals clusters that overlap from any single angle.
• Spatial and volumetric data. Anything measured through a physical thing: geology, medical scans, airflow, a building's sensor readings. The data already has three axes. Flattening it throws one away.
• Simulations and time-varying fields. Particle systems, fluid, orbital mechanics, agent models. The state is the visualisation.
• Very large point sets. Above roughly a hundred thousand marks, SVG stops being viable and the GPU is the only thing that will draw it interactively. This is a rendering argument rather than a dimensional one, and it is often the real reason a project needs WebGL.

Cases where a flat chart wins, which is most of them:

• Comparing quantities across categories. A 3D bar chart makes comparison harder, because perspective means two bars of the same height do not look the same height.
• Trends over time. A line chart is already optimal.
• Anything going into a report, a slide or a print. Static beats interactive when the reader cannot interact.
• Anything where the audience needs to read exact values. Depth makes precise reading worse, not better.

I would rather lose the project at this stage than build something that makes your data harder to understand.

The whole discipline is about not issuing a draw call per data point.

Instancing. One geometry, one material, uploaded once, drawn many times with a per-instance matrix and colour. A hundred thousand cubes cost roughly one draw call rather than a hundred thousand. In Three.js this is InstancedMesh, and it is the single technique that makes browser data visualization possible.

Attribute-driven geometry. Above a few hundred thousand marks even instancing strains, and the data moves into buffer attributes read directly by the vertex shader. The position of a point becomes a value in a texture rather than an object in JavaScript. At that point the visualisation is a shader and the data is its input.

Picking. Making a rendered point clickable is not free, because the GPU has drawn pixels rather than objects. The usual answer is a second render pass into an off-screen buffer where each mark is drawn in a unique colour, then reading a single pixel under the cursor to identify it. It is a well-understood trick and it needs planning for, because it doubles the draw work if implemented carelessly.

Where the data lives. The interesting constraint is rarely rendering, it is transfer. A million rows of JSON is tens of megabytes and blocks the main thread while it parses. Binary formats, typed arrays, aggregation on the server, and streaming in chunks are what make the difference between a two-second load and a thirty-second freeze.

Drawing the data is the easy half. Making it readable is the half that decides whether anyone uses it.

Text in a 3D scene has no good default. Rendered as geometry it costs draw calls and looks wrong at distance; rendered as HTML overlays it is crisp and accessible but needs projecting and occlusion-testing every frame; rendered into a texture atlas it is fast and fixed-resolution. Each is right sometimes and there is no option that is right always.

Then the ordinary problems arrive. Axes need to stay oriented as the camera moves. A legend has to be readable against a scene whose background colour changes as you orbit. Labels collide, and something has to decide which one wins. Depth cueing — fog, size falloff, desaturation with distance — is what stops a point cloud reading as noise.

None of this is visible in a screenshot, which is why so many 3D visualisations look wonderful in a case study and are unusable in practice.

Three things drive the number:

1. The state of the data. A clean API returning aggregated JSON is a different project from a 4 GB CSV export that needs a pipeline built before anything can be drawn. This is the biggest variable and the one most often underestimated.
2. Interaction depth. Rotate and zoom is cheap. Filtering, brushing, linked selection between views, drilling into a point and pulling its record from an API — each of those is a feature with its own state to manage.
3. How many people need to read it, and how carefully. An internal exploratory tool for five analysts can be rough. A public-facing visualisation that has to be legible, accessible and correct on a phone is a different standard of finish.

The cost that surprises people is the data pipeline. On a typical project the rendering is a minority of the work and the ingestion, aggregation and transfer layer is the majority.

Three.js is the base: instancing, custom shader materials, and a scene graph that handles the camera and interaction so the project is about the data rather than about matrix maths.

WebGPU matters more here than on most 3D work, because of compute shaders. A force-directed graph layout, a particle simulation, or an aggregation over a large buffer can run on the GPU instead of the main thread, which is the difference between a layout that settles in a second and one that locks the tab for thirty. Three.js reaches this through its node system and TSL. I still build WebGL as the fallback path, usually with a smaller dataset or a precomputed layout for browsers without WebGPU.

For flat charts inside the same interface, D3 remains the right tool and the two coexist happily — SVG for the axes and the small multiples, a canvas for the part that needs the GPU.

Radix 3D is an interactive 3D network graph built with React Three Fiber. It loads live JSON and re-renders the full node and edge graph every three seconds.

That last detail is the interesting one. A graph that redraws continuously cannot rebuild its scene from scratch each cycle, because allocating and disposing geometry at that rate produces exactly the stutter the visualisation exists to avoid. The work is in updating instance buffers in place, keeping the layout stable so nodes do not jump between frames, and keeping interaction responsive while the data underneath keeps changing.

You can try it — it is linked from the work section below.

3D chosen for the screenshot. The commonest failure and the most expensive. If the brief starts from wanting something that looks impressive in a deck, the result is a chart that is harder to read than the one it replaced.

No aggregation strategy. Sending every row to the browser because the dataset "is not that big yet". It will be. Decide early what the server aggregates and what the client draws.

Colour used carelessly. A rainbow ramp is the classic error: it implies category boundaries that are not in the data and it fails completely for the ~8% of men with a colour vision deficiency. Perceptually uniform scales exist for a reason.

No empty and loading states. Real data arrives late, arrives partial, or fails. A visualisation that only handles the happy path is a demo.

Interaction without affordance. A scene the user can rotate, with nothing indicating that. People stare at a still image and leave.

Ignoring the flat version. Even a good 3D visualisation usually needs a 2D companion — a table, a filter panel, an export — because at some point someone needs the actual numbers.