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.
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.
Pearl, or Perl?
It's the Perl programming language (https://en.wikipedia.org/wiki/Perl). It was more popular about 20 years ago but newer languages such as Python took over.
gglockner, yeah I know. The article had initially had Perl misspelled as Pearl. They corrected it but left my comment to make sure I looked like an idiot. 😀
Norton keeps popping up with 'suspicious activity' alerts during install. I also get an ' invalid certificate' error while trying to run it. Anyone else have similar issues
Uninstall Norton. Windows Defender is good enough. You should also consider using an ad-blocker like uBlock Origin to prevent many malware delivery campaigns.
Thanks to everyone involved, great work!
We can't wait to see what you have in store for 2.8/3.0. We wouldn't mind if the multiple plates feature from Bambu Studio and OrcaSlicer was ported to PrusaSlicer, for example 🙂
Multi-plate projects would be sweet
Great job, goodbye, Perl.
YESSS. That zit after filament changes always drove me nuts. Never understood why it didn't go to the *next* point instead of going back to the *last* point. Seems like a minor change but that's a really big quality of life improvement for people that do filament swaps (either manual or automated I assume).
The "Zit" is now at the start of the next layer, the slow travel down just allows the nozzle to ooze a little more than it should.
So, since the last part of Slic3r has been rewritten, does this mean that they now can remove the "based on Slic3r" part? And if so, is it something that will be happening you'd think?
The under extrusion gap on seams issue is still not resolved 🙁. This causes many machines to print bad:
https://github.com/prusa3d/PrusaSlicer/issues/11914#issuecomment-1975125706
I'm hoping there will be more effort put into reviewing the PR:s for porting over much-needed features from the Superslicer fork (since that it's mostly dead now). Polyholes and (internal) xy-hole compensation are pretty much mandatory for accuracy in small-ish features, but having to resort to using an ancient version of Superslicer to achieve them means you sacrifice lots of the modern improvements from Prusaslicer.
When I checked, it seems like the Superslicer project has actually sprung back to life, with the developer being paid to work on it almost full time. That is good news!
Still, I stand by my point that a lot more effort needs to be put into merging improvements from other Slic3r/PrusaSlicer forks back into the main project (there are so many PR:s of this kind that have been waiting for review and been left to bitrot, so it's not from lack of community effort alone!). Having three separate forks (now including Orcaslicer) each churning out their own sets of orthogonal improvements but seldom merging any of them into each other has created a really fractured ecosystem which is frankly awful for end-users who are forced to pick sides. I've been immersed in the open-source world for decades and never saw things fracture this overtly before. It feels like a real waste of effort, when they could focus on creating one go-to slicer to benefit everyone.
A counter-argument could be that it's up to the community to create a version merging all the downstream changes into a single project. But as we saw with Superslicer for the past two years, community projects are at risk of falling really far behind and stagnate if the volunteers can't afford to work on it regularly.
Happy that this f…ing blob is gone.
My good friend MK3S+ did not do such a poop! Now I hopefully can execute filament changes on my MK4 too. Thank you guys!!
what about:
https://github.com/prusa3d/PrusaSlicer/issues/11914 ?
I bought Prusa so that I get things like this fixed and not ignored.
Next will be Bambu A1 – cheaper and just works.
is there anyone to ping about feature requests on github not being labeled as a feature request and simply getting lost in the flood of open issues?
i opened 3 feature requests in November and they are still not labeled.
I have a rare use case where the old blob behaviour is preferred (two extrusions wide text on flat surface). How do i turn the old colourchange behaviour on? New behaviour destroys the print quality on the letter that gets printed first, because of my oozy stainless steel nozzle.
Old blob was easy to skim off with utility blade and the scar such that you had to look for it to see it..