We are happy to announce the stable release of PrusaSlicer 2.7.2. While we work on the next major PrusaSlicer version, we’ve put together this smaller release, featuring many improvements based on the recent feedback.

Download PrusaSlicer 2.7.2

Multi-Material Painting – Enhanced Precision

One of the significant improvements in this update is the new multi-material segmentation. In PrusaSlicer, we use Voronoi diagrams as part of several features such as the variable extrusion width using Arachne, multi-material segmentation, gap-fill, and thin-walls. We use the Voronoi diagram implementation from the Boost library because it is both fast and numerically stable.

Voronoi diagrams (image source)

Unfortunately, on rare occasions, it produces a non-valid Voronoi diagram for some input polygons (the graph is not planar, missing vertices, etc.), which could cause spilled layers with multi-material segmentation, artifacts on external perimeters with Arachne or even crashes of the application.

In 2.5.0, we implemented several mechanisms to detect a non-valid Voronoi diagram, and by manipulating the input, we could ensure that the Voronoi diagram would be valid. These mechanisms were originally implemented only for Arachne, and they were heavily tied with Arachne’s data structures. In this release, we have generalized these mechanisms to be used anywhere in PrusaSlicer. This itself solved many of the spilled layer issues with multi-material segmentation and also one crash during thin-wall generation.

We also reimplemented a significant part of multi-material painting from scratch, which, together with the changes above, should resolve all issues with spilled layers for multi-material segmentation.

Community-Driven Color Change (M600) Improvement

Previously, PrusaSlicer placed the color change (M600) right after the previous layer was finished. The default implementation of color change in pretty much all firmwares returns the nozzle to the exact same position as before the color change started. As a result of this behavior, a small blob of filament with the newly loaded color would get stuck to the print.

Our community, especially @Nohus, came up with a solution of placing the color change after moving to the next layer and position, which proved to be much easier and more universal solution than changing the M600 implementation on the firmware side. Thank you, Nohus, for your implementation and all of you who participated in testing his change.

Ramping Travel Moves: Smoother and More Efficient

We’ve replaced helical layer changes introduced in 2.7.1 with a more refined ramping profile. While the helical layer changes helped to reduce stringing, they sometimes caused color blobs and artifacts. With the new and refined ramping profile stringing is still mitigated without the disadvantages of the helical movements.

Filament oozing caused by the helical layer change in PrusaSlicer 2.7.1

During a ramping travel the print head moves in both XY plane and Z. If the travel is sufficiently long, the print head will reach the desired lift before the travel ends. This means that the Z-motor has to decelerate to stop, while the X and Y motors are still moving. Due to the limitations of motion planners in printer firmwares like Marlin and others, this Z-axis deceleration may lead to slight unnecessary slow down of the movement in the XY plane.

This issue can be sometimes mitigated by smoothing the ramping travel moves. PrusaSlicer now automatically employs this slight optimization when applicable. This further helps to prevent stringing and may even improve print times by a very small amount.

SLA Overrides

For SLA printing, we’ve introduced Material Overrides. This new feature, mirroring the flexibility of FDM slicing, allows to override selected configuration options from Print or Printer Settings in Material Settings. There is a new parameter page in Material Settings, which allows to check the parameters which would be overridden and to redefine their value.

A Farewell to Perl

PrusaSlicer’s origin is based on the Slic3r project, which was originally written in Perl scripting language. Over the years, we’ve rewritten nearly all of the code. First the slicing core, then the user interface. We have now rewritten all remaining unit tests still depending on Perl into C++. Goodbye, Perl. You will not be missed.

Other changes

We’ve addressed a wide range of bug reports that improve the user experience and software reliability. Key fixes include resolving issues with arranging objects on the print bed, including alignment fixes and the occasional misplacement of the wipe tower. We’ve also tackled UI glitches, such as those encountered when setting object scale to very high values or navigating through dropdown menus with keyboard arrows.

We hope you’ll enjoy the improvements in PrusaSlicer 2.7.2 and look forward to your feedback. While we focus our efforts on a bigger PrusaSlicer release (2.8/3.0) we will likely release another smaller update in the meantime.