Modern Stack
The 3D printing software ecosystem has been building on the same foundation for over a decade. At some point you have to modernize the base or you're just stacking features on top of technical debt. We decided to rip off the bandaid.
"I built a powerful PC for slicing large, complex models. With Arachne on, it took almost an hour to slice a 200mm x 200mm x 160mm molecule model. CPU was used fully for a few seconds then only one core was at intermittent 100% with 31 sitting idle. preFlight did the same slicing in about 80 seconds. 50 times faster."
- Immortal_Tuttle on Reddit
Luminary and DSKY
One of our first goals with preFlight was to retire libslic3r, the fifteen-year-old engine at its core. Luminary replaces it. This isn't just a rename, it's an entire ground-up reimagining of the engine we've been working towards since inception, with additional modernization still ahead that will land in future releases. And while we were at it, the UI formerly known as slic3r becomes DSKY.
The names come from Apollo 13. When an oxygen tank blew on the way to the Moon, the crew powered down the Command Module to save it for reentry and used the lunar lander, Aquarius, as a lifeboat. The software that flew Aquarius home was Luminary, and the crew ran those critical burns by hand through the DSKY, the display and keyboard unit. Neither Luminary nor the DSKY was meant to save a mission, but together they brought the crew back alive. That's the pedigree we want for the engine everything else depends on.
True 64-bit Architecture
The Slic3r lineage uses 32-bit coordinate types internally. preFlight moved to native 64-bit throughout, eliminating overflow bugs on large prints and matching Clipper2's native types. Clipper2 is compiled with 10-decimal precision, far exceeding the standard used by other slicers built on the same geometry library.
Modernized Dependencies
C++20, Clipper2, Boost 1.90, CGAL 6.1, OpenCASCADE 7.9, Eigen 5.0. We replaced GMP/MPFR, killed GLEW in favor of GLAD, and fixed memory leaks that accumulated gigabytes over long sessions. The Clipper1 to Clipper2 migration alone took months to get right and touched every polygon operation in the codebase.
Built Upstream, Not Bolted On
It would have been easier to slap on features in post-processing, which is how others tend to do it. We took a different approach and modernized at the source. Our features are built upstream, not bolted on in post. It's not glamorous work, but it's what makes everything else possible.
In-Memory Processing
preFlight slices, generates and previews G-code entirely in memory. The G-code text lives in a single GCodeObject with a line index, and the processor's move data sits beside it, so generation, preprocessing, preview and export all work from one copy. Before this, G-code was written out as text and then fully re-parsed to extract move data for the preview. That re-parse is gone. Move processing streams during generation, so the data is built once. Measured against PrusaSlicer 2.9.6 on the same project, preFlight uses roughly half the RAM. For a text G-code export, the file you asked for is the only disk write. Binary G-code and uploads stage a temporary copy that is removed when they finish.