Where the Third Dimension Earns Its Keep

Three Tests Before You Build Anything in 3D

Every example below survives three tests. We apply them before quoting for any 3D work, because a failed test at this stage costs a conversation, while a failed test after launch costs a rebuild. Run your own candidate through them first.

The first two tests are about the data and the job. The third is the one that kills most 3D proposals, and the one worth being strictest about.

A candidate that fails a test should become a 2D chart, and that's a fine outcome. Our data visualisation guide covers that territory: chart selection, data storytelling, and the mistakes that make business charts misleading. What follows is the territory 2D cannot reach, grouped from the strongest case for 3D down to the most situational.

Twelve 3D Data Visualisation Examples at a Glance

Four groups, in descending order of confidence. When the space is real, 3D is close to mandatory. When the argument rests on three trading-off measures or a dense network, 3D has to prove itself against a well-made flat alternative before anyone writes code.

Each of these runs in an ordinary browser tab. Nothing needs installing, and every view can sit beside the reports your team already opens.

When the Space Is Real: Operations You Can Walk Through

The strongest case for 3D is data attached to a place that physically exists. Your systems already store the coordinates: every warehouse management system knows aisle, bay and level, every planogram knows shelf position, every building management system knows which floor a sensor sits on. Flattening that data throws away a dimension your team walks through every day.

1. Warehouse racking and pick-path analysis

A pick report tells you what moved. It does not tell you that your five fastest movers live on level 4, or that half of every picker's shift is spent walking past dead stock parked at waist height in the golden zone. Colour every bin by picks over the last four weeks and the misplacements are visible from across the room: red bins up high where every pick needs a reach truck, grey bins hogging the easiest positions in the building.

The action is a re-slotting plan, and the payback is measured in picker-hours. Vertical travel cost (ladder picks, reach-truck queues) never appears in a flat heatmap of the floor plan, because the floor plan has no height. The data comes straight out of the WMS: bin coordinates, pick timestamps, stock age.

The rendering side is one InstancedMesh, whatever the size of the shed. Eight thousand bins is one draw call:

// One InstancedMesh for the whole racking layout. Aisle, bay and
// level come straight from the WMS; colour encodes 28-day picks.
const binGeometry = new THREE.BoxGeometry(1.1, 0.9, 1.2);
const bins = new THREE.InstancedMesh(
  binGeometry, new THREE.MeshLambertMaterial(), wmsBins.length
);

const slot = new THREE.Object3D();
const colour = new THREE.Color();

wmsBins.forEach((bin, i) => {
  slot.position.set(bin.aisle * 3.0, bin.level * 1.2, bin.bay * 1.4);
  slot.updateMatrix();
  bins.setMatrixAt(i, slot.matrix);

  // 0 picks = green, 120+ picks = red. Height does the rest of
  // the talking, which keeps the view readable for colour-blind users.
  const heat = Math.min(1, bin.picks28d / 120);
  colour.setHSL(0.33 - 0.33 * heat, 0.7, 0.5);
  bins.setColorAt(i, colour);
});

bins.instanceColor.needsUpdate = true;
scene.add(bins);

2. Container and vehicle load planning

Freight is priced by space as much as weight, and wasted cube is invisible in a manifest. Render each consignment as boxes inside the actual trailer or container and utilisation stops being an abstract percentage: the empty half-metre above the third pallet layer is right there on screen. Colour the boxes by drop sequence and the loading team can see that the last delivery of the day is buried behind the first.

Teams that review load plans this way argue about facts instead of recollections. The results are fewer vehicles moving the same volume, cleaner load orders, and a training aid for new loaders that no spreadsheet can match. The inputs are already in the ERP: carton and pallet dimensions, weights, delivery sequence.

3. Shelf and store layout analytics

Retail reporting is organised by product. The commercial questions are about position: eye level or ankle level, gondola end or back wall. Drape sales per facing over a model of the actual fixtures and shelf height becomes a visible variable, which matters because eye-level facings outsell bottom shelves by multiples, and planograms drift the moment head office stops looking.

Add footfall counts per zone and the dead aisle nobody walks down shows up as a cold stripe through the store. The actions are planogram corrections and layout moves, and the same view a month later tells you whether they worked.

4. Buildings, energy and occupancy

A multi-storey building reported as one monthly kWh figure hides everything useful. Stack the floor plates, colour each room by energy use, temperature or occupancy, and the anomalies surface on their own: the meeting room heated all weekend, the server cupboard fighting the air conditioning next door, an entire floor lit for the four people who come in on Fridays.

Facilities teams act on this directly with schedule changes in the building management system and zoning fixes. Owners act on it more bluntly: occupancy data draped over real floors makes an honest case for giving up space that nobody uses.

5. Factory floors and work-in-progress

Machine utilisation reports average away the story. Lay machine status onto the actual floor layout and let work-in-progress stack up visually between stations, and the bottleneck identifies itself: a growing pile of pallets in front of one cell. The spatial view also reveals what no report can, such as the two busiest stations in the process sitting at opposite ends of the building.

This is the natural entry point to a digital twin. Start with status colours on a floor plan fed from the machines you already monitor, and add live sensor detail once the basic view has proved its worth on real decisions.

Geography With Magnitude

Flat maps handle location well and magnitude badly. Colour-shaded regions compress differences, so a territory earning twice as much looks only slightly darker. Sized circles overlap in exactly the busy areas you care about most. Extruding values upward from the map turns distribution into a skyline, and skylines read at a glance.

6. Regional revenue and delivery density

Render revenue, order count or delivery density as columns over your actual trading area and concentration becomes obvious: the three postcodes quietly carrying a territory, the town with plenty of drops and hardly any margin. Rotating the view compares near against far without a legend getting in the way.

The decisions are territory design and depot placement. The deeper engineering, projections, map tiles and terrain, is covered on our geospatial and globe visualisation page.

// Revenue columns over a map plane. Height carries the message;
// exact figures belong in the side panel, not in the geometry.
const columnGeometry = new THREE.CylinderGeometry(0.5, 0.5, 1, 12);
columnGeometry.translate(0, 0.5, 0); // grow upward from the map

const columns = new THREE.InstancedMesh(
  columnGeometry, columnMaterial, regions.length
);

const column = new THREE.Object3D();

regions.forEach((region, i) => {
  const [x, z] = projectToMap(region.lat, region.lng);
  column.position.set(x, 0, z);
  // scaleSqrt keeps big territories from flattening small ones
  column.scale.set(1, revenueScale(region.revenue), 1);
  column.updateMatrix();
  columns.setMatrixAt(i, column.matrix);
});

7. Routes, corridors and consolidation

Draw a month of delivery routes as arcs between depots and drops, with thickness for volume, and the duplication appears: two vans from different depots serving the same street, a corridor busy enough to justify a direct run. A flat route map draws the same lines, but they merge into a single smear exactly where traffic is heaviest. Arcs at different heights keep overlapping routes separate.

The action is consolidation: merged runs, moved boundaries, and sometimes the case for or against a new depot argued from the shape of real demand rather than a hunch.

Three Measures That Trade Off

Some decisions genuinely hang on three numbers at once, and any pair of them misleads. This is the group where 3D scatter plots and surfaces earn their reputation honestly, on one condition: every axis stays plain. Each one is a figure from your own database with a name your team already uses. No composite scores, no algorithmic clusters, nothing that needs a glossary.

8. Customer drift: recency, frequency and spend

Plot every customer by how recently they bought, how often they buy and how much they spend, and the cloud has corners with business names: the loyal heart of the book, the one-off bargain hunters, and most valuably the drifting middle: customers who used to order monthly and have quietly gone bimonthly. On any flat pair of these axes the drifters hide inside healthier groups; the third axis is what separates them.

The view must end in a list. Brush the drifting region, export the customers inside it, and hand the win-back call sheet to the account team. That final step separates a working tool from a screensaver.

9. Product portfolio: price, volume and margin

Every catalogue has a busy-fools corner: products selling in volume at thin margin while eating warehouse space and picking time. It also has quiet earners nobody promotes. Plot price against volume against margin and both corners appear in seconds, along with the pricing outliers that survived three years of copy-and-paste price lists.

The actions are price reviews and range rationalisation, and the same view answers the follow-up question a quarter later: whether the corner has emptied out.

10. The seasonality surface: week, weekday and sales

Fifty-two weeks by seven weekdays is 364 numbers with structure in both directions. As overlaid line charts it turns to mush past a dozen series. As a surface it is a landscape: ridges are promotions and Christmas, and a valley cutting across an otherwise busy week is usually a stockout, rendered as exactly what it is: missing sales.

Demand planners and rota builders read the landscape directly, because the shape that shows when sales peak is the same shape that shows when the warehouse needs overtime booked.

// 52 weeks x 7 weekdays of sales as a displaced plane.
const surface = new THREE.PlaneGeometry(52, 7, 51, 6);
surface.rotateX(-Math.PI / 2); // lay it flat, sales become height

const positions = surface.attributes.position;
for (let i = 0; i < positions.count; i++) {
  const week = i % 52;
  const day = Math.floor(i / 52);
  positions.setY(i, salesScale(sales[week][day]));
}
surface.computeVertexNormals(); // so the lighting reads the ridges

Networks Too Dense to Stay Flat

This is the most situational group, so it deserves the most honesty: a well-laid-out 2D network diagram beats a 3D one up to a few hundred connections, and when it does, we build the flat version. Past that point flat layouts collapse into hairballs, while a 3D layout under rotation keeps clusters separated, because depth gives crossing edges somewhere to go.

11. Supplier and dependency risk

Map products to components to suppliers and the single points of failure stand out as heavily connected nodes: one fastener supplier feeding forty product lines, a courier that every despatch route quietly depends on. These structural risks hide in spreadsheets because each row shows one relationship at a time, and the danger lives in the pattern.

The action is a dual-sourcing priority list, ranked by how much of the catalogue goes dark if a single node fails.

12. Systems and integration maps

Businesses accumulate software the way lofts accumulate boxes, and nobody holds the full wiring diagram in their head. Render every system and every data flow between them, then pick one system and watch its dependents light up. Blast radius becomes a picture, and conversations about replacing a legacy system change once the risk stops being abstract.

The engineering behind large graphs, force-directed layouts in Web Workers, instanced nodes, edge bundling, lives on our network graph visualisation page. Untangling the estate itself is systems integration work.

Where 3D Data Visualisation Is the Wrong Call

The fastest way to lose a team's trust in a 3D project is to build one that should have been a bar chart. Every example above works because the third dimension carries information. When it carries nothing, it charges a toll in navigation effort and reading accuracy and pays nothing back.

Those two are about speed. The next two are about precision and portability, which a 3D scene gives up by design.

None of these get better with a stronger GPU or a nicer camera path. They are the wrong shape of question for a scene.

What These Take to Build

The pleasant surprise in most of these projects is the data. Nothing above needs new instrumentation. Bin coordinates live in the WMS, product dimensions in the ERP, floor plans in a drawing file, delivery points in the order book. The work is plumbing existing records into a scene, not surveying the building.

• ✓
  Runs in the browser Three.js renders in every modern browser on ordinary hardware. No installs, no per-seat licences, and it sits beside the dashboards your team already uses.
• ✓
  Backed by flat views Every 3D view we build is paired with a table or 2D detail chart. The scene finds the question, the table answers it precisely, and the table is what exports and screen readers use.
• ✓
  Honest at real volumes Instanced rendering, GPU picking and streaming updates keep tens of thousands of interactive elements smooth on a mid-range laptop.

The engineering behind that last point lives on the sibling pages in this section: 3D data visualisation patterns for rendering architecture and picking, performance and optimisation for frame budgets and memory, and accessibility in 3D interfaces for keyboard navigation and alternative representations. If the data needs to move live, real-time dashboards covers the transport layer.

The groups above also combine as an operation matures. A warehouse view that starts as a re-slotting tool grows a live feed and becomes a working twin of the building. Regional columns gain route arcs when depot planning starts in earnest, and the customer cloud earns a time slider once the first win-back campaign proves the drifters were real.

A sensible first project is small, and it looks the same whichever use case you start with.