Why don't you use Cura slicer?
-
I use the new version of Cura (released a few months ago). It's far better than the old versions and has a level of customised that the older versions did not. It still annoys me at time, but then so do the other slicers.
The next big feature it needs (which would make it probably the best one out there IMO) is the ability to manually edit and place support (like s3d)
-
@bot:
Three large things stand out to me, without having to think that much about it (I'm sure there is more, if I think long and hard about it).
-
workflow. Last time I used Cura seriously, it was in the 15.xx releases, but still the workflow isn't that much better in the new version. It's not that S3D is perfect, or even good, it's just better than Cura in terms of managing the models , the parameters, etc.. It's a mix of GUI and stability that S3D offers.
-
large models/gcode files. I ran into problems with Cura not able to slice models with many polygons, or save resultant gcodes of large size. (10+ million polygons, 750+ Mb filesizes. While S3D is far from perfect in this area, it's at least possible to slice and export gcode of insanely large models.
-
point and click support placement. I find the
S3DCura support features rather lacking… they aren't as smart and tuneable as they (developers) think they are, but they can get the job done. I wish the autmatic placement was better, and I wish they could be configured more (in terms of xy offset distance and layer separation causing problems with changing slope angles, among other things)
I would use Cura if it could "solve" these three issues. I would LOVE to use cura if it solved these issues.
- Let's start slicing the split second you pull a model in….oh no, you can't suspend processing while you rotate it a few degrees. It MUST be clunky. We see your 32 Gigs of RAM , 8GB NVidia and fast processor...but we've managed to dog it all down anyway.
I agree 100%. I have a UM2+ and use Cura for simple things on the UM or other (3) printers. I do scanning professionally and I too have run into large (watertight & verified good) STLs not slicing or not slicing properly, with no rhyme or reason why.
The last version I have used and printed with was 15.06. The newer versions got fat and clunky. The workflow got dumbed down in a real dumb way. It's just cumbersome to use now. So for quick & dirty hurry up and get her done, I use 15.06. Anything that is mission critical or need more horsepower to slice goes through S3D.
I tried Slic3r and hated it - reminded me of CAD on DOS. Too slow, too clunky and I have no idea why people like it...but that's another discussion. From what I understand it has a lot of unique features and tweaks, so maybe I'll look at it again...but with S3D I don't have a real reason to do so at the moment. Well worth the $149.
-
-
I worded my post poorly, but I did mean that I find S3D support lacking… but that it's still better than Cura. I've worded this post poorly, too, so I'll just stop adding to the confusion.
-
@bot:
I worded my post poorly, but I did mean that I find S3D support lacking… but that it's still better than Cura. I've worded this post poorly, too, so I'll just stop adding to the confusion.
Wait…like structural support or customer support? (please not athletic support...)
I thought you meant structural, which is pretty good but there are times when CAD drawn support is better with a .15mm Z gap.
-
I'm on a roll with my wording…
Structural support. It's definitely good, but it could be made better.
Though, now that you mention it, the customer support leaves a lot to be desired too.
-
I stick with s3d out of laziness. If a print doesn't require support, cura looks about equal. S3D just slices faster, and I'm used to using it.
If cura was smart enough to detect, on a per island basis, if there are overhangs, and not do retracts on them when possible, I'd look at switching in a hearbeat. It's the #1 bit of logic I can't believe no slicer has yet.
(Setting a seam location / direction doesn't help on prints with multiple islands, or overhangs that shift in direction across a print).
Bonus point if it knew to prefer inside corners for retract point. Another bonus point for avoiding travel over islands. Two bonus points if it knew not to travel over overhangs (since that's the most likely spot for curling, and therefore a collision resulting in a layer shift)
-
@bot:
Though, now that you mention it, the customer support leaves a lot to be desired too.
Customer support for S3D leaves everything to be desired. For a 150 USD product that competes with free products, I expected to get reasonable support and perhaps attentive updates for my money. I didn't. At least most of my issues had resolutions posted by USERS of the product on various forums.
Don't get me wrong - S3D is a good program, but it does have problems and it feels as though the company doesn't mind it having those problems. My mistake was that I wasn't still in my 2 week "return period" when I asked for support.
As for Cura - I used a version 15.something, and it was okay. When I moved to a dual extruder machine, I also changed slicers to one that many suggested as being good for dual extruder setups. Since then, I tried a newer version of Cura (I think I recently tried 3.something?) but it was, as others have mentioned, very… clunky. For the price, it's a great slicer. However, when I have S3D already paid for (and I've already learned most of it's quirks) it's hard to use a different product that has a different workflow and different quirks.
Perhaps when I find something I need my slicer to do, and S3D doesn't do it (but Cura does), I'll take the time to properly re-evaluate the newest Cura version and give it a fair trial.
-
Slic3r has multiple extruder support and also you can set temp/layer height differently at different points in the model.
So if you have something that is fairly detailed at the bottom, then simple in the middle, and complicated at the top (think of a greek or roman column) you can have it print .15 at the bottom, .3 in the middle, and .1 at the top.
-
Regarding S3D customer support/software support; I don't expect anything other than web support for a measly $149. I've been upgraded for free a number of times, it's never crashed on me even with 300Mb STL slices and they don't ask me to pay maintenance fees, unlike my professional software suites do/have. They cost me $7k/yr for the privilege of getting support if you need it and free updates to fix bugs they are responsible for anyway. I'm grateful S3D comes at such a low price. Plus, I have to research and read every other blessed thing in life, what's one more thing to figure out?
-
I would try cura again if there was a utility to import an FFF profile from S3D. I have a lot of time tweaking my profile and the time it takes to port these settings to another slicer is more time than its worth. S3D is printing just fine for me.
-
I do a ton of multicolor prints - keychains, etc - that I design around changing filament at a certain layer. In Slic3r I can find that layer in preview and it tells me the Z height so I can search for that in the gcode and insert an M226 pause. Cura does not have that ability in the new version that I have found, just a layer number which is not nearly as easy to figure out. Yes it can, but…
That's a big one for me, and seems like it would be an easy addition to show layer number/mm or at least configure that.
-
1. No slowdown when printing bridges.
2. Too much options. -
I drop Cura some moths ago because when printing perimeters, it prints one wall at a time, instead of printing all walls of the first perimeter, then move to the second perimeter and print all its walls, and so on…
It does not matter for any layers (except time lost), but on the first layer, it tends to tear off the wall when moving towards the second perimeter. If you have small perimeters, then you get a crappy first layer.
I asked on the forum to change that, and I was told it was not possible because of Bowden (don't remember exactly, but it was non sens to me).
At least, if it was able to slow down on small perimeters, it would no tear off the wall. But it does not... So, user has to slow down the entire first layer at a ridiculous speed, even non-printing speed.
Second think I don't like is the GUI: why spending so much time in re-writing a complete graphic lib? Why don't using Qt basic tools? It is ugly, not really handy (rotating the part!) and it takes hours to start. And it is a 100Mb executable!!!
That's why I switched back to Slic3r.
What Cura does well is support; Slic3r supports are crap.
-
I use CURA 15.4 for my older printer.
Everything is configured, it just works. It's nice and I don't have the courage to change slicer for it…I used Cura 3.1 for my newer printer and I prefer Slic3r PE.
The main problems with Cura are:
- Relative extrusion that is not really explicit
- Bridging parameters that can't be modified
- No manual support
-No easy way to change the Jerk and Accel parameters to have a more precise Time Estimation - No small perimeters parameters (that was the deal breaker of Slic3r for me).
But Slic3r is not really better, it's just different, with other quirks and good points.
I agree with FMA:
@fma:What Cura does well is support; Slic3r supports are crap.
One very positive point of Cura is the Ironing feature. It's a nice implementation…
Cura is free, as Slic3r and it's a very nice feature too. ^^
-
Thanks for all of the responses, keep them coming. Some valid points have been raised (and also some misunderstandings).
Cura comprises the GUI front end which is written in Python and the actual slicer itself which is a C++ program. The slicer
(CuraEngine) is quite fast, what causes most of the slowness in Cura is the Python GUI. Personally, I only work on the code for CuraEngine and having nothing to do with the GUI but I know they are putting great effort into improving it. However, it's probably never going to be able to handle huge models as well as other slicers that are written completely in C, C++, etc. BTW it is quite possible to use CuraEngine without the GUI front end and I know people drive it from scripts.I am hoping to meet some of the GUI developers next month and so will pass on the points that are being raised in this thread. I know that some of these are being worked on already.
-
Mostly stopped using it because it didn't support Z offsets for the bed. Although I have S3D I much prefer to use Slic3r PE.
-
@fma:
Slic3r supports are crap.
Which version are you using? I didn't use supports with Slic3r for a long time because they were junk, but have been using them again with Slic3r PE and they are working pretty well IMO.
-
@fma:
Slic3r supports are crap.
Which version are you using? I didn't use supports with Slic3r for a long time because they were junk, but have been using them again with Slic3r PE and they are working pretty well IMO.
+1
-
I used the old cura, did not like the new interface and moved on to Slic3r PE.
Yes supports are not the best feature in Slic3r, whenever I need to add manual supports, I modify the STL in
meshmixer which works quite well: -
Thanks for all of the responses, keep them coming. Some valid points have been raised (and also some misunderstandings).
Cura comprises the GUI front end which is written in Python and the actual slicer itself which is a C++ program. The slicer
(CuraEngine) is quite fast, what causes most of the slowness in Cura is the Python GUI. Personally, I only work on the code for CuraEngine and having nothing to do with the GUI but I know they are putting great effort into improving it. However, it's probably never going to be able to handle huge models as well as other slicers that are written completely in C, C++, etc. BTW it is quite possible to use CuraEngine without the GUI front end and I know people drive it from scripts.I am hoping to meet some of the GUI developers next month and so will pass on the points that are being raised in this thread. I know that some of these are being worked on already.
Good point. I have not tried the very large models through the cura engine without the python GUI.
I do actually like the slicing engine of cura, though it's not perfect (like none of them are).
Thanks for the interest here, and your contributions to open source software.
