in processing a large, support-intensive model, sandcastle by kijaidesign, i noticed an immense difference between Cura ( 5.5.0) and Orca (1.7.0);
tree supports touching bedplate, settings as close as i could get them…
Cura processed for 20 minutes before i cancelled it (16 core AMD Ryzen 9 5950X)**
Orca processed it completely in under 1 minute; preview of the sliced result looked good;
i repeated this whole process multiple times, similar results
generally it looks as if the tree support process is a very cpu-intensive step
** i was monitoring the process using AMD Ryzen Master and it looked like the multi-core exchanges were all over the place…
Yes in fact I was tinkering with Cora, Prusa and kiri (which I didn’t like at all) I found Prusa to slice way faster (M2 Ultra 24/60 core 128gb ram and an M1 8/8 16gb ram) interestingly the same file sliced close to the same time on both vastly different computers, if there is a difference I didn’t notice a large difference (kijai design moon city)
The most interesting thing was they both produce different print quality. Neither was always better nor was one always the same print speed on one file Cura was faster print times (stopwatch prints) and a Prusa another.
I think that using different slicers for different things can yield better results. I have not however figured out when one is better than the other. (Kiri I dislike so much I gave up on it.) I am still using both Prusa and Cura. Same file same printer same print settings with different results and print times. The way it slices seem to be the difference.
If I remember right it is due to the languages and algorithms that each program is written in.
Cura is written in Python which allows it to be easier to modify, but it is also more archaic. Python in itself is a much slower language because of the compilation process and such.
Prusa and any other program based off Slic3r is based on C, and therefor is more complicated but leagues more efficient. C is also a much faster language because it compiles directly to machine code instead of through a bunch of translation layers. The algorithms that Slic3r uses are much efficient than those that Cura use, and subsequently is able to generate more complicated geometry much faster.
This difference in the process of how these models are processed and sliced from a software perspective also causes the difference in quality between the printed models.
When you are slicing small parts these differences are not very noticable, but once you get to medium/ large parts you can sometimes be looking at a large difference in time between the slicing of the parts as you have noticed.
if i can get cura to complete the slice of that particular model, i can then compare the gcode files; size and whatever else stands out immediately;
i suppose if i wanted to get especially anal i could use some text compare utility…
update; after cutting off a significant amount of the base , i got Cura ( 5.5.0) to successfully slice, it still took much longer that Orca; the resultant g-code file was 80 k;
using that same stl, the orca slice resulted in a file that was 95k;
imo that is a pretty big difference for basically doing the same thing;
just for grins i tried to open the g-code file from orca in cura , and it did open it after quite a bit of parse time;
orca reported an estimated 19 hours;
cura reported 24 hours;
seems orca wins on the big fronts;
the settings were as close as i could get them, scale, all same sub-speeds, temps, flow rates, layer heights , walls, supports, etc;
as far as filament used , orca reported 252 grams; cura 242 grams
I don’t have a link to anywhere that explains that but when Cura 5 came out it was a big leap ahead and many of the current slicers adopted the cura engine. Now have they changed since then, maybe. Has prusa been been upgraded/modified since then obviously so I don’t know how varied they are at this time but if it basically the same engine then it can’t be that different…
PrusaSlicer has only ever advertised being built off of Slic3r, and I believe if they made the switch to Cura at any time it would have been big news. So far I have not been able to find a single piece of information that shows that it was using the cura engine.
Even past that however it wouldn’t make any sense from a programming perspective to use the cura engine, since the 2 programs are written in very different languages if they wanted to use the cura engine for Prusaslicer they would have to go through a bunch of translation layer which would make the program extremely slow and buggy, and most likely it just wouldn’t work properly given the structure differences between C and Python.
The only real way they would have been able to implement the cura engine would have been to completely re-write the program from scratch in a completely different language, and an arguably worse one at that.
What I think is more likely is that prusaslicer just was forced to implement some of the changes present in cura 5. Many of the changes made in Cura wouldn’t be very difficult to implement, especially when they have already been successfully done with another slicer. And some of the features that were present on cura 5.0 had already been present on other parts of Prusaslicer such as tree supports for their resin printers.
If someone can provide some sort of documentation showing that Prusaslicer was at one time built off of the Cura Engine I would love to see that, and would be more than happy to admit that I was wrong. But at this time I am having a hard time believing this…
I am absofrackinglutlypositivly sure about that. It came out on several of the YouTube 3D printing “talking heads” videos when Cura switched over version 5 and shortly thereafter they announced that Prusaaslicer, an others, adopted it also. It was switch or get left behind. You can search back for it if you want, I won’t it doesn’t matter any more. Did they switch again afterwards, maybe. Did they modify the Cura engine assuming they kept it, probably. The bottom line is that it really doesn’t matter that Prusa is faster then Cura, the difference is small enough so that it amount to much anyway.
You are correct that the differences are minute at best, and that both slicers work basically the same. Definitely used to be much more of a difference, but I guess that is the great thing about open sourced work, everyone gets to learn and benefit from everyone else!
I was however curious to learn more about if they had switched to using Cura engine, this would be very interesting if they were in fact using it and I would like to learn more about that. I contacted the prusa help line and they confirmed that it seems that they have not switched to using Cura as their engine but instead have implemented algorithms and changes made in Cura 5.0 such as arachne.
I will include a link to the chat log if anyone would like to take a peek.
I just want to be clear here that I am not trying to argue with you or step on your toes in any way, every member of our community here has my utmost respect, and I am very thankful for all of your help on the forum here. You are a great guy and I love seeing your posts. I was just personally very curious to try and find out more about this as it was very interesting to me!
I have been tinkering with slicers lately. Cura, Prusa, now Bambu. It is interesting all three (Bambu and PS are the same engine) but have vastly different slicing times and different results. Different slicers with very similar settings produce different outcomes. Print times vary and results. I don’t think if you wish optimum quality you can use just one. I have not discovered when which one produces better results. Prusaslicer is covered to swift. I suspect it is why it runs many many times faster than Bambu.
Yes, I think that you could probably slice the same model with the same parameters a couple of different times using the same slicer and end up with slightly different results. It definitely would not be as big of a difference as the differences between the slicers, but you could probably see something.
Even the slight inconsistencies in the machines would be enough to cause differences in the prints, even in the same gcode file if you really look super close.
When I was tuning settings for the V400 I found the settings that were as close as I could get them to produce very different results. Then a different file would be different again. Nothing was consistently better it kept flipping one slicer than the other. Print times vary as well as well as surface quality. Slicing time is more constant, Prusa on a Mac (M1, and M2 Ultra) is always the fastest, it is close to instantly. Cura is next, Kiri is slow and Bambu studio is very slow.
How long it takes to slice is not really relevant but it is likely for me the singularly most obnoxious moment. When one slicer is faster than I can time and another is slow enough to get a cup of coffee for the same file I find it very frustrating to wait the 5 mins.