Prusa Research heeft versie 2.9.5 van PrusaSlicer uitgebracht. Dit programma zorgt ervoor, simpel gezegd, dat een 3d-ontwerp zo goed mogelijk uit een 3d-printer komt. PrusaSlicer is opensource en beschikbaar voor Windows, Linux en macOS. Het wordt primair ontwikkeld voor Prusa's eigen printers, maar bevat een groot aantal profielen voor printers van andere merken. Sinds versie 2.9.4 zijn de volgende veranderingen en verbeteringen aangebracht:
Bugfixes with respect to 2.9.5-rc1.Translations
- macOS specific: Fixed a crash when logging out of Prusa Account.
Improvements with respect to 2.9.5-beta2
- Updated ES dictionary.
Improvements with respect to 2.9.4
Configurable toolchange ordering: There is a new config option in
Print Settings -> Multiple Extruders -> Advanced -> Toolchange Ordering. It configures whether the number of toolchanges should be optimized by starting each layer with the same tool that the previous layer ended with (which is how it worked before), or whether the sequence of toolchanges on adjacent layers should be exactly the same (if possible). The latter means there are more toolchanges, but multicolor models generally look better because previous layer has time to cool before being printed on.Moved couple of SLA parameters to Expert mode.
Bugs fixes with respect to 2.9.4
- In previous versions, SLA support slices were generated by using core slicing algorithms on their 3D meshes, which often took a long time because the meshes are not always slice-friendly due to self-intersections and other defects. Because the supports are composed of cylinders, spheres and cones, the resulting slice is made of conic sections (and their parts). PrusaSlicer now takes advantage of this and calculates the slices analytically, which is typically much faster.
- Instead of storing all slices for the SLA supports in memory, the slices are now calculated on-demand during rasterization step. This means that only several SLA support slices are in memory at a given time, which reduces memory footprint. This and the preceding improvement allow PrusaSlicer to finish slicing of many projects where 2.9.4 ran out of memory or the user out of patience. The time speedup is especially noticeable with heavily supported models, where it can be more than twice as fast when compared to 2.9.4.
- Added material overrides for these SLA print settings:
faded_layers,support_critical_angle,support_max_bridge_length,support_max_pillar_link_distance,pad_wall_slope,support_small_pillar_diameter_percentandsupport_max_bridges_on_pillar.- Access token exchange with Printables is reworked.
- Maximum print height check in SLA now accounts for tower hop height.
Infrastructure
- Linux specific: Fixed crash in webview in a specific scenario (#15343).
- Fixed a small UI glitch in SLA tilt parameters - options were not graying out as they should when
Use tiltwas toggled.- Fixed incorrect tooltip on "custom parameters" fields (#15033).
- Fixed a rare crash in Config Wizard
PrusaSlicer 3.x status
- Linux specific: Flatpak runtime updated to GNOME 50 (#15345).
Many of you know that we are working on a bigger release (PrusaSlicer 3.0.0), and you are probably eager to get your hands on it. We are sorry to keep you waiting and we admit that the work is taking longer than expected. There is massive amount of technical debt that we need to get rid of to allow future maintenance of the application. We are now fully focused on that, along with developing new features.
We are also sorry that we are not very active in our GitHub issue tracker lately - for the same reason. We plan to get back to it when the new slicer is released and make things right again. We hope that the work we are doing now will allow us to release more frequently in future and get back in touch with our community.
At this stage, we can confidently say that the 3.x groundwork is well in place and most features are ported. We are currently finalizing the UI and bugfixing. The time to release it now counts in weeks (although there may be more than four). The previous time estimates we worked with internally proved not very accurate, so we will rather not be more specific now.
