​

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.

Because the new internals are built around the idea of multiple beds, it is now possible to have multiple beds with different configurations in one project. It is even possible to mix different printers in one project (#13619, #13729, #13858, #13877). We have also removed the limit of 9 beds per project, which was applied in PrusaSlicer 2.9.x for technical reasons (#13866, #14381).

Multiple projects

Thanks to the big overhaul we did, it is now possible to open multiple different projects in one PrusaSlicer instance (#3882, #11007, #12690). The individual projects can be switched using tabs in the top toolbar. The projects share very little context - open dialogs, active tools, etc. are kept per project.

Redesigned UI

While UI changes are always a controversial topic, we have decided that it is time to do a complete overhaul. The UI of PrusaSlicer 2.x was generally a bit intimidating for new users, and many features were hidden. The new UI strives to be more user friendly, but still provide easy access even to the more advanced features - although not everything that we have planned is finished as of this first public alpha.

Let’s take a quick tour!

First of all, there is a new sidebar at the very left, where you can switch between Slicing, Connect and Printables (#13927). The panel also allows access to application Preferences and houses the PrusaAccount login button. (The online features are not mandatory and if you are only interested in slicing, you can opt out from all of them - more on that later.)

Let's further look into the UI on the 'Slicing' tab, which is where most of the work typically happens. We have decided to stop misusing the object list for various things such as object-specific settings, layer range settings, etc. Instead, you now see the object list on the left-hand side, and it serves as an overview of what your project contains, which beds are sliced and similar. The panel grows so it does not obscure more of the scene than necessary, and it is also collapsible when the user does not want to see it at all.

The right panel contains controls related to the currently selected item. When a bed is selected, it allows you to change profiles and settings. When an object is selected, object-specific settings are shown instead. When a tool like Variable Layer Height or Paint-on supports is opened, the right panel is the place where its controls are (PrusaSlicer 2.x used in-scene dialogs, which were a bit intrusive).

The right panel still allows the user to tweak some of the most frequently used configuration options, but unlike in PrusaSlicer 2.x, the list is now configurable. You can add any config option into “favorites” (by checking a star icon in settings) which makes it appear in the right panel. This was long requested by the community (e.g. #1267, #8320, #11105, #12690) and we believe that many non-power users will now have no reason to open the “big” settings at all.

There are many smaller improvements: For example, it is now possible to filter profiles based on filament type or even using fuzzy search (#9303, #11494, #14264). We have modernized 3D rendering to use a PBR-like material render pipeline with ambient occlusion and cast shadows (this is configurable in Preferences and it can be turned off when graphics resources are limited, or if someone simply does not like it). We have also added a "View cube" control to rotate the camera (#4410, #13096), which you can find it in the bottom-left corner (the reason were hesitant about adding it sooner was our fear of possible copyright infringement - we did it now after receiving an explicit approve from the copyright holder).

Both Light and Dark UI modes are supported. Unlike PrusaSlicer 2.x, the styling is now applied even to in-scene dialogs (which had a common look before) and it is generally much more consistent across all three supported platforms. The mode can be switched manually in the Preferences dialog (automatic detection from system settings is not yet implemented).

It is probably pointless to describe everything in more detail - after all, UI should above all be intuitive and not require description in the first place. Let us know your opinion!

Profiles handling changes (#14728)

PrusaSlicer has its built-in "system profiles" - read-only profiles provided by Prusa Research, which can be updated by online updates and which are fine-tuned for both our and 3rd-party printers. This infrastructure has been in PrusaSlicer since 2018, and it is one of the key features of the application. However, it turned out that the system does not scale well with the number of printers and their variants, and that it is practically incompatible with multiextruder printers (like the Prusa XL). One problem - largely invisible to the end user - is that because filament profiles are compatible with certain printers, most variations of a printer require duplicating all filament profiles even if only a single config option is different for a given printer, which greatly complicates maintenance.

Another big problem is related to multiextruder printers and printer variants in general, and we did not anticipate it enough in 2018. Let's say that the user is running an XL with two tools, one with a 0.4mm HF nozzle and another with 0.6mm non-HF nozzle. In PrusaSlicer 2.x, it is basically impossible to simply get the correct system profile. The user must select the closest configuration in the wizard (XL 2T HF0.4 nozzle), create a user copy and then manually change nozzle diameter and all related options (retractions, etc.) for the second extruder. This requires the user to know which options must be changed, and it also disqualifies that user profile from possible profile updates in future - not to mention that the process is quite tedious for a task that should be simple to do.

In PrusaSlicer 3.0.0, the concept of system profiles was changed. Instead of providing some of the possible combinations and variations, letting the user select one and forcing them to tune it to match their exact setup, the profiles now branch on internal conditions. The user simply selects, e.g., that they have an XL 5T. The nozzle diameters and high-flow status are "free" parameters of that profile. Changing these "free" parameters is done simply in the printer profile dropdown, and the whole profile automatically instantiates according to that hardware configuration.

Each nozzle has a potentially different list of supported Print profiles. However, in order to slice, all extruders must use the same layer height. In case that there is no Print profile with a common layer height value for all selected nozzles, PrusaSlicer will report the nozzle combination as mutually incompatible. In practice it would happen in cases where nozzle diameters differ significantly (e.g. 0.25 and 0.8 nozzles).

Another major change with regard to multiextruder printers is that the classic Print / Filament / Printer profiles now have a fourth sibling: a ToolPrint profile. It contains overrides of those options from the Print profile that can be configured differently for each tool (#14872). Note that there is no separate UI tab for ToolPrint profile. Instead, the Print profile tab shows “branching” of individual options per extruder, so that the values that will be used are seen in one place. When a single-tool printer is selected, the user is shielded from this complexity completely, because the UI then does not allow changing the tool print overrides at all.

There are cases where the slicing backend cannot really use a different value of a config option for each extruder, although it makes sense to specify it in tool print settings (for example, the value should be different for high-flow nozzles). In these cases, the per-extruder values are aggregated into a single value based on the strategy defined for each case - the result of the aggregation is shown immediately in the UI.

Setting everything up is very simple if you use PrusaConnect. Using the onboarding dialog or the “Set as current” function in the Connect tab will configure the matching profile automatically. The respective printers will be flagged as favorite. We have plans to make the sync even better integrated in future.

It is now also possible to have unsaved modifications in several filament profiles at once (#5486, #8279, #11613, #14528, #14796). In PrusaSlicer 2.x, editing any filament profile forced saving of any profile which was already modified, meaning that tweaking a multi-material print required the user to keep saving user presets needlessly.

Please understand that while this alpha allows to save custom user profiles, the workflow is not fully polished and it may be confusing. It also does not support full editing of the profile tree that our system profiles use. Both will be addressed in later releases.

Calibration tools & Lua plugins (#6168, #3289)

3D printing is a lot about experimenting and fine-tuning settings, especially when printing with non-standard setups, moist filaments etc. This may require printing various calibration prints with progressively changing settings, so one can find the sweet spot - temperature towers, speed towers and similar. Being able to generate such prints easily is very helpful.

Built-in calibration prints were added into SuperSlicer long ago, and they had propagated to many other forks. PrusaSlicer itself stayed a bit behind on this front. This is now changing. PrusaSlicer 3.0.0-alpha11 comes with two (for now) built-in parametric calibration prints: Flow tower, and Temperature Tower. You select the desired print, adjust parameters in a dialog, confirm, and a project containing an object and settings materializes - you can then save or slice it, like any other project.

If that does not sound like much, do not worry and keep reading. It is just the beginning.

Let us talk a bit about how the calibration tools are implemented. The dialog and the whole “project generation” logic are not embedded inside PrusaSlicer source code, but distributed alongside it in the form of Lua plugin. The application scans the plugin folder and builds the menu items dynamically on startup. The plugin defines its inputs, PrusaSlicer builds the parameter input dialog accordingly and passes the values to the plugin when it is executed. Plugin communicates with PrusaSlicer using some defined API. This means that in principle, one can add more plugins or modify existing ones without updating PrusaSlicer itself.

At this point we present this purposefully minimal implementation so we can hear your opinion. The purpose of currently existing plugins is to create objects programmatically. However, the architecture is designed to accommodate more plugin types, based on what the plugin is wired to and what it does. Note that the Lua API is currently experimental and it is subject to change. We will probably do a breaking change every now and then, it will most likely never be completely stable.

We have put significant effort into making the whole system safe. Any plugin system effectively means that an application - a process with user permissions - executes code that was not distributed with it and tested by the authors. This is why we chose Lua - the system is more or less designed to be sandboxed, and the plugin can be very simply restricted from accessing filesystem, executing other processes and similar. The plugin can only get permissions to do what it is expected to do.

And there is a cherry on top. We are already working on a plugin marketplace - a web interface where it will be possible to share plugins with the community, search through them, rate them, and similar. It will also allow the user to install the plugins with one click, without having to download files and figure out where to copy them. In addition, the bundling system of the plugins supports cryptographic signing - any plugin author can easily sign their bundle with a private-public key pair. This will allow the user to check that the downloaded plugin is indeed what that author published and keep a list of trusted authors. The marketplace is currently in testing and it will be launched in the near future.

Performance improvements

Although PrusaSlicer 2.x was not terribly bad in this regard, it would occasionally become unresponsive for a short while, for example when a slicing task was being cancelled. The startup time of PrusaSlicer 2.x was also quite long. These issues were addressed and you should see visible improvement. There are also somewhat less important related improvements, which were made possible thanks to the big internal refactoring.

When slicing multiple beds at once, the beds are now sliced in parallel, meaning that the overall slicing time will usually be shorter. However, do not expect that slicing time will be the same regardless of how many beds there are - even in PrusaSlicer 2.x, the slicing of a single bed was already parallelized to quite a large extent.

Saving a 3MF has also been optimized, expect it to be more than twice as fast as it was in 2.9.6.

Offline mode

In PrusaSlicer 2.8.0, we started deeper integration of PrusaSlicer and our web services (PrusaAccount login, PrusaConnect and Printables). We were very open about all this being completely optional, and we provided an option to hide these features for those who are not interested. Despite that, the change was sometimes considered to be the first step to making slicer login mandatory, and people complained about frogs being boiled slowly. The whole thing raised emotions at times, even words that polite people tend to avoid had been uttered now and then (#13951, #12968, #14145).

In PrusaSlicer 3.x, it is possible to completely disable all online services. The option to opt-out is presented in the Welcome wizard - not just before any embedded browser is loaded, but before any other online communication happens. This also includes online profile update checks, meaning that PrusaSlicer is now capable of running in restrictive environments without triggering any firewall alarms. It is possible to selectively enable and disable the individual services in application Preferences, so everyone can choose which of them they want to use. When all services requiring embedded browsers are disabled, there is no webview-related performance overhead. We believe that this is flexible enough to cover all use-cases that needed to be covered.

CLI changes

PrusaSlicer 3.x is still capable of CLI-only operation, but the whole code for parsing and evaluating the command line arguments was completely refactored. We tried to keep the interface intact as much as possible, but very likely some parameter combinations and less typical use cases will require updating scripts that you use to run PrusaSlicer. If we broke your workflow, feel free to let us know - it may be simply an overlooked edge case, rather than a deliberate change.

Compatibility with PrusaSlicer 2.x

Old 3MF projects from PrusaSlicer 2.x should load and work. PrusaSlicer 3.x will load the old configuration, transform it into the new format, infer correct printer configuration and find the respective profile among system profiles. That means that if you used the MK4 HF0.4 profile in PrusaSlicer 2.x, modified some values, saved a 3MF and loaded it in PrusaSlicer 3.0, you will see the correct printer selected and the modified values will still be flagged as modified.

Please note that loading projects using custom printers or projects from other slicers is not fully supported yet. You may encounter errors in these cases. This will be taken care of shortly.

Loading projects from PrusaSlicer 3.x in PrusaSlicer 2.x is possible, but the old slicer will only load the geometry, not the configuration. If you are running PrusaSlicer 2.9.1 or later, you will be notified about this. In older PrusaSlicer versions, the config will be skipped silently.

License

This is not really a new feature, but we noticed various discussions about this on social media. PrusaSlicer 3.x is released under AGPLv3, meaning that it stays as open as PrusaSlicer 2.x, Slic3rPE and original Slic3r. This is in line with the will of @alranel, who has laid the foundations that we (and not only we) now proudly stand on.
Although the GUI rewrite was so massive that it would have been technically possible to separate it from the slicing backend and close its source code without violating the license, we have decided to honor the principles that our company was based on from the very beginning. You are free to read or modify the source code as you like, provided that you in turn release the source code of any derived work and let others do the same if they so choose (read full AGPLv3 license for details). The open source journey continues, and everyone is welcome to follow it with us.

Reworked color visualization settings

In PrusaSlicer 2.x, the user could set the colors in Printer Settings (for each extruder) and in Filament Settings, with an option to have the extruder color unset. This was confusing and it also tied the colors with the filament / printer preset - meaning that one had to save a user profile just to color the project as they wanted. In PrusaSlicer 3.0.0, the color is now saved at a project level, meaning you can set the colors in individual projects as you like, even if they use the same filament and printer preset.

Configurable camera control (#4277)

It is now possible to change mouse bindings for camera control. There is a dropdown in Preferences, you can currently choose PrusaSlicer, Blender, Tinkercad, Fusion or SolidWorks-like schemes. An option to reverse mouse wheel direction is still present and is completely independent of the selected binding.

Auto-restore (#8430, #15119)

PrusaSlicer now periodically backs up all opened projects in the background. When the application crashes or when it is killed by an OS for whatever reason (like running out of memory), all opened projects can be restored on the next application start.

Floating objects (#1513)

Lifting objects above the build plate is now possible. PrusaSlicer 2.x did not allow this and snapped objects to bed, lifting them required various ugly workarounds. Allowing this required multiple changes in both the GUI and backend code, which is why we never got to lift this limitation in PrusaSlicer 2.x, despite frequent requests. The time has now come, sorry for the long wait.

Automatic crash reporting

We have implemented a mechanism to report application crashes automatically. This will give us important data to prioritize bug reports and it will provide us with vital clues to be able to reproduce and fix such crashes. In the background, we use sentry - a battle-tested bug reporting tool - to help us collect and organize the bug reports.

The crash report contains a stack trace (to tell us where it crashed) and application log (to tell us what happened before). It obviously does NOT contain the geometry you are printing, nor the configuration used. However, the log may contain absolute paths to files in your local setup - if you are not fine with this information leaving your computer, you should leave the option unchecked - the automatic crash reporting is strictly opt-in and an option to enable it is presented in the Welcome wizard. You can change your choice in Preferences at any time.

Slicing backend improvements and bugfixes

• Fixed intersecting infill with perimeters when a single perimeter on top surfaces is used (#14405).
• Changed extrusion width calculations to use nozzle diameter instead of layer height. The old behavior was inherited from Slic3r and it was a long-standing source of confusion for many. Because projects from 3.x are not compatible with PrusaSlicer 2.x, we used this window of opportunity to finally change the behavior. Projects from 2.x are updated on import (#1923, #2829).
• Travel paths generated due to "avoid crossing perimeters" are now simplified by G-code resolution (#12065).
• Removed narrow overlaps between top and bottom surfaces from bottom surfaces to prevent unwanted bridges (#14329).
• Fixed crash when the raft was enabled in a specific case (#14533).
• Filtered out unnecessary support base islands.
• Fixed out-of-bounds access when a multi-material painted object is sinking and has zero top layers.
• Fixed crash inside TriangleMeshSlicer when slicing facets without any color information.
• Fixed organic supports not supporting low overhangs well (partially fixes #9601).
• Split the raft first-layer density and expansion parameters, which were previously shared between the raft and supports, into separate parameters for the raft and the supports.
• Fixed a tool change being preceded by a travel to the next object when the wipe tower is disabled.
• Fixed travel_short_distance_acceleration being emitted when travel_acceleration is zero.
• Fixed crash in tree supports with zero interface layers and no raft.
• Fan speeds are now clamped to the min/max range when dynamic fan speeds are enabled.
  extrusion_width in placeholder parser now reflects the value set in config without further smart deduction. If it is 0, "0" is emitted, if it is "80%" and nozzle_diameter is 0.4 the result of "0.32" is emitted.

Other improvements with respect to 2.9.6

• PrusaSlicer has supported gcode and bgcode output formats since 2.7.0. In PrusaSlicer 2.x, the required format was configured in Preferences, because the G-code generator needed to know it during slicing - but it was quite unexpected. Now you can simply choose the required type in the Save file dialog and the Preferences option has been removed (#11913).
• ‘Layer height range’ is now a separate tool and not embedded in Object List. Hopefully the feature will be more discoverable that way (#378, #495).
  ‘- Bed temperatures differ’ warning (and similar warnings) now shows only when the affected extruders are actually used in the print (#15519).
• filament_load_time and filament_unload_time were removed from filament settings, replaced by filament_change_time in printer settings
• Supports are no longer configured by two misleading checkboxes - there is a single dropdown now.
• The painting tool now uses a constant edge limit to ensure fine subdivision regardless of brush size.
• Wipe tower preview shape is only shown and used when the current project will actually use the wipe tower. PrusaSlicer 2.x would show it even for single extruder prints, just on the basis that the printer had multiple extruders and the wipe tower was enabled - it only corrected itself after reslice. Now it checks what extruders will really be used (#7813, #13020, #11938, #14636).

Bugs fixed with respect to 2.9.6

We apologize in advance that this list is incomplete. Because we were rewriting big parts of code instead of explicit bugfixing, we have very likely fixed many bugs without even being aware of them. (Hopefully we have not introduced too many new ones in the process.)

• Fixed a crash when using --merge on CLI (#14632)
• Fixed a crash when adding manual extruder change at layer (#14536).
• Measure tool was incorrectly disabled when a volume was “sinking” (#11119, #13546).
• Fix cooling perimeter transition distance to use each object's own extruder instead of the current extruder.

What is in the queue?

As mentioned above, important pieces of 2.9.6 are still being worked on, and they are not part of this alpha:

🚧 SLA slicing

The whole SLA part of the slicer is now suppressed. A lot of it is actually ported already, but there are many corner cases which need attention, and we decided to focus on FDM before we get to them.

🚧 3rd-party profiles

The alpha only contains profiles for Prusa printers. Porting of the others was postponed for practical reasons - several iterations which required constant changes in the profiles were done, and having to update all profiles all the time means wasting effort. Therefore we decided to validate all the profile-related changes on Prusa printers first. 3rd-party profiles will be reintroduced later. This is not a first step to a “walled garden”, as some may fear. Nothing has changed about our opinion on support for non-Prusa printers.

🚧 Standalone G-code Viewer

PrusaSlicer 2.x provided an option to load a .bgcode / .gcode file and show the preview. While this is planned to be ported as well, it will not be available in PrusaSlicer 3.0.0.

🚧 Others

• Post processing scripts
• Custom G-code editor
• Sequential arrange
• 3Dconnexion mouse support
• Mirroring
• Accessibility and support for screen readers