Beginnings of a new Slicer NOT producing GCode yet!

[Daid 306]

I've put up my code on Github today. So today is a good day.

I've started work on a new Slicer for 3D printers. Which is a more complicated task then I had imagined. I was looking at Skeinforge and I found it slow, the code inflexible to work with. I did some work on trying to speed it up. But in the end it's the design that makes it slow and clumsy.

So I started on my own slicer. And with a huge ego programmers have, I named it "SliceAndDaid". It currently only slices the model into layers, generating an outline. I'm still a few days off from generating GCode, but I figured I get this topic rolling a bit. I've not measured slicing speed, because providing metrics at this point would be useless as it lacks many features. But, it's fast, very fast. The largest thing I threw at it took seconds to slice and optimize.

The steps my slicer takes:

Configuration dialog

I'm aiming for a simple configuration dialog, with 3 "user levels": Beginner, normal, advanced. The higher the level the more options are shown. The beginner option should only need a few settings like layer height, line width, filament width. Advanced will show everything, like Skeinforge does.

Model loading

It only loads ASCII STL files right now. Binary STL files is in the planning, but I have yet to encounter those files. (please send me an example?)

Slicing

It slices the model not layer by layer as Skeinforge does, but triangle by triangle. This means it goes trough all the triangles in the model, and only adds lines to the layers in which this triangle intersects. This is very fast, especially on high detailed models. Because this way it only needs to go trough the triangle list once, instead of once per layer.

Optimizing

My slicer will assume, and require!! that your model is manifold. It tests so during the optimizing phase, where it will connect the lines to each other, find out which are outlines, and report errors. It will also join up lines that have a to slim angle between each other. This will make circles slightly less round, but will also reduce the amount of GCode. (this is configurable)

Outline

The outer wall is generated by a line inside of the enclosed lines found during the optimizing phase. There are a configurable number of outlines.

Currently there is an issue with thin sections which causes outlines to overlap. Another thing for the todo list.

My code can be found at:

https://github.com/daid/SliceAndDaid

I'm not providing binaries yet, and documentation is lacking. There are files in there for an eclipse project. I'm just throwing this out here so people can give me ideas. I hope to have the code ready for printable hollow objects in the next few days.

[Daid 306]

It is producing GCode now, but I cannot edit the topic title...

It still only generating the perimeter, but I guess you could print one of those fancy tornado's with it like this.

I've added an "Tiny compact" GGode mode, which I think produces GCode as compact as possible, which the firmware will still accept. However, some parsers might not like it, and it's far from readable. But it does save about 10% codesize, might just be the edge if you run into buffering problems.

The startup/shutdown code it hardcoded right now.

It's still in heavy development, but it's also still slicing at ~2 seconds for my test model which took 5 minutes with skeinforge. Right now it can slice the _assemble.stl from

http://www.thingiverse.com/thing:12472

under a minute. The assemble.stl is not really intended for printing, but it's a good speed test, however I do not dare to put that stl into skeinforge.

I'm working at many fronts at once, so I've also updated the config UI, and the preview window. The configuration dialogs look this this:

(Beginner mode)

(Normal mode)

(Advanced mode)

[ddurant 0]

Great progress!

edit: and, just a idea, consider having min and max thread widths instead of a single, predefined value. Or maybe allow a specific value or a range. This isn't as interesting on the perimeter but when you do infill, this will allow it to chose fatter/faster lines in the interior and thinner/slower lines on the exterior. That and it will help solve (or reduce) the thin-wall problem where the a specific thread width & shell count prevents areas from being filled..

[Daid 306]

That's a great idea! I'm a long way from it, but I'll keep it in mind. First step would be to get the features so normal prints work. I just did a test with the "Pink Panther Woman" printing at 50% with just the perimeter 3 lines. And it came out quite good for the first 10mm or so. The bottom layer was not really sticking to the platform, so it moved a bit. Other then that, it looks great.

I didn't push my latest update to github yet, so don't try to use the current code, it doesn't work. (problem of using a new tool, haven't been using git for long)

[Daid 306]

So, more updates!

Finally got to push my earlier update to github. I've also added some more GUI stuff, like a progress window.

The STL from

http://www.thingiverse.com/thing:13440

slices in 50 seconds on my desktop machine (Core2 2.33Ghz) as the reported slice time was 3 hours on SF, it's more then 200x as fast right now.

Still no infills, and the perimeter sometimes intersects with itself causing problems. Which is the next thing I'm working on, but it's quite math heavy.

I've added the option for a skirt, which doesn't work correctly in most cases yet. (My math Foo was failing today)

I've also added a "minimum layer time" option, so you get the same behavior as the cool plugin from SF. (This was ridiculously easy)

I've moved a few of the ADVANCED settings to a new setting group called "KITCHENSINK" which will contain all options which you will never want to change.

The start/end GCode is now configurable (new configuration dialog shows 3 tabs for: settings, start code, end code)

I hope to get my first working print tonight!

[Daid 306]

 

http://daid.eu/~daid/IMG_20111109_193835.jpeg

First print!

[Daid 306]

edit: and, just a idea, consider having min and max thread widths instead of a single, predefined value. Or maybe allow a specific value or a range. This isn't as interesting on the perimeter but when you do infill, this will allow it to chose fatter/faster lines in the interior and thinner/slower lines on the exterior. That and it will help solve (or reduce) the thin-wall problem where the a specific thread width & shell count prevents areas from being filled..

I need to work out the math for this. But I have an idea how to do this, it needs to use up to twice the normal thread width at some points, but then you could create an almost perfect fill for thin walls.

I need to fix my perimeter code for this (which I'm working on right now, requires a custom "straight skeleton" implementation, which I haven't nailed yet).

I've done some updates on the UI:

The buttons now show the "level" of the setting: beginner/normal/advanced/kitchensink = white/orange/yellow/red. To make it easier if you are configuring with more settings visible.

I've added categories like seen in Slic3r (Always copy good ideas)

[ddurant 0]

Looking good!

I'd switch the colors around, though. Red makes me think it's something I must pay attention to.

[darkflame 0]

Nice work.

If you still need binary STL files I could supply some.

[Daid 306]

Oh, I've put this project on halt while I try to understand how Skeinforge works a bit better. Slic3r is also producing good results now with less slice time. And I've hacked skeinforge to work with pypy (see skeinforge forum section) which make skeinforge run at acceptable speeds.

[darkflame 0]

No problem.

I was looking at a alternative because Slic3r was producing gcode that always crashed when I tried to use it - always said something about a command not recognized. This could be as I am not using the newest ultimaker firmware, however.

[Daid 306]

Well, slic3r produced an pile of goo for me when I tried it. With Marlin. But I've seen people get good results with it.

But the models I'm slicing right now are < 2 minutes with Skeinforge_PyPy so that's fine for me.

[jleichne 0]

Hey there Daid!

I gotta say - I'm impressed that you took it upon yourself to try to write custom slicing software.

I've just received my ultimaker recently and my application requires a custom slicing module that allows me to generate particular sequences of G-Code based on predefined geometric parameters to guide a modified multi-headed system.

The only problem is that it means I need to write a 'slicer' of sorts that works with predefined geometries.

I'm excited to possibly contribute to this work once I understand exactly the protocol in which G-Code can be generated from a 2-D slice of a 3-D structure.

Jared

[Daid 306]

Note that this project is pretty much dead. But a few people have picked it up as a learning experience. I learned quit a bit while writing this slicer. And some day I might write a new one.

[codemaven 0]

Hi Daid, I didn't realize you attempted a slicer... I might take a look at what you've done. I've been toying with this idea for a couple of days, but as soon as I put any serious thought into it I always run into great difficulty in conceptualizing how to actually accomplish certain aspects... One of the most troubling for me is how to determine what areas need regular in-fill, vs downskin / upskin.

I wrote a OpenScad like compiler recently in Java with all of my own CSG code using BSP math... it works, but it's slow when it comes to large models as it tends to multiply the number of triangles with each operation. So after a few differences I end up with millions of uneccecary triangles that could (should be merged). Without any optimization it uses a lot of memory and each additional operation has more and more triangles to sort... Not sure if I'll ever release the code for this or not.

However, I was thinking that slicing is basically the same thing as intersecting a plane through the model using a Union operation and calculating a BSP tree for the points that it pases through.... So I might just attempt this. I don't have much time to work on programming projects these days. I have so many different projects on the go (like yourself), but I don't know how you can manage to make any progress... Betweek work, commute, girlfriend, etc I only get about 2 hours a month to work on my own projects...

Anyway, it's great to see this.

Cheers,

Troy.

[Daid 306]

but I don't know how you can manage to make any progress... Betweek work, commute, girlfriend, etc I only get about 2 hours a month to work on my own projects...

Well, I work at Ultimaker now so more time for my projects because of that, I can work in the train (so more stuff to do during commuting), I don't have a girlfriend (not anymore, but not because of all the projects).

So the only thing keeping me from projects is my cat. (who just crawled on my lap)

[victor.mazz 0]

Hi!

I am very interested in this slicer, would you be able to send me a message so we can talk, maybe through email?

Thanks!

Victor