Research note · 13 September 2026

The engine we built from the loss

After sparrow beat us thirteen times out of thirteen, we measured what it does that we did not — and wrote that search ourselves, on our own collision engine, with our own pattern finder in front of it. Measured by one judge, on 48 shop-floor jobs, with the true outlines and holes.

Five wins outright, 34 of 48 within three points, and on structured jobs — series of identical parts, parts inside other parts — a clear win: squares 92.4 % vs 85.5 %, part-in-part 70.0 % vs 53.5 %. The solver also plans lead-ins that fit the scrap and, on request, starts each part inside the kerf of the previous one.

Download the solver whitepaper (PDF)

Why measure against someone else at all

In sheet-metal fabrication nesting is money. One percentage point of sheet utilisation across a thousand plates a year is a real sum, and the spread between tools runs into double digits.

We had been benchmarking our previous engine against Deepnest, a popular open-source tool from 2016. We were barely keeping up, and we treated that as a result. It was a methodological mistake. A bar set too low produces a false sense of progress — successive iterations stopped adding anything, because we were optimising against a reference point that was not itself ambitious.

So we started over with an explicit goal: measure ourselves against the best that exists in public, and find out how far short we fall.

The opponent

sparrow 0.2.0 — a heuristic for two-dimensional irregular strip packing, published in September 2025 by Jeroen Gardeyn of KU Leuven, built on the jagua-rs collision engine. MIT licence, roughly 4,600 lines of Rust.

We chose it because it is the strongest published result, it is fully available — so the comparison is verifiable rather than resting on a vendor's claims — and it is current.

The difference in family is the heart of the matter. Our engine, Deepnest, and most commercial systems are constructive: place part after part, never allow overlap. sparrow belongs to the separation and compaction family: place everything, allow overlap, then pay it down. That single distinction turned out to explain the entire gap.

What we tested it on

A real production job from our own shop — 120 parts in seven shapes, 10 and 15 mm plate, 1500×3000 mm sheet, 6 mm spacing — and thirteen classic ESICUP benchmark instances that have been used in the literature for decades. Importantly, we did not choose the benchmark set ourselves; a self-selected test set can always be unconsciously fitted to one's own algorithm.

The result

Thirteen instances, 60 seconds each, one machine, one metric, every layout verified geometrically on real polygons rather than on the raster.

The difference is visible without reading a single number:

What compute does not buy

The single most useful measurement we made. Our GPU engine evaluates about 300 complete layouts per second — three orders of magnitude faster than the same decoder on a CPU. So we gave it 2.85 times more search and looked at what came out.

Identical to the pixel. The record was set after 66,816 evaluations; the following 117,504 layouts improved nothing. A completely different search strategy — ruin & recreate instead of a genetic algorithm — tied to within the noise.

The one thing that did work

Clustering — exhaustively searching every relative placement of two shapes and fusing the best pairs into a single object before nesting. Triangular ribs that fill only 74.6% of their own bounding box combine into pairs at 96.1%. A trapezium that already fills 97.2% of its rectangle is correctly left alone.

Worth +2.12% on our engine, and every random seed improved. So we fed the same clustered instances to sparrow.

It made sparrow worse — by 0.36 points.

Two errors we caught in our own code

This section is here deliberately, though it does us no credit.

Borrowing from the physics of granular materials, we tried tapping the layout: rotate the small parts a couple of degrees at random, let gravity settle them, repeat. The first measurement showed +9.38 percentage points. It looked sensational.

Geometric verification found 38 pairs of overlapping parts. Rotation drove each part into its neighbour and the settling routine never repaired it. That was not a denser packing — it was parts driven into one another.

We fixed it, measured gravity alone, and got +2.98 points on the same instance. Verification found 17 overlapping pairs: in one branch, neighbours were searched within a radius five times smaller than the permitted movement, so parts were passing through objects that were never tested.

With both faults fixed and a guard that rejects any layout containing an overlap, gravity is worth between 0.01 and 0.09 points, and vibration — across 463 taps — is worth exactly nothing.

Why tapping a jar works and tapping a nest does not

A jar densifies because the grains move all at once and can momentarily squeeze through the loosened structure. A correct implementation enforces feasibility at every instant — so nothing can ever pass anything else, the structure is frozen, and every rotation is pulled back to where it started. Our broken version "worked" solely because it let parts interpenetrate permanently.

The real mechanism requires allowing overlap temporarily and paying it down. Which is exactly what sparrow does. The physical intuition was sound; the best existing algorithm already implements it, correctly.

What we build from here

sparrow becomes the packing core. Our raster engine moves to where its properties actually pay: lead-in placement, pierce points and collision checking, where inflating the geometry before drawing it makes a clash impossible by construction rather than by checking.

There is no reason to rewrite a year of someone else's work from scratch just to arrive at the point where improvement can begin. You take the best published result and push it further. That is how research is done — and it is also, we think, how honest software gets built.

sparrow and jagua-rs are the work of Jeroen Gardeyn (KU Leuven), released under the MIT licence and used here with the copyright notice preserved. The paper describing the algorithm is arXiv:2509.13329; the source is at github.com/JeroenGar/sparrow. We are not affiliated with the authors and they have not reviewed this note.