Progress update on the new Cura slicer

[Daid 306]

Hi everyone,

As some people might have read, and others might have not. I'm working on replacing the slow slicing engine behind Cura.

First a bit of history. Cura started about a year ago as a better and easier to use GUI on top of existing slicers. Back then I picked Skeinforge as the engine to use, because I knew how to get good prints out of it. And because it could slice just about anything, only a bit slow. I also left the option to use Slic3r as engine. But because Slic3r is very picky about manifold meshes I never enabled it.

Now a year later, and Slic3r is still picky, crashes on a few models that I tried. And not that much faster then Cura. Skeinforge is running on it's last breath as people are printing larger and larger models. With more and more layers.

And so people are pretty much forced to use KISSlicer or NetFabb for large prints. KISSlicer does a pretty good job. And once you get NetFabb configured it also does a nice job.

So. Now that I work at Ultimaker, and I have more time to actually do stuff. I'm doing what I said I would never do. I'm making my own slicing engine. In C++. And I'm crazy (for the people that didn't know that already).

So, what do I have? I have a working slicing engine. With:

Basics like side walls, with infill, top/bottom filling, sparse insides.

It doesn't do the strange "interface layers" thing that Skeinforge does.

It does do proper bridging like Skeinforge.

It also does retraction, combing and proper path-order-optimization. So it doesn't do a crazy amount of traveling, stays inside the model when possible.

I just added support material today. So that's one thing crossed off the ToDo list.

The thin wall problem? It's solved. Yes, it, is, solved!

There is still a lot of work to be done. It's only partially integrated into the Cura GUI right now, progress bar is not working for example. About all settings in the expert-config are missing. The new "bottom cuttoff" feature (from Cura 13.03) is not implemented yet. Retraction settings are not added (retraction itself is), cooling settings are still missing. Dual-extrusion is missing, as well as project-planner support.

And then there are a bunch of models that do slice with Skeinforge, but not yet with my new engine. So, work, work, work. But I am making awesome progress. And I hope to get a test version out to more people soon. I've send a early version to a few people. And it's been mostly positive responses.

Oh, and did I mention it is fast? I didn't measure the latest version, but so far most things slice in seconds compared to minutes with Skeinforge. So that's awesome :-)

Finally, this project has gotten high priority at Ultimaker. And it will be open-source once we have a version out. So I hope to see you all slicing at light speed soon :-)

Also, this would be a perfect place to request features ;-)

 

[codemaven 0]

Glad to hear this is progressing well. I look forward to seeing it in action.

What's the license going to be on this? Will it be released under an opensource license at some point, or remain closed?

Cheers,

Troy.

 

[illuminarti 18]

Awesome - great to hear that you are making progress with it.

Some of the things that I really like from Kisslicer are:

1) the ability to do loops, sparse infill, solid layers at different speeds.

2) What might be interesting would be to be able to print the first layer at one speed (for bed bonding purposes) and then print the rest of the solid base at a different speed, and then the top at another speed again... or at least make sure that the first solid layer over infill is treated as bridging. (Maybe SF does that last bit? KS doesn't). The reason I want this, is that I find that when I'm printing on a very solid base of plastic (as at the bottom of the print), I can easily print at very high speed (true 250-300mm/s). But that speed doesn't work well for solid layers at the top, mostly because the first solid layer doesn't properly bridge over the infill, so none of the rest work either. Printing the solid base layers very fast saves a lot of time in the print.

3) The ability to do infill every n layers.

4) Configurable limits on volume per second - slowing down if the limit is exceeded (which it can easily do especially with fast infill every n layers). KS does this. In several of the cases that I have worked with lately providing support to users with filament grinding issues, excessive volume seems to have been a key issue. (I am also considering adding this as a limit in the planner in Marlin - I think it will help a lot with reliability. New users seem to like to crank the knob all the way up to 1000%).

 

[illuminarti 18]

Oh, and regarding support... how is that going to work. Cura's '50%' under-extruded support just seems to cause problems by taking the pressure off the nozzle, so that by the time the proper print starts again, you get considerable underextrusion for a while.

 

[3d-junkie 0]

Cant wait to get my hands on your latest creation, also verry impressed that you are going up from scratch with the slicer.

I noticed in the sneak peek you gave us that you incorporated the ultimaker bed, does this mean we will be stuck with the ultimaker bed dimensions? or can we also create our own dimensions as we used to?

Keep up the good work ! :-)

 

[owen 19]

Hi Daid

I'd like the ability to do multiple things after n layers from the start but not repeat

eg.

Extrude a bit more first layer

Go slower for first 2 layers

other people like to turn the fan on after a few layers etc.

Other than that nice tops like Netfabb would be good too

Most all other abilities and settings in KISSlicer I like

I have 64 bit windows so haven't been able to use Cura yet so looking forward to it.

Happy to be a beta tester too.

Thanks

 

[Daid 306]

Owen, 64bit windows is compatible with 32bit applications, so Cura runs fine on it. (My dev machine is 64bit windows) the only thing is that you cannot use more then 2GB of memory in a 32bit application.

Illu, I've been noticing the the extrusion problem myself, it seems to depend a bit on the printer (as my home machine was printing fine with 50% support material). So I need to do some test on what works. I'm not a huge fan of support material, so that doesn't help in getting the best settings for it

3D-Junky, the platform is already in the current release, but only shows when you select the Ultimaker as printer. I have no plans to remove support for other printers, with different bed-sizes or even delta-bots (Which need to have the 0,0,0 position in the center of the bed). While Cura is tuned for the Ultimaker, that's mainly because I have one and Ultimaker pays me. But the more people that use Cura, the better it gets.

 

[owen 19]

OK thanks Daid. I've tried it twice and it crashed or something both times and then I seen here about probs with 64 bit so I thought that was my problem.

 

[tomnagel 126]

Feature request: varying layer heights.

Try to print the famous owl: http://www.thingiverse.com/thing:18218

With 0.2mm layer height, most of the owl comes out fine. But the top of the head is not nice. With 0.05mm layer height, the top of the head is beutiful, but the total print takes forever.

The user interface for this feature will be tricky though...

 

[joergen 2]

Totally agree with Illuminarti, a modern slicer needs a set of very differentiated speeds, extrusion widths and layer heights. The old cura/SF paradigm of one size/speed fits all does not work.

as a feature request, and since I can't stand NF, but like the feature, please think about a method to implement the 1/2x, 1x and 2x paradigm for layer heights.

 

[greengecko 8]

I sincerely agree on the different layer heights, speeds within one print. Should not be too hard to have a post "plugin"-type extension that allows the user to specify different layerheights (quality setting height and speed) for different layers.

In an advanced setting it would be even better so be able to select different parts of a model (like a lasso on the surface with a defined depth ) and change the quality setting (height and speed and extrusion) for this part/surface of the model.

Otherwise slicing speed is great but a nice visualisation that points out potential problems (such as overhangs) is also very important.

Also to allow for a start and finishing point would be great, because sometimes the end points is somewhere where you just do not want it to be. An implementation could be to add a finishing point one layer higher then the last model layer so the path algorithm should be able to find an ending of the path below the specified endpoint. Reverse should be true with the starting point (default closest to edge x,y = (0,0)).

 

[Daid 306]

Cura 13.03 has an "overhang view" where it shows the steep angled areas in red. Works great. (I think 12.12 also has this, but it's less easy to find)

I think the multiple-layer-extrusion width setting is great, and it can be done. (But it is a bit of a GUI hell like NetFabb proves) But first a stable feature-complete release compared with Skeinforge.

[lawrencejohnston 0]

I'm excited for this new slicer. As far as feature requests go, there are quite a few of mine implicitly included in my slicer thoughts post from a while back: https://groups.google.com/forum/?fromgroups=#!searchin/ultimaker/lawrence$20johnston%7Csort:date/ultimaker/5C1uAUz6JvE/KufYdLe3OuAJ

Some excerpts from the linked post (things that I find KISSlicer does better than the current Cura):

* KISSlicer has a nice feature where it will print several layers of semi-sparse infill (much closer together than normal sparse infill) before top-skins, which tends to make the top-skin print much nicer with lower infill settings (e.g. ~20%). In Cura you have to increase the top/bottom thickness to get the top-skins looking as nice, which affects both top and bottom-skins and prints more completely solid layers.

 

* KISSlicer supports printing upskins covering only part of a layer better, as Cura (i.e. Skeinforge) will usually make significantly more of the layer solid than really needs to be so.

 

* KISSlicer supports varying speed based on the extrusion kind (perimeter, top/bottom-skin and support, sparse infill). This is great for reducing print time by speeding up sparse infill.

 

* I prefer KISSlicer's support in that it generates sparse support up until a couple layers before it's needed and then switches to denser support up to where the print will rest on it. Saves filament for basically no downside.

 

* KISSlicer produces the full number of perimeters for large (and/or supported) overhangs, whereas Cura seems to go into some sort of bridging mode and only produce a single perimeter no matter how many are configured.

 

* KISSlicer's stacked layer implementation is such that the stacked layers do not lie directly on top of one another if the object is not perfectly vertical (it prints the same perimiters it would if you'd configured layers of half the size, but only prints infill every other layer) whereas Cura's just generates layers that are the thickness you configured but prints the perimeter twice at half thickness (so the two perimeter layers always lie directly on top of one another, even when the object is not completely vertical). I prefer KISSlicer's implementation, as the outside looks much better any time the object isn't completely vertical. Cura's implementation might have a small advantage in that the infill is always touching both stacked perimeters, but in most cases I would prefer the outside looking better.

* KISSlicer has a crowning feature, where it each layer it will attempt to fill in small gaps where there's no room for infill but the perimeters don't quite meet up. In concept, this is awesome, and in implementation, it's often awesome, but occasionally it can be a PITA. Especially for an object which has a lot of these tiny gaps on each layer (a half-sized octopus, say), there can be easily a half dozen or more tiny jump-prime-extrude extremely small amount-retract-repeat sequences each layer which travel all over the model which take up a lot of time and tend to slightly over extrude plastic in those areas due to the time spent priming and retracting. I do need to mess around a bit more with the crowning threshold setting to see if I can improve this. [NOTE: It sounds like you've already come up with your own solution to this, but I'm listing it in hopes that you can avoid the issues with KISSlicer's implementation, though even comb + retract only on jumps will help significantly I think.]

 

[Daid 306]

I'm excited for this new slicer. As far as feature requests go, there are quite a few of mine implicitly included in my slicer thoughts post from a while back: https://groups.google.com/forum/?fromgroups=#!searchin/ultimaker/lawrence$20johnston%7Csort:date/ultimaker/5C1uAUz6JvE/KufYdLe3OuAJ

Some excerpts from the linked post (things that I find KISSlicer does better than the current Cura):

* KISSlicer has a nice feature where it will print several layers of semi-sparse infill (much closer together than normal sparse infill) before top-skins, which tends to make the top-skin print much nicer with lower infill settings (e.g. ~20%). In Cura you have to increase the top/bottom thickness to get the top-skins looking as nice, which affects both top and bottom-skins and prints more completely solid layers.

 

* KISSlicer supports printing upskins covering only part of a layer better, as Cura (i.e. Skeinforge) will usually make significantly more of the layer solid than really needs to be so.

 

* KISSlicer supports varying speed based on the extrusion kind (perimeter, top/bottom-skin and support, sparse infill). This is great for reducing print time by speeding up sparse infill.

 

* I prefer KISSlicer's support in that it generates sparse support up until a couple layers before it's needed and then switches to denser support up to where the print will rest on it. Saves filament for basically no downside.

 

* KISSlicer produces the full number of perimeters for large (and/or supported) overhangs, whereas Cura seems to go into some sort of bridging mode and only produce a single perimeter no matter how many are configured.

 

* KISSlicer's stacked layer implementation is such that the stacked layers do not lie directly on top of one another if the object is not perfectly vertical (it prints the same perimiters it would if you'd configured layers of half the size, but only prints infill every other layer) whereas Cura's just generates layers that are the thickness you configured but prints the perimeter twice at half thickness (so the two perimeter layers always lie directly on top of one another, even when the object is not completely vertical). I prefer KISSlicer's implementation, as the outside looks much better any time the object isn't completely vertical. Cura's implementation might have a small advantage in that the infill is always touching both stacked perimeters, but in most cases I would prefer the outside looking better.

* KISSlicer has a crowning feature, where it each layer it will attempt to fill in small gaps where there's no room for infill but the perimeters don't quite meet up. In concept, this is awesome, and in implementation, it's often awesome, but occasionally it can be a PITA. Especially for an object which has a lot of these tiny gaps on each layer (a half-sized octopus, say), there can be easily a half dozen or more tiny jump-prime-extrude extremely small amount-retract-repeat sequences each layer which travel all over the model which take up a lot of time and tend to slightly over extrude plastic in those areas due to the time spent priming and retracting. I do need to mess around a bit more with the crowning threshold setting to see if I can improve this. [NOTE: It sounds like you've already come up with your own solution to this, but I'm listing it in hopes that you can avoid the issues with KISSlicer's implementation, though even comb + retract only on jumps will help significantly I think.]

 

The idea to print spare infill denser near the top is pretty good. Need to think a bit on how to implement it (I know how KISSlicer does it, but my code is using a different way to do things)

The "oversolidfy" (or interface layers) is something I never really understood from Skeinforge, I know what happens, but I never understood why someone in their right mind would think it's a good idea. Thus, my engine does not do this.

I'll most likely throw in a "power user" mode, where you can configure shitloads of things, like different extrusion widths and speeds for just about anything.

For support material, there is a lot to improve. I currently have an implementation that resembles the SF way. But most certainly that will change.

The "Skin" or stacked layer implementation of Skeinforge is just an ugly hack, and doesn't make a whole lot of sense. But this feature for my new engine will most likely not make it in the first version. As I have to choose what to include and what not. And slicing at different layerheights add quite a bit complexity to the current code.

My "thin wall fix" is pretty simple and effective, but it will require some tweaking for optimal results. My initial settings caused overextrusion so I dialed it down a bit already. It also causes a LOT of tiny head movements, which result in a lot of noise. But the path-order-optimizer combined with the combing code take care of the possible time spend here. And the thin-wall-fill is done combined with the normal sparse and top/down infill, so it doesn't to it separately moving all over the place when the rest is done, but while the rest is also printed.

As I'm also doing some changes on the Cura GUI... well, "some changes" are that I'm merging the project planner into the main window, adding better object selection for it, and updating the 3D view a bit. The code is currently a huge mess. For the technical people, I'm switching from the fixed-function depricated OpenGL code to VBO's with Shaders.

We're working on better dual-extrusion support. And I'm pondering to add support for having a "multi-part" objects which you print with 1 head, but different parts at different settings (making dual-extrusion nothing more then a multi-part object where one of the parts has a different extruder as setting). The AMF file format might play a big role in this.

But this is long term planning, so be happy with the current 13.03 release ;-)

 

[lawrencejohnston 0]

The idea to print spare infill denser near the top is pretty good. Need to think a bit on how to implement it (I know how KISSlicer does it, but my code is using a different way to do things)

The "oversolidfy" (or interface layers) is something I never really understood from Skeinforge, I know what happens, but I never understood why someone in their right mind would think it's a good idea. Thus, my engine does not do this.

I'll most likely throw in a "power user" mode, where you can configure shitloads of things, like different extrusion widths and speeds for just about anything.

For support material, there is a lot to improve. I currently have an implementation that resembles the SF way. But most certainly that will change.

The "Skin" or stacked layer implementation of Skeinforge is just an ugly hack, and doesn't make a whole lot of sense. But this feature for my new engine will most likely not make it in the first version. As I have to choose what to include and what not. And slicing at different layerheights add quite a bit complexity to the current code.

My "thin wall fix" is pretty simple and effective, but it will require some tweaking for optimal results. My initial settings caused overextrusion so I dialed it down a bit already. It also causes a LOT of tiny head movements, which result in a lot of noise. But the path-order-optimizer combined with the combing code take care of the possible time spend here. And the thin-wall-fill is done combined with the normal sparse and top/down infill, so it doesn't to it separately moving all over the place when the rest is done, but while the rest is also printed.

As I'm also doing some changes on the Cura GUI... well, "some changes" are that I'm merging the project planner into the main window, adding better object selection for it, and updating the 3D view a bit. The code is currently a huge mess. For the technical people, I'm switching from the fixed-function depricated OpenGL code to VBO's with Shaders.

We're working on better dual-extrusion support. And I'm pondering to add support for having a "multi-part" objects which you print with 1 head, but different parts at different settings (making dual-extrusion nothing more then a multi-part object where one of the parts has a different extruder as setting). The AMF file format might play a big role in this.

But this is long term planning, so be happy with the current 13.03 release :wink:

 

Thanks for the response, and I'm glad to hear that most of my biggest issues with SF will most likely eventually be addressed. Looking forward to trying the 13.03 release, and thanks for all your hard work.

 

[snowygrouch 1]

looking forward to trying it. will it solve the staircase thin wall at the top of arches problem that all slicers have?

 

[Daid 306]

looking forward to trying it. will it solve the staircase thin wall at the top of arches problem that all slicers have?

 

Depends, because I'm not sure what you mean with it.

 

[gr5 2,229]

I think it would be great (and probably easyish) to have the "bottom" layer optional. This would help greatly with parts that don't need to look good on the bottom and that are large (have warping issues). With no bottom, the bottom layer would be able to compress a little when the upper layers are cooling and would be less likely to lift and also less likely to warp (almost the same thing).

Examples would be a "bust" where it is meant to sit on a flat surface and you don't see the bottom layer without picking it up. The infill would be visible from the bottom and would be a nice conversation starter on how 3d printers work.

Or architectural models or anything that is meant to sit on a flat surface. This should only affect the "bottom most" layer and not layers that are higher up in the model (for example the underside of a chin on a face).

 

[chopmeister 0]

I think this is the best piece of news I heard all month I'm so glad you will be making a completely new slicer. Lots of things and best practices have been discovered on the UM groups in the last year or two, so I think it's a great time to put all that info to good use.

As for feature requests here are some:

1. Netfabb style infill - the best infill I've ever had on prints, in my opinion the ideal balance between structural strength, looks and speed (and also great for printing nice upskins)

2. The power-user mode, as you call it, would be really awesome thing to have, with all possible settings exposed (you can never have enough settings )

3. Multiple extrusion widths/speeds with a decent GUI - netfabb's way of doing it is a GUI design version of a Darwin award, so it's a great example how the new GUI shouldn't look like. There must be a way to do this more intuitively.

4. Something like a "hash code" for settings - it would be awesome to pack a print profile into a string, which can then be copy-pasted from the 3d model's description (for example, if I could put in the description of an object on thingiverse:

"Cura: [hTg53%gdSH432FD]", there would be no need to read about print settings, and it would make it super easy to share profiles online. I don't know if this is feasible, given the amount of settings available.

5.And last but not least: adaptive slicing! there's tons of research papers about it on the web. I know it's probably tough to do, but I would like to see that in a next gen slicer. You just input a min and max layer height, and the slicer adapts to the features and overhangs on the model. It gives a much better quality/time ratio than uniform slicing.

I'm sure I'll think of more stuff soon

Cheers,

Chopmeister

 

[snowygrouch 1]

Hi Daid,

This is what I mean by "staircase" effect. I have photos of parts I have printed in Netfabb, KS and CURA

where a thin wall part is actually having a hole at the top of "dome" shape areas because of this problem.

 

Although its much less of an issue with lots of infill, it would still be very nice to have fixed. I print parts

that have to be water-tight and this problem is really an issue for that !

C.

 

[Daid 306]

Ah, that effect. My new engine will lay full-infill under those stairs, so the "stair" parts are always 6 layers thick (on default config). This does add a pretty large amount of tiny print moves, but the result works great.

 

[illuminarti 18]

Doesn't KS try to compensate for this by adding extra solid infill inside the loops to try and make the wall the correct thickness?

 

Hi Daid,

This is what I mean by "staircase" effect. I have photos of parts I have printed in Netfabb, KS and CURA

where a thin wall part is actually having a hole at the top of "dome" shape areas because of this problem.

 

 

Although its much less of an issue with lots of infill, it would still be very nice to have fixed. I print parts

that have to be water-tight and this problem is really an issue for that !

C.

 

[snowygrouch 1]

Dont know, to be honest - the problems I had with this were when printing a 100% hollow part. So infill would

have no healing effect. Unless KS has updated it in the latest beta version.

C.

 

[gr5 2,229]

This is a great example of where one would want variable thickness layers. I would want to double up my layers for these areas. This is referenced in that "paper" slicemeister posted about earlier in this thread.

 

[mastory 44]

I've been giving some thought to some Slicer and/or firmware features that might improve printing. Mechanics are my forte, so bear with me if something I suggest is out there programming or electronics wise. I like to consider alot of ideas, good or bad. The more the better. A small percentage will develop into something real. A few will trigger other ideas.

A. One thing is improving the function while pausing a print. The goal would be to make the pause function predictable, more useful and non-harming to the print. This could be the result of a premeditated stop (maybe to change filament, insert an object into a printing part, add support tooling, etc...) or an emergency on the fly thing. I started a post on the Gogle group about this.

Premeditated stop points could be placed in the Gcode by the operator/slicer at slciing. A subroutine would be triggered when the stop code is encountered.

Maybe for inserting something into a print it might go like:

Stop,

Retract,

Rapid Short Z down,

Jog X & Y to known postion (maybe over infill, or off the print to the side)

-Pause-

Resume print from break point (jump to position, Adjust E, Resume) on operator action.

Unplanned stops could be intiated spontaneously by the operator for any reason. Once called, the machine would proceed to the next convenient point and then stop like above. The potential stopping points would be pre-defined by flags that were placed at strategic points in the slice (maybe one per layer, the next opportunity over infill', Z change...) If no unplannned pauses are requested, all the flags are ignored.

I doubt it's feasible, but a third 'immediate' stop mode would seem intuitive. By this, I mean an imediate stop mode that could be resumed from, maybe with the sequence from above.

B. Potentially borrowing from the Flat Bottom function; Lets say you have a model that you would like to split into 2 (or more?) pieces before slicing. The model could be positioned so the XY plane of the printer bed cuts the model in half. The slicer is intiiated on the model as positioned and slices from the bed up and saves the file. The slicer then inverts the model, and uses the same slicing parameters to slice the other half of the model. To kick it up a notch, maybe registration holes could be placed in both halves?? .. or snap features??

C. Its an old topic, but it would be a great benefit to make cylindrical hole printing more dimiensionally repeatable. Estimating offsets and trial and error testing becomes tedious. If this could be handled at the slicer, the benefit of shared models would be greatly improved. I don't have clue if this is possible, or how it might be done. Granted, there are alot of contributing factors. Maybe a table could be derived from a set of printed callibration models. I started logging my modeled hole sizes vs the printed result and found that the variation dimishes on fairly predictalble curve as the hole diameter gets larger.

Thanks for humoring me... Your thoughts?

Matt