PrusaSlicer 3.0.0-alpha11

PrusaSlicer

Summary

This is the first public alpha release of PrusaSlicer 3.0.0. This release comes with completely redesigned internal architecture, new UI, new print profile system, full support of multiple beds and multiple projects and other improvements and bugfixes.

To let you enjoy the alpha without worries, the alpha builds save their profiles into the PrusaSlicer3-dev directory, so you may use the alpha side by side with the current release without ruining your production configuration. The configuration folder is different from what PrusaSlicer 2.x is using, meaning that PrusaSlicer 2.x and 3.x can run alongside each other without any conflicts.

Important note for Linux users: We are now using Flathub ↗ as the only official distribution channel of PrusaSlicer on Linux. This alpha version is available in flathub-beta repository.

A detailed change log follows. You can also read the respective article on our blog ↗ for a more concise version.

Before we start

While PrusaSlicer alpha builds are generally well polished and almost production ready, it is NOT the case this time. The amount of changes and the need for early feedback has forced us to release an actual alpha, which is expected to be unstable and not polished. What you are seeing is not a production build, this is an unfinished alpha which aims to present the general direction we are taking.

It is also worth noting that the alpha build is not feature complete (when compared to 2.9.6). We are still working on porting various things from PrusaSlicer 2.x and sadly, some of them have to wait for later releases to be fully ready. While we understand that this is a nuisance, a large part of the application was rewritten from scratch and reimplementing everything takes time and effort - PrusaSlicer has surprisingly many features.

You can find the list of unfinished features at the end of this change log.

Congratulations, PrusaSlicer!

Let us now congratulate PrusaSlicer - it is its birthday. Exactly 15 years have passed since Alessandro Ranellucci (@alranel) authored the first commit of this repository. To quote from the README which was a part of that commit:

Slic3r is (er, will be) an STL-to-GCODE translator for RepRap 3D printers, like Enrique's Skeinforge or RevK's E3D.

Notice the future tense. Given what Slic3r was capable of at the time, it was a bold statement. But it turned out that Alessandro was exactly right. What he and other contributors created has later become the core of one of the most widely used family of slicing applications. Let us wish PrusaSlicer all the best for the upcoming years and appreciate the time and effort that people thanklessly sacrificed to make it possible.

Internal architecture refactoring

We can continue with the history lesson. The project originally started in Perl and was later rewritten into C++ in several steps. This alone led to architectural compromises. In addition, the application originally did not support multiextruder printers, SLA printers, wipe tower, multiple beds, filament overrides and other cool features. As PrusaSlicer outgrew the original scope, many of these features were later added (as well as many others), and the project gradually became quite large. However, the architecture of the application was not ready for these big changes.

Especially in the last couple of years, it was apparent that implementing anything is becoming more and more difficult because of various hacks which have piled up over time. PrusaSlicer showed classic signs of architectural decay, and it slowed the development down significantly. When we got to a phase where we would decide to rather not fix an obvious bug with the reasoning that the bug is better than what the fix would likely cause, we understood that it got way too far.

Therefore, we have decided to take the long postponed big leap and refactor the internals around current requirements. The amount of technical debt was so large that we made a hard decision to rewrite most of the UI code from scratch (despite knowing that developers usually regret it in the end). The new architecture is designed with carefully defined responsibilities, interfaces and data flow, it is better covered by tests, etc. The architecture of the slicing backend was kept (although substantial changes in the backend code were done as well). We have also improved our internal processes as we went.

We are hoping that all this will untie our hands again and allow us to speedily deliver more new features.

As much as we understand that users don't have a reason to care about internals of the software, this is the most important change and it is what made the following improvements possible (and also others which are coming soon).

Multiple beds with different configs

We have introduced multiple beds feature in PrusaSlicer 2.9.0, although the implementation was purposefully minimal - especially regarding 3MF projects. We knew at the time that we were going to do a bigger update, so we decided to not save the bed data into 3MFs, and instead to infer the beds from positions of the objects. This was done so we wouldn't have to break forward compatibility of our projects twice, but only once.