If you own a desktop 3D printer, you’re almost certainly familiar with Slic3r. Even if the name doesn’t ring a bell, there’s an excellent chance that a program you’ve used to convert STLs into the G-code your printer can understand was using Slic3r behind the scenes in some capacity. While there have been the occasional challengers, Slic3r has remained one of the most widely used open source slicers for the better part of a decade. While some might argue that proprietary slicers have pulled ahead in some respects, it’s hard to beat free.
So when Josef Prusa announced his team’s fork of Slic3r back in 2016, it wasn’t exactly a shock. The company wanted to offer a slicer optimized for their line of 3D printers, and being big proponents of open source, it made sense they would lean heavily on what was already available in the community. The result was the aptly named “Slic3r Prusa Edition”, or as it came to be known, Slic3r PE.
Ostensibly the fork enabled Prusa to fine tune print parameters for their particular machines and implement support for products such as their Multi-Material Upgrade, but it didn’t take long for Prusa’s developers to start fixing and improving core Slic3r functionality. As both projects were released under the GNU Affero General Public License v3.0, any and all of these improvements could be backported to the original Slic3r; but doing so would take considerable time and effort, something that’s always in short supply with community developed projects.
Since Slic3r PE still produced standard G-code that any 3D printer could use, soon people started using it with their non-Prusa printers simply because it had more features. But this served only to further blur the line between the two projects, especially for new users. When issues arose, it could be hard to determine who should take responsibility for it. All the while, the gap between the two projects continued to widen.
With a new release on the horizon that promised to bring massive changes to Slic3r PE, Josef Prusa decided things had reached a tipping point. In a recent blog post, he announced that as of version 2.0, their slicer would henceforth be known as PrusaSlicer. Let’s take a look at this new slicer, and find out what it took to finally separate these two projects.
Revamped User Experience
The interface for Slic3r, and by extension Slic3r PE, wasn’t exactly the high water mark in terms of design. It was certainly functional enough, but it was never designed to be pretty. Since Prusa is in the business of selling relatively high-end 3D printers, it’s not hard to see how the spartan look of Slic3r could be a bit of a problem.
So it’s little surprise that the biggest user-facing change in PrusaSlicer is a completely new interface. It’s familiar to long time Slic3r users, but at the same time has a much more modern feel. There’s a greater focus on performing common tasks with vector icons inside the 3D preview view rather than having to dig down into menus to find them. The side panel now has a tabbed layout which allows the user to select how many options they want to see depending on their skill level. In general, PrusaSlicer is now a bit reminiscent of Ultimaker’s Cura slicer; which seems fitting considering both companies are trying to develop easy to use (and support) slicers for their customers.
For long-time Slic3r PE users who might think the new look of PrusaSlicer is just a coat of fresh paint, there are plenty of usability improvements and tweaks you’ll notice while using the new software. For instance, the real-time estimate of print time and cost is a huge improvement over previous versions where you had to slice and export before you’d get that information.
A New Approach to Supports
For models with complex geometry, printing support structures is something of a necessary evil. Automatic support generation is a standard feature in every slicer out there, but on some models, it can get confused and produce sub-optimal results. Over the last couple of years, proprietary slicers like Simplify3D have tried to address this by implementing custom support structures that the user can place wherever they want.
The PrusaSlicer approach is something of a middle-ground. Supports are still generated automatically, but the user can easily mask out areas where they don’t want supports to be generated. Alternately, you have the ability to disable automatic support generation except for within specifically designated areas.
In this example, you can see how the automatic support generation would fill the inside of the part with unnecessary and difficult to remove support structures; wasting plastic and making part cleanup harder than it should be. But by designating a specific zone in which support structures should be generated, this issue can be avoided.
Make no mistake, you can get yourself in trouble easily with this function if you’re not fully tuned in to the strengths and weaknesses of your printer. But that’s often the price to pay for this sort of fine-grained control.
The Power of Light
With the announcement of their SLA printer last year, Prusa found themselves in need of a slicer that could support this vastly different 3D printing technology. Rather than create a second slicer, they decided to start implementing support for light-based 3D printers directly into what was then still Slic3r PE. Since most of that work happened in the alpha and beta builds of Slic3r PE, PrusaSlicer represents the first time a large portion of this SLA capability has been available in a stable release.
In fact, Josef Prusa claims that upon its release PrusaSlicer immediately became the most polished and complete open source SLA slicer available. That seems a bold claim, but we have to admit we haven’t seen many entries into that particular niche to compare it against. Homebrew SLA printers are far less common than their FDM counterparts, but with the cost of the principle components coming down and now an arms-race in terms of the open source tools to drive them, perhaps that will soon change.
In with the New, Out with the Old
While the core of Slic3r was written in C++, the high-level components including the user interface were done in Perl. According to Josef Prusa, this combination has proven to be a challenge to maintain over the years. Citing difficulty in finding contributors who are well versed in the language, as well as compatibility issues with the wxWidgets user interface library, the decision was made to start rewriting these legacy Perl components in C++.
On the whole this transition has been smooth, but at least one feature did end up on the chopping block because of it: USB printing. If you prefer to keep your printer physically tethered to the computer, you’ll need to stick with Slic3r PE for now. Currently, PrusaSlicer will only generate the G-code. You need to get it onto your printer with something like Printrun, via SD card, or have OctoPrint setup so you can do it over the network.
Your USB cable isn’t the only thing being put out to pasture with the release PrusaSlicer. Not long after creating Slic3r PE, Prusa started work on something of a “Plan B” slicer: PrusaControl. Believing that current slicers were too complex for beginners, PrusaControl was positioned as a bare-bones tool that would get you printing with as little hassle as possible. But with the ability to adjust the interface of PrusaSlicer depending on the user’s skill level, the decision has been made to officially abandon PrusaControl.
Looking Ahead
While PrusaSlicer has a new name and a long list of improvements, at its core it still runs on Slic3r. Just as importantly, it’s still released under the same open source license. That means that anyone is free to try their hand at porting over these new features to vanilla Slic3r if they were so inclined. It might be more difficult now that Prusa is on a mission to rid the codebase of Perl, but it’s certainly not impossible. On the flip side, Josef Prusa says his team has every intention of merging in upstream Slic3r fixes and changes, so long as they make sense to include in PrusaSlicer.
In the long run, this move should end up benefiting Slic3r developers as much as it does anyone at Prusa. For one, the name change should keep them from getting hounded with bug reports that don’t apply to their code. In time, they may even find that with Prusa leading the charge on the user interface side of things, they can focus their efforts on improving the core slicing engine.
One thing is for certain: this is how open source is supposed to work. A successful company taking an open source project, adding their own resources and talent to it, and spinning it off into a new open source project is something worth celebrating. We can argue about the semantics of the name change, and the potential fracturing of the userbase, but in the end the code is out there and the community as a whole stands to benefit no matter who’s name is on the top of the page.
Love reading articles like this. Haven’t dived into the 3D printing world yet but appreciate being able to stay up on what’s going on in this space.
“That means that anyone is free to try their hand at porting over these new features to vanilla Slic3r if they were so inclined. It might be more difficult now that Prusa is on a mission to rid the codebase of Perl, but it’s certainly not impossible.”
Still have the original problem. Finding enough programmers well versed in Perl. Doubly so skilled in Perl AND C++.
It’s probably slightly easier to find perl coders who can read C++, than ones who can write in both languages. TBH, the real problem is probably that perl is a dying language.
perl the write only language; the language that looks identical to line noise eg. ‘ent(#*&1G@%)#NT#_H%)I,o0]’ could be valid perl.
perl is just so old that even if one can write maintainable perl, there is nothing to enforce it, or stop one from writing cryptic magic bullshit.
backwards compatibility may be a problem for C/C++, but is an albatross for perl; coding standards have moved on and perl has some old shit it still supports
A lot of cryptic code possibilities in C, Python with its weird blank spaces, any language.
Well written perl is just like any other well written language. There are some complex scripts in bash that look like a binary file got mixed with the code.
An as the article points, the core is in C++, and the GUI in perl, so they need coders proficient in just the language of the part they want to change. If as the article implies, they want to work in the core, then that would be C++ programmers only.
One can certainly write maintainable Perl. I always “use English;” (https://perldoc.perl.org/English.html) and apply the same techniques that I use for other languages (for example, identifiers are meaningful and not abbreviated, nouns or noun phrases for data, verbs or verb phrases for functions).
As for enforcement, static analysis tools (https://metacpan.org/pod/Perl::Critic) can flag cryptic magical incantations. Of course, the team must maintain the discipline to use such tools and heed the recommendations.
That said, nowadays I use JavaScript for things I once would’ve done in Perl.
I’m as anti-Perl as the next hacker, having left the language in the late 90s and never looked back. BUT, the Slic3r is the absolutely most readable Perl I’ve ever seen.
You think that’s unreadable? Forth I 1 time used!
about the supports : i don’t understand why each single support has to start from the bed. it would save some time and material to have only a few columns starting from the bed and after, expanding ” Y style” to cover the required area at a given altidude. almost like a tree : one trunk, many branches.
is there any slicer software that can do this automatically or in which i could construct this type of structure for the supports ?
i know i could build it as “lost” part of the object itselfbut hey …..
Meshmixer can be used to create supports like this, and you’re right, it does save time and material to do a “branching tree” sort of structure rather than a big block. That said, they can be a bit finicky.
Flashforge also uses the same Technique as Meshmixer for Supports http://www.flashforge.com/creator-pro-3d-printer/software/
Sounds a lot like “Tree Supports” in Cura (3.2 and above), you can find it under Experimental options. Like all support options, sometimes it makes sense to use, and sometimes it doesn’t. Experience (usually failure) will inform that decision.
What makes you think it will save time and material to build a tree support?
Non-contact support is extremely sparse, just one extrusion width spaced 2-5mm apart. Its a straight path so you can extrude at 150mm/s or faster.
A tree might look like it has less outer volume, but those kinds of thin branches have cooling problems, tons of direction changes, and need to be denser.
The tree support in Cura starts as a large hollow trunk and builds/branches from there. It definitely uses less material, and by extension, less time.
The problem with branching is how difficult it is to create thin plastic trees. The nozzle tends to drag and push little columns of plastic, as well as the nozzle being too large to make columns worth automating. There would have to be a revision specifically for fdm printing, as the resin printing supports simply won’t work reliably. I think you are correct that we need a different support system based on branching or maybe something like inverted V’s in order to speed up printing supports. Hmm, maybe an arch with a slightly separated blob for the keystone could work…
I’ve designed “tree” supports in a few of my designs that printed and worked extremely well. They don’t have to be thin, they just have to be thinner than a solid vertical column. Branching isn’t just to I save print time and material. Sometimes you need support that doesn’t have build plate directly under it and don’t want to build support on your model. I like Meshmixers customizability in their supports, and it really nails ti for the types of supports I just mentioned, but I hate the support to print surface interface. It’s either sag city or stuck to the part. Or both.
Slic3r PE vs. Simplify 4.1
Prusa’s slic3r is free and S3D is paid (150$) both are providing option define different infill ratio for multiple zones in the model.
S3D is much more faster (sometimes 40minutes or more ) S3D is proviiding option define retraction points (less visible part of model)
Prusa is offering Hilbert’s curve infill S3D is providing many other patterns.
Also new CURA 4.0 is quite good, but I have to say noone is perfect one slicer is good in VASE mode other not :P
Try slice octopus model in Slic3r PE and click on progressbar it will hang up :P
We are testing it from first day ;)
Absolutely nothing you’ve written matches with my experience of slic3r PE, which I use every day. Perhaps you need a fresh install or something?
Different users may have different experiences with slic3r PE and bug may affect only in specific scenarios.
Be lucky you are not affected probably its memory leak becouse we sliced many models huge models 35x30cmx25
without restarting Slic3r PE. Clean boot and run ist not hanging up. (thats my experience)
if you are not agree with me, that’s fine… but i absolutely can’t agree with your possition becouse my experience is different. (becouse different HW, OS, Printer profile etc…. )
Here is the fact https://imgur.com/a/Ap4dNUh ( for non Czech speaking visitors of this page) There is a MessageBOX with
message “Aplication is not responding” … (This took a 30-40minutes we leave program long time end but it utilize CPU and crash finaly.)
My opinion it’s a problem of algorithm when is model faulty or many open holes slicer is running out of model and stuck.
(developers may confirm or not if is there any limit if is “ray” outside of model) similiar scenario like in huge recursive Floodfill algorithm without limits.
BR DXR :P
Just uncheck avoid crossing perimeters :)
“no matter who’s name is on the top of the page.”
I was under the impression that this was the main reason they forked in the first place.
Been using Slic3r PE even before I owned a Prusa printer. I think the interesting question at this point is: does Slic3r vanilla have any compelling feature or goal that PE is missing? If not, it may die off. (Maybe usb support counts)
Prusa’s firmware is even more interesting. Forked from the ubiquitous Marlin but deeply rewritten. Using fast interger math rather than float, for example. I’ve been expecting (but haven’t seen) forks to support non-prusa printers.
The most compelling thing for me is the idea that you can generate supports from plastic all the way up to just below where the support hits the piece, then do just those layers in water soluble.
This is the sole reason I’m seriously considering getting the latest Prusa printer and the multi-material upgrade.
Prusa’s multi material system wastes a lot of material in the purge block, which gets printed solid. Every layer of print gets a layer on the purge block, even when not changing materials. It’s least wasteful for printing large items or filling the bed with several identical small items. To print one small item the purge block can end up using more material than the item.
Far less wasteful would be a purge chute and nozzle wiper that would be used only when changing materials. Pretty much like inkjet printers have always used to spritz a little ink to ensure they’re primed for printing, a thing to catch and soak up the waste ink, and a nozzle wiper to keep back spattered ink from smearing the paper.
This is something I knew, but hadn’t fully processed when I started my upgrade to multi material. Now I’m wondering whether I should finish up or not.
I understand why the purge block needs to be printed to at every layer, but is there a technical reason it can’t be sparse, even 50%, when there isn’t a filament change? Or have we just not made it that far in the development yet?
the wipe tower is as sparse is it can get, and you can even wipe into infill or into another object.
The previous poster stated it was printed solid, even when there is no filament change. I understand that if a filament change occurs, the purge extrusion needs a substantial volume of filament extruded to ensure that there is pure filament coming out, and solid is the most space efficient way to do this. If there is no filament change, you don’t need to *purge* anything, you just need to have a filler layer of some sort for the next purge block layer to reliably adhere to. I wouldn’t think a non-filament-change purge block layer needs to print solid, it seems like that could be very sparse, say 10%-15% – similar to infill – perhaps with a perimeter to ensure a good wipe. then if the next layer is a filament change layer that needs to be solid, it will be similar to printing the first top solid layer over infill. If it’s not a true purge layer (same filament) it will just be like infill printing over infill. Am I missing something?
Purging into the infill would be perfect if you have enough infill or if your materials allow for it – purging dissimilar plastics (disolvable/flexible mixed with PLA/PETG/ABS/whatever) as infill probably wouldn’t win a durability contest, though it probably wouldn’t affect it as much as I think it would.
As an industry-widely-adopted-FOSS-project maintainer, I’m really not happy about how this article portraits forks by commercial entities: the optimum way is *not* having a fork to “optimize the software for your device”; the proper way is to contribute a fair and easy to choose (or not choose) integration **upstream**.
In other words, there was no reason to fork a working, active project instead of contributing changes upstream, or at the very least re-merge upstream changes, so to stay as compatible as possible. That would be playing the field fairly.
Were not talking about a couple pull requests here. The changes in PE almost completely reinvented Slic3r, for those kind of changes to get pushed through upstream, Prusa would have effectivity had to take over the whole project.
Now rather than Prusa strong arming a popular OSS project to fit their needs, the user can now chose for themselves which one to use.
I do not see that working. They decided to ditch the perl interface, and rewrite everything in C++. How would that go ? Should they just force the rest of the project to accept it and start using this ? And about other changes, would have to be forced upon the others also. Or the software would be turned into a one-size-fits-all , with a lot of compromises and patchwork code to make things work. Not the path to a quality product.
Prusa’s codres may do a functional C++ job, but their code produces a lot of warnings. Mainly warnings about compairing signd and unsignd variables.
But there are dozen other things, wrong indent and others. A pull request about repairing indention and making the code better readable is reverted.
See:
https://github.com/prusa3d/PrusaSlicer/pull/2314
https://github.com/prusa3d/PrusaSlicer/pull/518
https://github.com/prusa3d/PrusaSlicer/pull/517
I think it is also not a path to a quality product.
That is more of a problem with many programmers, who are allowed to ignore warnings when learning, and carry that behaviour with them later, than with the prusa project.
But I agree with you, a code that compiles cleanly, with no warnings, would be preferable.
As for indents and the like, it gets into too much of a personal preference to result in a consensus. If at least the prusa team can keep it consistent among them, it should already be considered good enough.
You provided a pull request, that adjusted spacing and indents to your liking, or to the liking of your IDE or editor.
Regarding the compiler warnings, we inherited some and we surely added some. Judging from your comments, you don’t have much experience with real world software engineering. The day has 24 hours and there is a pressure to deliver. You either have a project free of warnings, or the warnings will only grow. You are right that we shall fix the warnings and I personally am slowly doing it along the way. It would be great to fix the warnings in one session, but first there was not time for that, second there is a risk that one breaks something, which will be difficult to track. You certainly don’t want to do that close to a release date.
You’re right. I’ve no idea what Software engineering means. I’ve only written some tiny things with the arduino ide, and that was more copy and paste with try and error system, but
I’ve compiled a lot, and learnd from doing mechatronics:
Messy work will fail, it’s just the question of time. When time is money then you have to work clean and accurate, failing and searching for the cause costs more time than make it clean and propper.
The fear of the risk of breaking something that is difficult to track seems there is a level near to the break even.
I’m happy that PrusaSlicer exists, it work’s and does it’s job. But I can’t compile it propper and install it without some issues, so I’m thinking to move away from it and find an other slicer which do this job. But I had not found one yet with my expected functionality.
> the optimum way is *not* having a fork […] the proper way is to contribute […] **upstream**.
Very true. Forking should always be the last resort and taken only if upstream becomes reluctant or unresponsive. Forking all over the place without need produces just more mess.
Also the article calling forking “Stallman approved” is pretty bold. Stallman and his team takes great care to avoid a need for forking and if it happens nevertheless (as with egcc), they work on joining both paths back together. That’s why there’s just one Bash, one gcc, one Emacs, one Apache, one Linux kernel, and so on. Even Ubuntu isn’t a Debian fork, Ubuntu inherits from Debian as a layer on top of it.
Just because Github claims forking to be a natural and productive strategy doesn’t mean this is actually true.
There are no large, established, open source projects which would let a company come in and completely reinvent their product and change their culture. Not going to happen.
Creating a new variant of Slic3r was the only way these sort of sweeping changes could have been made. Considering the alternative, Prusa developing their own closed UI in C and just using the Slic3r engine as a plugin (which is what other slicers are already doing), this is absolutely the best way to go.
If they were eventually merge back together (which is certainly not impossible), then the result would almost certainly be Prusa taking the lead and the original culture of Sli3r being lost. Not sure how that’s preferable.
You can already selectively place support using the slicer pe support blockers and enforcers functionality
There was basic support for it if you knew where to look and enabled it, but now it’s properly integrated into the new UI.
Note that contrary to popular assumption you can run OctoPrint directly on your own computer rather than needing to run it over the network; that’s how I’m connecting to my printer with mainline slic3r right now and it works way better than slic3r’s built-in USB print server anyway.