How does CakeForge
pack a build?

01 / THE OBJECTIVE

Use the build volume well. Keep every part usable.

A cake is one powder-bed build. Each part has a requested quantity, a shape, permitted orientations and spacing requirements. CakeForge searches for positions that respect those constraints, filling additional cakes when necessary. Optional consolidation tries to reduce the number of cakes; optional refinement tries to improve the arrangement within a cake.

There is no single density number that describes every goal. A short, compact build can use less powder than a taller one with the same full-chamber density. Nesting a part inside a cavity may save space, but only if there is a way to separate the pieces afterwards.

02 / YOUR MACHINE

A local application, delivered by a website.

The website supplies the program, not a remote packing service. Your browser loads the application and runs it on your computer. It acts as both the delivery mechanism and the execution host: your CPU does the CPU work, and your graphics device does the WebGPU work. There is no server-side packing queue.

How the browser hosts the engine

The packing engine is written in Rust and compiled to WebAssembly. A dedicated worker runs parsing, packing, verification and slicing away from the page’s interface thread. Where supported, a worker pool and shared WebAssembly memory allow CPU work to use multiple cores. The host supplies the cross-origin isolation headers needed for SharedArrayBuffer; when that facility is unavailable, the CPU path can run with one thread.

WebGPU creates device buffers and executes compute shaders through the browser’s graphics implementation. Those buffers are local device resources, not cloud storage. The 3D viewer is also rendered locally. Your machine’s memory, processor, graphics capabilities and browser limits determine the available capacity.

Page-to-worker postMessage() calls transfer or copy values between local execution contexts. They are not HTTP requests. A worker can independently make a network request to load its code or assets; that is a different operation. MDN explains worker messaging and execution.

Exports are built as local bytes and downloaded through a browser Blob URL. Settings and custom profiles use local browser storage. The loaded meshes and packed result live in the current session; saving preferences is not a backup of the job.

Verify the boundary yourself

1. Inspect the requests. Open DevTools → Network before loading the tool. Wait for the engine to be ready, then clear the log. Import a small file from your disk and pack it. Inspect new requests using their URL, method, initiator and payload; use the full request list as well as the Fetch/XHR and WebSocket filters. The reviewed packing path contains no geometry submission or remote job API. Chrome’s Network reference describes these controls.
2. Disconnect after initialization. In a fresh, fully loaded tab, switch Network to Offline before selecting a local file. Run the first pack, inspect it, and download an export. You can also disconnect the computer’s network to cover traffic outside one DevTools target. A successful run demonstrates that this workflow did not need a remote computation service.
3. Inspect local execution. DevTools exposes worker execution contexts. Browser or operating-system task managers can show CPU, memory and GPU activity during the job. This corroborates local work; GPU activity alone may also come from the viewer, so compare it with the selected packing backend and the result’s GPU/fallback notes.

03 / REPRESENTATION

Turn complicated surfaces into grids.

For each permitted orientation, preparation builds a voxel representation: a regular 3D grid whose cells record occupied space. Spacing fields and nesting rules reserve additional forbidden space. These grids make repeated placement queries much cheaper than testing every original triangle at every candidate position.

The search is discrete. It tries a finite set of rotations and grid translations, rather than every possible pose. A smaller packing voxel captures more detail, but requires more memory and computation. For the same physical box, halving the cell width creates approximately eight times as many grid cells.

h is the packing voxel width; L_x, L_y and L_z are physical dimensions. Padding and extraction headroom add further cells. This resolution is separate from the layer thickness used for slicing.

Voxel search does not replace final mesh checks. CakeForge retains the original geometry and checks actual chamber bounds and mesh distances after placement.

04 / THE MATH

Ask about many translations in one operation.

For a fixed orientation, let A(q) be the part’s binary occupancy and B(q) the current blocking field, including the spacing representation. At a translation t, count their overlap:

If the count is zero, that translation has no overlap in these grids. A positive count means it intersects forbidden cells. The expression is a cross-correlation. With the transform convention used here, the same map can be calculated as:

An FFT changes how the overlap map is computed. It does not choose the orientation, optimize the whole job, or prove removability on its own. The transform work scales approximately as O(N log N) per map; orientation count, memory traffic, updates and validation also contribute to total runtime.

The spectral collision formulation follows Cui et al., §3.1. CakeForge caches orientation spectra, evaluates candidates and chooses winners on the GPU, and updates occupancy between accepted placements. Batching keeps these decisions on the device until completed results are ready for the worker.

05 / CONFIGURATION SPACE

A place to fit is not always a way out.

Imagine replacing each possible translation by a point. Mark that point blocked if the part would collide there. The remaining points form the part’s free configuration space. An exit is a connected path through those points to somewhere clear of the surrounding material.

The connection between collision maps and disassembly follows the paper’s §4. GPU insertion checks search collision-free translations toward empty space above the pile. This conservative test can miss valid side exits. Normal audited packing permits cavity candidates without that insertion proof and checks removal after the optional squeeze.

When every selected placement has a GPU insertion proof, removing parts in reverse insertion order restores the same obstacle sets and supplies a removal certificate within the voxel model. If any selected placement lacks that proof, the completed layout receives the full removal audit. Later operations must also preserve the certificate.

06 / OUR IMPLEMENTATION

Shared foundation. Different engineering choices.

The comparison below concerns the published method, not the authors’ source implementation. These differences do not establish better packing quality or scientific novelty.

The ranked GPU objective

Ignoring orientation-specific bias, the settled candidate key can be read as the following tuple, compared from left to right:

Here H is the current pile height, h is this orientation’s voxel height, and c sums nearby overlap-map counts as a contact surrogate. The second term is twice the voxel bounding-box center height, not the mesh’s center of mass. This is a lexicographic ranking, not the paper’s distance-based objective.

GPU packing still has CPU work around it

Spectral packing · GPU runs correlation, candidate selection, settling, reachability and occupancy updates on the graphics device. Full removal searches for GPU jobs also run there. The CPU prepares geometry, coordinates batches and checks original-mesh bounds, clearance and proposed motion.

Voxel search · CPU is a separate placement backend for devices without a usable GPU. It searches voxel placements on the processor and may defer expensive removal checks until the completed layout. It can choose different placements from the GPU backend. Loading this explanation starts neither backend.

When a full removal audit is needed

A layout without trusted insertion history needs a full removal audit. Imported layouts cannot claim the internal certificate. After original-mesh checks and certified alignment to the audit grid, the GPU auditor tries straight exits, then bounded searches for turning translation paths to any of the six exterior faces. It removes proven parts and revisits the rest. A cropped search region or exhausted budget leaves the result unresolved when it cannot establish a verdict.

The separate CPU auditor can also extract rigid nesting groups and check their members independently. A group leaving the cake does not prove its members can separate. Neither auditor removes unproven obstacles merely to make another path succeed.

If a GPU audit finds trapped parts in an otherwise geometrically valid cake with no unresolved findings, up to three automatic repair cycles reinsert only those parts and audit each proposal. Other placements stay fixed. Retry validation (4× budget) rechecks failed or inconclusive cakes without moving parts. Repack cake rebuilds the affected cake together with the final cake and adopts only a complete replacement that passes the required checks.

07 / IMPROVE, THEN CHECK

Move the arrangement without spending its clearance.

Optional refinement changes translations within a cake, not rotations or part identities. For one GPU refinement phase, preparation computes each part’s movement radius from its original spacing slack. The radii are chosen so that two parts cannot consume more clearance than the pair has available:

The implementation includes a numerical reserve and caps the search range. A second phase bounds relative vertical travel with constraints of the form d_i ≤ d_j + c_ij, where these d values are downward displacements. GPU relaxation lets close neighbors descend together while staying inside those prepared limits.

When layer balancing is enabled, candidates trade layer-coverage variation against occupied height. The current comparison uses RMS coverage deviation over a fixed chamber-height window plus 0.10 × occupied height / usable height. This is an engineering heuristic, not a thermal simulation.

The GPU job runs pack → optional squeeze → final audit, with no full audit before squeeze. Original-mesh distance and continuous-motion checks guard squeeze moves. If a changed candidate fails the final audit, it is discarded and the original pack is audited. If squeeze fails or makes no accepted change, the original is audited once. A preserved insertion certificate can avoid a full removal search; final mesh bounds and clearance are still checked.

GPU squeeze processes one cake at a time, using layer profiles instead of dense distance fields. Detailed collision geometry is loaded as needed within a bounded memory budget. If preparation cannot fit, that cake stays as packed and the job continues. Layer balancing may redistribute parts without lowering the pile; neither a lower pile nor fewer cakes is guaranteed.

08 / READ THE RESULT

Always ask: a percentage of what?

Let V be total material volume, A the physical build-plate area, H the usable chamber height and h the occupied pile height. The workspace reports several distinct quantities:

Full-chamber material density

V / (A × H) compares material against the whole available chamber.

Material / built slab

V / (A × h) compares material against the height actually occupied by the pile.

Powder-use fraction

V / [A × (base + h + cap)] includes the powder layers below and above the parts.

Layer coverage

slice area / A describes an individual layer. Its graph uses a fixed 0–100% scale.

Voxel occupancy can include spacing reservations and should not be confused with material volume. Packing voxel width, mesh detail and slice thickness are also different settings with different effects.

During a build, the progress panel shows the current cake, GPU activity and placement progress. “Minutes left” estimates placement time from the current run’s average after warm-up; an earlier matching run can supply the initial estimate. It excludes preparation, squeeze and the final audit. A full placement bar therefore does not mean all checks are complete.

09 / SCOPE OF THE CHECKS

Know what has—and has not—been established.

• Finite search. The chosen orientations, voxel grid and work budget limit what can be found. A result is not a globally optimal packing.
• Translation-only extraction. Neither CakeForge’s current removal model nor the paper’s disassembly model searches arbitrary rotational maneuvers. A grid-level trapped finding is not a proof over all continuous rigid motions.
• Unresolved is a separate result. A budget limit, uncertain alignment or unproven group exit is not the same as a completed search finding no exit.
• Geometry checks are not process qualification. Packing and coverage heuristics do not model thermal stress, warping, powder behavior or every printer constraint. The CLP slicer targets the Loopzizo K100; its machine output still needs validation on actual printed parts.
• Performance belongs to a workload. The paper’s timings and densities are not CakeForge benchmarks. A fair comparison must match meshes, quantities, spacing, resolutions, orientations, stopping rules, hardware and accepted verification results.

10 / FOLLOW THE REFERENCES

The paper and the implementation.

Qiaodong Cui, Victor Rong, Desai Chen and Wojciech Matusik. Dense, Interlocking-Free and Scalable Spectral Packing of Generic 3D Objects. ACM Transactions on Graphics 42(4), Article 141, 2023.

DOI: 10.1145/3592126 ↗Read the paper at MIT (PDF) ↗

This explanation was checked against CakeForge’s spectral placement, insertion checks, removal audit and constrained refinement behavior. The illustration above is original and deliberately simpler than the production algorithm.