AI Supply Chain in 3D

Almost every map of the AI supply chain is a static tree or a table, and a tree can only express containment. You can see that HBM belongs to memory and memory belongs to chips — but not which downstream links go dark when HBM supply is cut off.

The real information in a supply chain is flow: who feeds whom. This project models that explicitly as a directed graph, which buys you two things a tree can’t do — click any link and traverse both directions to light up its entire supply chain (HBM lights 41 nodes, CoWoS lights 56), and lay the graph out along the actual process order rather than a classification hierarchy, so you can see where in the chain a bottleneck actually sits.

What’s in the graph

153 nodes and 239 edges. 144 of those nodes are main-chain links laid out along the X axis in real process order across twelve stages, from materials and equipment through wafer fab all the way to applications and end-user hardware. Nine more are cross-cutting factors — export controls, compute financing, regulatory filing, AI liability insurance — that sit off the main chain, floating below it and connected by dashed lines to whatever they affect.

Eighteen links are flagged as current bottlenecks: lithography, hybrid bonders, HBM, CoWoS, substrates, optical modules, gas turbines, grid connection permits, inference engines. Twenty are flagged as domestic-substitution priorities, and 115 carry representative companies.

One thing deliberately doesn’t follow the source data: depth in the tree is not position in the chain. In the original outline, “power” and “EDA” are both upstream — but on a flow graph one feeds data centres and the other feeds chip design, and they belong nowhere near each other. So stage position is hand-assigned business semantics, not graph-theoretic topological depth.

Interaction

• The sidebar and the 3D view drive each other. Click a list entry and the camera flies to that node and selects it; click a node in the graph and the list scrolls to it, marking upstream orange and downstream green.
• Clicking a node scales it up, bursts its representative companies out as an orbiting satellite ring, runs a bidirectional BFS to light the full chain while dimming everything else, and fills a side panel with upstream dependencies, downstream destinations (each clickable in turn), representative players and bottleneck flags.
• The satellite ring is built on the camera plane, so no amount of rotation lets another node occlude it.
• Bottleneck links pulse continuously. You can filter to bottlenecks only or substitution targets only. Reset clears every bit of state and returns all 153 nodes to their exact starting coordinates.
• On entry the nodes start as a scattered nebula and the force simulation converges them into place while you watch.

How it’s built

three.js r160 and 3d-force-graph 1.73.4, plus a hand-written CSS2D label layer. The whole thing inlines into one 1.39 MB HTML file with zero external requests — double-click and it runs.

The layout is not pure force-directed. Force layouts don’t express order, so nodes within a stage scatter at random and edges cross back and forth. This uses barycenter ordering from layered graph drawing: each stage is a layer group, iterated 40 times, each pass pulling a node’s vertical rank toward the mean of its neighbours’ actual Y coordinates before re-sorting the slots. Edge crossings dropped from 479 to 192 (−60%) and mean vertical span from 82 to 55 (−33%). After that the force field only prevents overlap and adds a little organic motion — it no longer drags the ordering apart.

Overlap has to be judged in screen space. Collision against the core radius is a lie: the glow you actually see has 2.25× the core’s radius, so two cores that don’t touch are already smeared together. Switching to visual radius got world space to zero overlap — and 93 intersecting pairs remained on screen, because a separation vector pointing straight at the camera collapses to a point under projection. The fix is three-layered: the collision force only computes the component perpendicular to the view direction, each stage is arranged as a row-column grid whose springs target the node’s own column rather than the stage centre, and adjacent columns are offset by half a row in Y. Fully intersecting pairs went from 93 to 1 (and that one is tangent); more-than-half overlaps from 54 to 0.

Labels use greedy de-overlap, not a distance threshold. The reference implementation’s absolute distance cutoff works on a compact spherical layout, but this chain is 2,300 units long and every node sits between 1,886 and 2,385 from the camera — a threshold of 1,750 shows zero labels and 2,100 jumps straight to 110, with nothing usable in between. Instead labels are placed greedily in priority order (selected > on the lit path > importance > nearest camera), and any rectangle that intersects an already-placed one yields.

The deepest hole I dug

Early on, when the scene was small, I added one line of fog. It looked good. Later, to frame the entire chain, the camera pulled back to 1957 — which put the fog interpolation at 0.66, meaning two-thirds of every node’s colour was replaced with background black and only a third survived. No amount of palette tuning, adding a bright core, or reworking the glow falloff helped, because a layer multiplying everything by 0.34 sat on top of it all.

What found it was giving up on eyeballs and reading the framebuffer with gl.readPixels. The brightest pixel on the canvas was (96,111,97) as-is; solid cores only, no change; depth test off, no change; transparency off, no change; scene.fog = null and it jumped to (233,245,255). Four experiments that changed nothing rule out materials, draw order and depth testing — and the arithmetic agrees: node colour 251 × 0.34 ≈ 85, against a measured 96–111.

The lesson: measure pixels before touching parameters. I’d spent three or four rounds tuning materials, every one of them in the wrong direction.