Brix is a UI concept for an orange juice line, built in three.js. It runs a simulated shift you can scrub through, cuts any machine open like a drawing, and keeps the tables a plant team works in beside the 3D, reading the same numbers.
Can a 3D view of a running plant share one screen with the tables its team already works in, without the two ever disagreeing?
A simulated shift. Best on a laptop or bigger.
Brix is an orange juice factory you can open in a browser tab. Fourteen stations run from the weighbridge where the fruit trucks come in to the dock where the pallets leave, and a shift is running on all of them: oranges on the belts, juice in the pipes, a robot stacking packs, forklifts putting pallets away. Press Run the line above, or open it full screen, which is the size it was made for.
Screens for a plant tend to come in two kinds. One is a 3D model of the place, which shows where everything is and is lovely in a demo. The other is the screens the plant runs on: tables of truck receipts, tank movements, lots and pallets, where the work gets done and nothing is drawn. Brix puts both on one screen, and both read from the same numbers.
It is a UI concept. No plant stands behind it and no data comes in from one. The shift is simulated, the growers and customers are made up, and every number in it is a sample.
Everything in Brix comes from one model of a shift, worked out minute by minute when the page loads. Twenty tonnes an hour of Valencia oranges go through four extractors, which gives about 9,800 litres of juice an hour into storage tanks. Blend tanks take turns feeding a pasteurizer and a filler rated at 12,000 one-litre bottles an hour. Trucks arrive on a schedule, tanks fill and drain, the lab releases blends, and pallets go out on trailers.
The interface keeps no numbers of its own. The dot over a machine, the reading inside it, a row in a table and the bottle count at the bottom of the screen all ask the model for the same thing at the same shift time. Because the whole shift exists before you look at it, the timeline can jump to any minute and everything on screen still agrees. Drag it back an hour and the tanks are at their old levels, and every pallet made since has left the warehouse table.
Three things go wrong during the shift, each a different kind of trouble. A gasket on the pipe rack lets go, and the only sign is juice that leaves the extractors and never reaches the finisher. A bottle falls over at the filler's infeed, and the stop runs both ways: the blow molder backs up behind it, and the labeler, packer and robot run dry one after another. The pasteurizer's steam valve sticks shut, and juice comes out of it below its safe temperature. Each plays out on a fixed script from the minute it starts, so it looks the same live, scrubbed or replayed.
Pick a machine and it opens the way a section opens on an engineering drawing. A plane slices through the casing, the half nearest you goes, and the walls the plane passes through are filled with a hatch. Inside, numbered pins walk through what the machine does, and round instrument tags show the live readings where the sensors would sit.
Cutting the shape is the easy half. three.js can clip any material against a plane, and nothing on the far side of it is drawn. What that leaves is a shell with no walls: through the cut you see the inside of the far side, and the edge nearest you is a line with no thickness. It reads as a broken model.
Filling the cut uses the stencil buffer, a hidden layer that keeps a whole number for every pixel on the screen. Picture the line from your eye through one pixel, starting where it meets the plane and running on into the scene. If that starting point is in open air, the line goes into the casing and comes out of it the same number of times, so it crosses as many surfaces facing you as facing away. If the point is inside a wall, the line has to leave the wall before anything else, so it crosses one more surface facing away. The difference is zero in the air and one in the wall.
So each casing is drawn twice more, invisibly, clipped by the same plane, with depth testing off so that every surface along the line is counted. Surfaces facing away add one to their pixels; surfaces facing you take one away. A flat square lying on the plane then draws its hatch only where the count is not zero, which is the wall, and puts the count back to zero as it draws, so the next machine's cut starts clean. This is the method in three.js's own clipping example, and the sample below is it cut down to its parts.
import * as THREE from "three";
// What stays is the side the normal points to.
const plane = new THREE.Plane(new THREE.Vector3(0, 0, -1), 0);
function countingPass(side: THREE.Side, op: THREE.StencilOp) {
return new THREE.MeshBasicMaterial({
side,
clippingPlanes: [plane],
colorWrite: false, // draws nothing you can see
depthWrite: false,
depthTest: false, // counts every surface along the line
stencilWrite: true,
stencilFunc: THREE.AlwaysStencilFunc,
stencilFail: op,
stencilZFail: op,
stencilZPass: op,
});
}
// Surfaces facing away add one; surfaces facing you take one away.
const away = countingPass(THREE.BackSide, THREE.IncrementWrapStencilOp);
const toward = countingPass(THREE.FrontSide, THREE.DecrementWrapStencilOp);
// The square on the plane: hatch where the count isn't zero, then reset it.
// Brix draws a hatch here with a small shader; a flat colour shows the idea.
const cap = new THREE.MeshBasicMaterial({
color: 0x4ea7fc,
stencilWrite: true,
stencilRef: 0,
stencilFunc: THREE.NotEqualStencilFunc,
stencilFail: THREE.ReplaceStencilOp,
stencilZFail: THREE.ReplaceStencilOp,
stencilZPass: THREE.ReplaceStencilOp,
});The two counting passes and the cap go on the casing's meshes and the square,
with render orders that draw them in that sequence, and the renderer needs
localClippingEnabled switched on and a context created with a stencil
buffer.
The cost is in the modelling. The count only comes out right when every casing is a closed solid, an outer skin and an inner skin a wall's thickness apart, with no gap anywhere along the cut. So the tanks, the extractors and the pasteurizer are all built that way, in code, along with the rest of the plant. Brix loads no model files and no textures. The surfaces, from the epoxy floor and the brushed steel to the pine of the pallets, are painted by a worker thread when the page opens, as near-white detail that each material tints with its own colour.
Thousands of oranges go through the plant during a shift, and none of them is anyone in particular. Follow one orange picks one off a truck and keeps the camera on it until it leaves on another.
The ride is a script of beats, and each beat moves the orange along a path the plant already uses, on the same clock as everything else: the belt the other fruit is riding, the pipes, the robot, the forklifts. Where the orange would only be waiting, in a bin with 28 tonnes of other fruit or in a tank while the lab checks the blend, the shift clock jumps ahead and the screen says by how much.
Once it is squeezed there is nothing left to see, because from the extractor on the juice is never in the open. So its share, about 90 millilitres, is drawn through the steel as an orange slug, the way a tracer shows up on an X-ray, and the camera follows it into a tank, through the pasteurizer and over to the filler. After that it is a bottle, one of six in a pack, one of 105 packs on a pallet, and one of 33 pallets on a trailer.
The panel in the middle is the orange's record, and it fills in as the ride goes: picked at an orchard, tipped from a truck that carried 19.6 tonnes at 12.1 °Brix, squeezed in cup 3 of extractor EX-402, then screened, spun, stripped of air, stored and blended. Juice mixes in a tank, so from storage on the record can only say which tank, and in what window of time. Every line in it is read off the same shift model as the plant around it.
The 3D view shows where things are. Counting them, sorting them and finding the one with a problem still happens in a table, so Brix keeps the tables.
Each stage of the line has one: truck receipts, the extraction log, tank movements, the pasteurizer's log, filling lots, pallets. Beside them sit the records the line exists to serve, customer orders, work orders and the lab's batch results. They open as a sheet along the bottom of the screen, under the plant or over all of it.
A row exists only once the thing it records has happened, so the tables move with the timeline too. Point at a row and the plant shows you where it is. Open it and the record sits beside the table, with a button to find it in 3D and another to rewind the shift to the minute it was made. A pallet traces back through its filling lots to the blend, and from the blend to the trucks of fruit that went into it.
People can add to the records as well: book a truck, log a hand reading at the pasteurizer, take an order, plan a work order, put a lot or a pallet on hold. Each of these shows a notice with an undo, except the pasteurizer reading, which is a food-safety record and stays once it is written.
Every drop of juice has to reach 92 °C and stay there for 30 seconds before it can go near a bottle. A thermometer at the end of the holding tube checks it, and under 90 °C a valve sends the juice back round instead of on to the filler. In food-safety terms that is a critical control point, and the pasteurizer is the line's first.
When the steam valve sticks, the temperature falls through that limit, the valve starts sending juice back, and the filler runs out of juice to fill. The alarms follow ISA-18.2, the standard for alarm management in the process industries: raised, acknowledged, back to normal. Each priority has a shape as well as a colour, so it still reads without the colour.
The question anyone on that shift would ask is whether the juice going into bottles is safe, and Ask the line takes it in those words. It answers the way an operator would find out. It opens the pasteurizer, reads the thermometer at the outlet, checks the shift against the limit, and writes its answer from the numbers at that moment, with links to the readings it used.
There is no language model in it. Each question Ask knows is a short script of those steps, and only the wording around the numbers is written ahead of time; the numbers come from the shift when you ask. It knows a handful of questions, about the stops, the pasteurizer, where a bottle came from and whether the plan will be met, and asked anything else it lists those.
The first versions of Brix had the panels a control room screen is expected to have: a bar across the top, a column of tools, a minimap, a strip of stages along the bottom and a panel down the right. Next to the plant they were a lot of words, and the layout sat too close to the reference concepts I had started from.
I mocked up three layouts over real renders and chose the one that keeps the least on screen. The plant now takes the whole window, and the interface is one object at the bottom of it, which I call the island. At rest it says one thing, bottles made against the day's plan. Point at it and it opens into the controls: the timeline, play and speed, the line's state, the six stages, the tables, Ask, and a menu for the rest. Pick a machine or a record and it grows into a card; open the tables and it becomes the sheet. It is the same object changing shape each time, so nothing you were looking at moves somewhere you have to look for it. Alerts dock on top of it, whatever shape it is in.
Over the line each machine is a dot in its state's colour, and pointing at one opens its name and its live number. Colour is kept for things that mean something. Orange is juice, blue is the cut and the safety checks, and green, yellow and red are machine states. The rest is graphite greys and hairlines in the manner of Raycast and Linear. Two earlier looks, a light control-room grey and a navy with glowing orange, were both dropped on the way.
The island's first motion took 520 milliseconds with a 4% overshoot, and switching the sheet between half and full screen felt slow and glitchy. It now grows in 380 milliseconds on a spring that overshoots by about 1.5%, shrinks in 260 with none, and the contents fade in a beat after the frame starts moving. Only the frame animates: its size goes straight to its style rather than through React, so the table inside is not rendered again on every frame of the move.
Early on, every material in the plant began to shimmer whenever the camera moved. With the camera still, one frame was identical to the next, so a screenshot showed nothing at all. Finding it took a probe: turn the camera by about a twentieth of a pixel each frame, read the pixels back every frame, and flag the ones that jump. Bigger steps flag every edge that moves. Then each material was swapped for a flat colour of its own, so every flagged pixel could be traced to the material it belonged to.
The worst of it was the floor. The coloured zones on it sat 3 millimetres above the hall floor, too close for the depth buffer to tell apart from the overview's distance, so the two traded places as the view moved. They are a centimetre apart now, and the camera's near plane moves out to about 2.5 metres at the overview and comes back to half a metre for close-ups. The ambient occlusion pass, which darkens corners, was running on too few samples, and its grain crawled over every machine; more samples cost nothing measurable. And on braces turned at exactly 45°, the texture flipped between two orientations from one pixel to the next, until the tie went the same way every time.
Two findings from the hunt hold for any three.js scene. When the lighting
comes from scene.environment, the envMapIntensity of a standard material
with no map of its own is overwritten on every draw, and only
scene.environmentIntensity changes anything. And SMAA, a smoothing pass, made the shimmer worse on top of 4x
multisampling. It also loads its lookup textures after a delay, so a
measurement taken right after switching it on shows it doing nothing.
Some shimmer is still there, on the thinnest parts at the overview: pipes, rails and floor stripes crawl a little along their edges. The scene already uses as much multisampling as the GPU allows, and rendering at a higher resolution would remove it at a real cost in frame rate.