Box dividers down to 3 mm, and the layout that needed 4.8 GB
10 October 2026
The rugged box generator has had a compartment editor for a while. You split cells, drag the divider lines around, and the box comes out with 1.2 mm dividers standing on the floor exactly where you drew them. Until this week the editor would not let a cell get narrower than about 8 mm. Fine for screws. Useless for anything flat.
Version 1.318.0 drops that floor to 3 mm.
What a 3 mm slot is for
The old limit came from a fair worry. Below 8 mm you cannot get a finger in, and that is still true, and the editor still says so. Squeeze a cell under 8 mm and a note appears, "Fine for cards or bits; too narrow to reach in with a finger", but it no longer stops you. Plenty of things in a box are never picked out with a fingertip anyway. Cards standing on edge, spare utility knife blades, a few flat shims. You tip them out or slide them out, and the narrow slot is the thing that keeps them from ending up in a heap.
The 3 mm is free space, not the distance between line centres. A divider in the middle of the box takes half its thickness from each neighbour, the box wall takes nothing, and the editor now measures cells the same way the server does, so a layout the editor accepts is one the server builds. While any cell is under 8 mm, a "smallest cell: A x B mm" readout sits under the layout. Drag a line into the floor and that side is marked "(minimum)". Split buttons grey out when a cell has no room for another split.
Tiny cells also had to stay clickable. Each divider line has a grab area around it, and next to a 3 mm cell that band covered the whole cell, so you could not select it at all. It now shrinks to a quarter of the narrowest cell beside it. Scoops got a fix too: a cell too shallow for a finger gets no scoop, and the ramp stops at the back of its own cell instead of running through the divider into the next one.
The layout that needed 4.8 GB
In September I wrote about the box generator being killed by its own memory limit when someone sent it a big divider layout. I raised the cap to 1200 MB and admitted the real fix was a less hungry generator. Smaller cells made that impossible to put off, because a lower floor means more cells fit in the same box.
So I measured the worst case first. A 500 mm box with 400 cells took 18 seconds and 4.8 GB of RAM for the full model, and with scoops switched on it was 44 seconds and 7.8 GB. Inside a 1.2 GB container that request was never going to finish.
The cause sat in how the box is built. The walls come together as a stack of horizontal slices, 60 to 100 of them depending on the box, and the dividers were merged into every single slice, paying for the whole divider pattern again each time. A divider looks the same at every height. Now it is one extra prism from just under the floor top to the top of the dividers, overlapping the wall by 0.05 mm so the two fuse into one solid.
Same box, same 400 cells: 0.45 GB and 2.1 seconds, or 0.8 GB and 5.7 seconds with scoops. The preview file your browser downloads shrank from 27.6 MB to 4.9 MB. Before shipping I compared 47 configurations against the old code (volume, watertightness, number of bodies, cross-sections, lid clearance), and the geometry matches.
Limits you will probably never hit
The box now also checks the layout itself before it builds anything: at most 400 cells and 16 levels of nested splits. Past that, the editor asks you to merge some cells first. While I was in there I found that the slide-in plates field had no upper bound on the server. The page only offers 0 to 12, but a hand-made request for 100,000 plates ran for 224 seconds and used 8 GB. Anything outside 0 to 12 is now refused with a plain message.
One thing still bothers me. On a phone, a 3 mm cell is a small target for a thumb, and that is the next part of the editor I want to fix.