a brand new slicer - does what YOU want?

[Daid 306]

CodeMaven, that works, until you get into the corner cases. For example, take an U shape, and have the bottom part really thin, thinner then 4 shells. Then if you do your basic scaling you will run into problems. (It's the issue I ran into with SliceAndDaid, and why I'm using ClipperLib, as that library has solved the problem)

[alaris2 1]

the biggest problem (and I think Daid is going to hit this too) is that you must use a thickness function, not an offset/scale function.

consider the case of a figure 8 in 3D. you don't want to scale about the centerpoint of the 8, you want each circle to scale about the center of its circle.

this requires deciding multiple centers and which polygon belongs to which.. and this is where it starts to get slow.

the correct way to solve the problem came to me at about 3pm after thinking for many hours, only to discover someone else had already thought about it and written a very good paper on the subject.

alas no free source code, and the suggestion was that it's still slow.

there's a solution in opengl-land, because you can fix the XY-plane part of this problem by using some bresenham - but traversing large texture arrays = slow. which defeats the purpose of the exercise.

it seems to suggest speed and robustness are mutually exclusive - you can either take the fast but 'keel over and die when you find the tiniest fault in the model' approach that k'slicer takes.. or the 'works on every model under the sun even the horribly degenerate corner cases, but takes hours to generate the shell' approach which is the corner I seem to have painted myself into.

[Daid 306]

Forget "fast". People are quite accepting the speed of Skeinforge in Cura, and are more ticked off by the fact that it doesn't support 64bit on Windows and runs out of memory then that it slices slow. If you are 3-5x faster then Skeinforge, then you are golden.

With my C++ code (Which is called "SteamEngine" for now, but might be called "Carpaccio" later on, we haven't really decided on the name yet), I'm not aiming for speed. But code simplicity. If it's easy to see what the code is doing, it's easy to adept and try different things.

[snowygrouch 1]

Hi Daid,

I would be careful about saying that people are quite accepting of Skinforge in CURA. Im not !

This is (for me) a small file:

CURA = 10 minuites

KISSLICER = 40 seconds

Thats 15x faster !

If I spend 2 hours a day waiting for the slicer, if I switch to KISSLICER I can get all my work done in 8 minuites.

Scale that over a couple of weeks and I have saved a huge amount of money.

I simply cannot possibly find hours and hours to waste waiting for the slicer.

So as long as KISSCLICER is 15x faster than CURA, I cannot consider using CURA.

C.

(Also now I look at the images, I had CURA with 0.2mm layer height. And KS has 0.16mm, so KS has computed 20% more layers)

[IRobertI 520]

I have to agree with snowygrouch here. After my first print with KS I completely abandoned cura. And the reason for that was largely due to the speed difference (I do my slicing on a slow laptop so every bit helps).

[alaris2 1]

it's the second reason I moved to KS originally - the first was because the outer surface quality of parts was just so so much better than SF.

if I had to prioritize it would be quality, time, robustness. how do others feel about priorities?

[Daid 306]

Go have your Cura is slow flamewar somewhere else please. This is NOT the place. I know it's slow, I acknowledged it. But I also know it's not that acceptable speed wise and that it needs improvements. But speed should NOT be top priority. And quite a few people are accepting the current speed. 3-5x faster was what I said. Which is NOT hard at all. Printing quality should be first. And easy of use was and still is important for new users.

As for slicing, you know, the thing we where talking about here in this topic. Before someone decided to took my "don't focus on speed remark" and blow it out of fucking proportions.

The outer skin quality is something I'm investigating, it's very noticeable on the Ultimaker robot at 0.1mm layers with Cura. And my C++ slicer has some improvements compared to SF on it. But I haven't nailed it quite yet, as KS still is a bit better. (We're calling it the "schurft bug". Schurft is a skin disease FYI)

[snowygrouch 1]

1) Quality

2) Speed

3) Stability with large STL file sizes

4) Support material configurations

5) Infill material configurations

6) Ease of configuration

I would add that no amount of quality will outweigh speed if its really really slow.

[joergen 2]

I am going to side with David, bashing Cura (actually SF) is completely unnecessary. David has stated times and times again that SF (inside Cura) has reached the speed limit, and that major improvements are unlikely and difficult to achieve... This is/was the reason why Cura is plugin based... at one point it was possible to use Slic3r as the engine, and now Kisslicer may be an option.

But continuously bitching about the (lack of) speed doesn't help anybody. If there would be a large headroom for speed improvements for SF, David would have done it already, or at least we would have heard about the option to do so.

I agree with David, Cura is indeed good enough for beginners to get good prints... it is already 10x faster than 18 months ago...

If you have a large need for speed improvements, you are not a beginner anymore, and as I have stated in another post, you are free to use the other slicers, we all have the liberty to choose. complaining about things that are difficult/impossible is counter productive, especially if you can't offer a solution to the problem at hand.

[IRobertI 520]

Go have your Cura is slow flamewar somewhere else please. This is NOT the place.

Overreact much? This is exactly the place to state that for us speed is a very important feature and that is the only thing we did. No one is bashing cura. Calling it a flamewar is just silly.

[snowygrouch 1]

What I did, is to slice an STL model, in two different slicers - and then post the times that it took. Then I posted this data in a thread created by someone who is writing their own slicer and was looking for recommendations.

Thats IT, thats ALL that happened.

However I am not a moron, and so of course that is why this information was posted NOT in the CURA section of the forum (where it would obviously be just inflammatory, and not of use), but in the "other" section of the forum where someone was asking for recommendations about what can be improved about current slicer software, AND where a discussion was already underway about slicing times.

If anyone wants a show of how popular CURA is, they only need to look at the forum posts - which show it has well over twice as much discussion as the nearest other slicer (which costs 150 Euros).

C.

[alaris2 1]

easy all. no offence was intended to anyone and there were good and valid points raised by all parties.

the crucial next step is some alpha code that people can run so we can get feedback. there's also a 'collection of data' task too - it's very apparent reading thru different threads that almost everyone has their slicers configured in different ways (eg. with respect to fans on/off, first layer thickness, heated bed temps, etc etc).

is this because it's the *only* way it worked for that person, or because we've all fallen into habits? has anyone tried a comparison between 'with this setting' and 'without this setting' for example?

I know i'm guilty of this - over time I've tried almost everything, but not necessarily in a scientific way, there are too many variables, but what I have may not be optimum therefore.

to try and explain why this is important - allow me to take the example of the first layer which is tackled differently by nearly everyone. some swear by bed levelling and treat the first layer the same as all others, others will configure the first layer speed and layer thickness. this has implications on the g-code generation as well as the slicing.

none of these methods are better or worse or right or wrong. but i'd like to understand if there's a one size fits almost all situation here because it avoids a huge number of UI configuration options if so and makes it easier for new users (we all want a 'just do it' button after all).

in the early days I had the first layer about half speed, with no fan and twice as thick as other layers.

later I realized this distorted models so tried all layers same thickness. it worked fine, so i stayed with it.

later still i got tired of waiting so long for the first layer, so sped it up to 75% of full speed. it worked fine. i stayed with it. then i switched the fan off for everything except bridges.

obviously the first layer is key, but without starting another war, can we discuss "just how much like a normal layer can we treat it and still have a 99% success rate?"

[codemaven 0]

Just to get a little bit back on track here...

"...or example, take an U shape, and have the bottom part really thin, thinner then 4 shells. "

The issue with thin walls is something I'm familiar with.. I haven't done extensive testing yet, but my BSP tree should be taking care of that. For each line segment on each interior polygon the BSP tree can tell me with a simple call whether my line segment is clipped by another polygon (i.e. if it's scaled down to negative space, meaning that the wall is too thin.). In these cases I can adjust. Exactly how to deal with these situations is another issue... But I've got a few ideas.

For the shells, I am producing a configurable number of shells with configurable widths and speeds. Each shell can have it's own width and speed. This is like NetFabb. Thus, the outer shell can have a small width that is done slowly while the inner shells can be printed faster. I've also added the ability to do everything on a 1 or 2 layer basis so you can slice at 0.04mm layers and print the outer shell on every layer, but the inner shells on every second layer. As far as I can tell this is basically what NetFabb is doing with half-layers.

Cheers,

Troy.

[Daid 306]

For the first layer. I've put Cura on very slow, very thick there. Which is not required, but helps a lot to get the layer to stick if you bed is not properly leveled, or the tape is less then perfect. I have the advantage here of having tested on quite a few machines and a warped 6mm bed on my machine.

Cura also compensates the slice location of the first layer for the thicker layer, not all slicers might do this which could lead to deformed objects.

[alaris2 1]

Daid> compensating is important I agree. the warped bed thing is interesting too - I see KS has an option to load a bed profile (not quite sure how it's generated) to handle strange shaped beds..

have any tests been done to understand speed? logically we feel slower is better, if nothing else it gives more time to react and stop the print, but is slow necessary to stick? does it actually make any difference to how well PLA sticks to tape or is that just a warm fuzzy feeling inside our heads?

Troy> I think I understand - but how are you handling shells in the Z dimension? the XY plane description makes good sense but only if the shell exists purely in the plane?

[Daid 306]

Yes, speed makes a difference. At higher speeds it has less time to bond to the bed and because the head moves faster it also rips the line easier from the bed. This especially happens at the infill lines, where the head makes sharp corners.

[codemaven 0]

Alaris > The Z shells are easier. I'm assuming you are talking about upskin / downskin (at least that's what it's called in NetFabb). Basically, for each layer I'm doing a BSP tree 'Diff' with the previous layer. Any zones that are solid in the current layer, but were not solid in the last layer get a filled skin. It's done going bottom up for downskins and then in another pass going top down for upskins. In order to get more than one layer of course we need to define multiple skin zones... I.e. for each zone if there is no solid below it then this region is solid infill-1, then on the next pass we do the diff and we see that a solid region is above an infill-1 area so we make this new layer an infill-2 layer (perhaps a different direction of infilling if we're doing croshatch). Just keep going for the appropriate number of skins. This is configured seperately from the shells, but for consistency should be determined by shell thickness... If you have 3 shells at 0.4mm then that total thickness is 1.2mm, so at 0.08mm height you would need 15 layers if infill to match the same thickness.

Cheers,

Troy.

[msurunner 2]

the crucial next step is some alpha code that people can run so we can get feedback. there's also a 'collection of data' task too - it's very apparent reading thru different threads that almost everyone has their slicers configured in different ways (eg. with respect to fans on/off, first layer thickness, heated bed temps, etc etc).

is this because it's the *only* way it worked for that person, or because we've all fallen into habits? has anyone tried a comparison between 'with this setting' and 'without this setting' for example?

I know i'm guilty of this - over time I've tried almost everything, but not necessarily in a scientific way, there are too many variables, but what I have may not be optimum therefore.

THIS is the main advantage that Cura has over any other slicer. The creator of the software was a machine specific user, and one with the capability to try many things to get a good start point for getting users close. That was my main draw towards it initially. Now, I completely understand the shortcomings and limitations of Cura, don't get me wrong. BUT Cura also is a great tool for teaching new users about WHAT the software is doing. IF we want a completely new slicer, we need to make sure that there are enough profiles collected to create an average profile to get a user close. This would be the main disadvantage of KISSlicer. You need to have another user with a good working profile (thanks grouch!) to get you close. If we want to backdoor it to Cura, potentially all the better. Save the work of GUI generation.

I use both slicers and both have their pluses and minuses. For my students, I can explain what is going on a bit more easily with Cura (the interface helps a lot). I can also tweak a couple of different parameters that I haven't figured out how to in KS (perhaps out of laziness). BOTH are capable slicers for 95% of the projects thrown their way, and generally that 5% is covered by the other slicer. It would just be nice if we got to a point where we were tackling 98+% of our projects at 99+% satisfaction.

My biggest thing would be quality. That means surface quality and wall placement (a problem that I feel is all too often declared a loose belt backlash issue). I understand pulley slippage and belt tension are still going to provide users with some issues, but a slicer should be absolutely spot on with those two. Second would be speed. 3-5 times the speed of SF-Cura would probably be acceptable for me on smaller or less complex prints, but I know Cura has trouble with some of the Yoda busts and whatnot. I am very excited to see what your speeds look like (still can't believe you were upset with 800K layers in 3 min, alaris...). I generally will not use Cura if I just want to do a quick print on something because of the slice time, and hate tying up the computer for fifteen minutes anytime another teacher wants a Yoda...

(Wow, this is running on... almost there)

As for first layer issues, I am a firm believer in bed level/proper height. I think way too many people (myself included) got frustrated with that first layer time and cranked it up. Then things weren't sticking, so you lower the bed, then you get an over extrusion, so you adjust filament size/steps per e, then your top surface quality suffers so you are lost in this hopeless calibration loop. IMHO, bed height and level is critical. The byproduct of that is first layer speed will need to be generally less than half of print speed (again, IMHO). BUT, that may just be me. I want my part not to warp, not have a flared lip, AND release from the bed with relative ease. The only way to do that is for the bed height to be adjusted properly and only take the speed up to where it can handle it. I'm more than willing to wait another three minutes for the part to be "perfect" and not have to deal with cleanup issues with high speed first layers.

Finally, when we do create profiles and what not, I think it's very important that we remember to create a starting point for users. Saying "oh, well, with this slicer and a properly tuned UM you should be able to print at 200 mm/s or have a layer thickness of .3 mm or .05 mm or an extrusion thickness up to a mm..." is pointless. Those are specialized cases. No one claims that everyone should be able to run a sub 10 second 100 m because some Olympic athlete can. Why should we expect all of these printers that have been tuned by hundreds of users with millions of potential settings to all perform to the pinnacle performance? Let's be realistic in our expectations here...

[alaris2 1]

wow thanks MSU, there's a lot there to digest!

I'm going to try some experimental profiles and relevel my bed after fitting the heated bed next.

[msurunner 2]

If you have something available to test, I'm more than willing to alpah/beta it... Plus, inexperienced 15 year olds are a great test for the intuitiveness of a software...

[tom 0]

If you have something available to test, I'm more than willing to alpah/beta it...

I second this, I'd be more than happy to help any way I can.

[leadingedge 0]

If you have something available to test, I'm more than willing to alpah/beta it... Plus, inexperienced 15 year olds are a great test for the intuitiveness of a software...

Happy to help as well. +1 on the inexperience. Can't quite remember 15 years old tho' ;-)

[msurunner 2]

Haha, it helps when you are around them five days a week! It's amazing how many bugs they can find in even commercial software, too. Every time I think I have a piece of software figured out, they find a way to alter the GUI/settings in a way I've never seen and I have to go searching on the net for how to return it to its original state.

[tom 0]

Welp its that time again, its been a couple of weeks and I'm going to be "that guy" and ask how its going? I'm definitely still interested and I'm sure others are as well.

As always, thanks to those who do this!

[alaris2 1]

it's gone really quiet actually - I had so many people write to me saying they were working on slicers that it made no sense for me to reinvent the wheel, so I stopped.

I also had loads of messages of support and offers of help- thanks to everybody- and sorry I didn't have time to respond to you individually- there were too many!

I was reminded last night again after a terrible print just how dire the need for a decent slicer is-so I hope Daid has made better progess than I.

whilst I don't now have the time to write the whole thing I would be happy to share where l got to and the methods I was intending to use to solve each of the requests