PrusaSlicer 2.7.2-alpha2

github.com/prusa3d/PrusaSlicer/releases/tag/version_2.7.2-alpha2

Summary

This is the first public alpha release of PrusaSlicer 2.7.2 (alpha1 was not public). This release introduces improvements of multi-material segmentation algorithm, improved M600 G-code handling, SLA overrides and many more improvements and bugfixes.

To let you enjoy the alpha without worries, the alpha builds save their profiles into PrusaSlicer-alpha directory, so you may use the alpha side by side with the current release without ruining your production configuration. The alpha will ask whether it should import a configuration from previously run PrusaSlicer versions on the first start.
Multi-material segmentation improvements

In PrusaSlicer, we use Voronoi diagrams as part of several features such as 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. Unfortunately, it rarely produces a non-valid Voronoi diagram for some input polygons (the graph is not planar, missing vertices, etc.), which could cause a crash of PrusaSlicer, artifacts on external perimeters with Arachne or spilled layers with multi-material segmentation.

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 tight 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 (#10632).

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

voronoi
Color change (M600) improvements
Place the color change (M600) after moving to the next layer and position

Previously, PrusaSlicer placed the color change (M600) right after the previous layer was finished. The default implementation of M600 in all firmware will return to the position before M600. As a result of this behavior, the extruder with changed filament returns to the place that was printed with a previous filament and could create a blob with new material at that position (#2672).

Our community, especially @nohus, came up with a solution (#9036) 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 PR.
Selecting the correct tool before performing a color change (M600) on multi-tool printers

Previous implementations of color change for multi-tool printers left picking the right tool on the firmware and user. Also, M601 (pause print) was placed instead of M600 (color change), which is how it was intentionally implemented for MMU. That case issue especial on our Prusa XL printers (#11516, #11517, #11600, #11792).

This proved to be insufficient for multi-tool printers, mainly because there is a special sequence of extruder movements that need to be done before parking the tool, and PrusaSlicer depends on it.

Based on this, we implemented picking the tool on which the color change will be performed. After the color change, it picks the previous tool (if the tool for which the color change was performed no longer prints on that layer).
Along with this, we are now emitting the M600 (color change) for multi-tool printers instead of the M601 (pause print).
Ramping travel improvements over PrusaSlicer 2.7.1

In PrusaSlicer 2.7.1 we introduced ramping travels together with helical layer changes that both should mitigate stringing and oozing especially on long travels between objects. In this release we continue improving the ramping travels.
Replace helical layer changes with proper ramping travels

Based on user feedback, it turned out that helical layer changes weren't good enough and sometimes even caused visible blobs or artifacts on external perimeters of prints (#11940, #11800).

We thus decided to replace the helical layer changes with the ramping profile previously only used for travels. This change ensures that the stringing is still mitigated without the disadvantages of the helical movements.
Smoothing of ramping travel moves

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 slow down of the movement in the XY plane which is not necessary.

Under the right circumstances this issue can be mitigated on Marlin-based printers by smoothing the ramping travel moves. PrusaSlicer now automatically employs this slight optimization when applicable. This further helps to prevent stringing and may even slightly improve print times by a very small amount.
Lift before obstacles

During long travels above already printed parts of models, ooze material may be so long that it can be wiped on the perimeters of other objects. Increasing the Z-hop distance could reduce this issue, but it also increases the print time when it isn't needed to do such a big Z-hope.

We implemented the lift before obstacles feature that ensures that during crossing already printed objects or parts the nozzle will be at chosen distance to not wipe oozed material on perimeters of that object.
SLA overrides

PrusaSlicer classifies the SLA parameters into three groups: Print, Material and Printer parameters. This parameter classification is certainly artificial and not flexible enough. We are now introducing a concept of Material Overrides in SLA, which is mimicking the Filament Overrides feature known from FDM slicing (introduced in 2.1.0). It 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.
image
Other improvements with respect to 2.7.1

Windows specific: The cut tool sometimes produces non-manifold meshes. This situation is now detected and the user is advised to use Windows repair algorithm on the resulting objects (#7243).

Bug fixes with respect to 2.7.1

Fixed incorrect partial arrange in certain cases.
Fixing arrange issues with aligning to unprintable objects when doing Shift+A.
Fixed arrange which sometimes put the wipe tower slightly out of bed (#11367, #11410)
Fixed UI glitch when setting object dimensions to extremely high values (#11617).
Fixed a bug in generation of brim and skirt preview in the preliminary G-code preview (#11821, thanks to @supermerill)
Fixed an issue Ctrl+Shift+Tab shortcut, which incorrectly collapsed sidebar (#7799).
Fixed wiggling of Rotate gizmo when moving an object in certain cases.
Fixed missing updated when moving through dropdown items using keyboard arrows (#11817).
Improve filtering of special characters on Klipper EXCLUDE_OBJECT labels (#11802, PR#11813 by @jschuh - thank you).
Fixed layer change color dialog opening off screen (#10419).
Fixed occasional crash during thumbnail generation for SLA printers.
Fixed slicing issues such as missing infills and similar on multi part models when sliced with object-specific settings (#11721).
In SLA mode, it was not possible to use custom file extension (configured in Output Settings).
Fixed incorrect calculation of wipe length in certain cases, leading to shorter wipes than configured.
Fixed various issues and UI glitches in text/SVG embossing (#11868, #12002).
Fixed missing update when a new printer was added while a physical printer preset was selected.
Scrolling of the window was incorrectly performed when using mouse wheel over a dropdown.
Windows specific: Drop down menus appeared outside of PrusaSlicer and could not be opened again (#11988).
When loading an object from a 3MF, the suggestion to rescale the model is not shown, because 3MFs store the information about the correct unit (unlike STL files).
Fixed an incorrect check of supported OpenGL version, which led to a hard crash when OpenGL 3.2 was not available (#12000).
When loading a 3MF for MM printer, PrusaSlicer offers to load individual models as parts of a single object. This dialog did not show up for specific geometries (#11547).
PrusaSlicer did not start on some Windows Server installations due to a missing DLL (wlanapi.dll). The library is now loaded in runtime and the respective features are not available when not found (#11790).
Fixed layout of configuration values in parameter tabs when the controls are placed next to each other.
Fixed a rare crash when switching printer profiles (#12005).
Fixed missing update when toggling "Show incompatible print and filament presets".
Fixed update of extruder dropdown when switching application color mode with SLA printer selected.
New G-code placeholders extruded_volume, extruded_volume_total, extruded_weight and extruded_weight_total (introduced in 2.6.0) did not include the volume / weight of the wipe tower. This is now fixed.
Template filament profiles did not show for custom printers in a specific case (#11991).
Dynamic speed on overhangs feature did not take into account maximal filament volumetric speed, meaning that it could violate it and speed up on the overhang.
When object name is changed, the G-code is newly reexported so the objects label in the G-code match the updated names (#8059, #12193).
Fixed a crash when loading an invalid 3MF.
When scaling a volume of a sinking object, PrusaSlicer incorrectly placed the model on the bed.
Legend in G-code preview was not automatically switched to Color Print view when color change for MM printers was set.
Z-lift was incorrectly not applied for the first travel move (#11843).

Other

It is now again possible to build PrusaSlicer without GUI (#11992).

Architecture, infrastructure
PrusaSlicer no longer uses Perl

PrusaSlicer is based on Slic3r project, which was originally written in Perl scripting language. Over the years, various parts were rewritten into C++, first the slicing core, then the user interface. We have now completed the transition by rewriting all remaining unit tests still depending on Perl into C++. Goodbye, Perl. You will not be missed.