a brand new slicer - does what YOU want?

[msurunner 2]

I should mention that my computer that I'm running this on is a 12-core 4.5ghz machine with SSD storage and 32gig of ram... That could contribute somewhat to my speed reports...

...Perhaps just a touch.... What did you purchase that for???

[codemaven 0]

For Fun

I bought it because I don't like upgrading every year... I could afford it so I decided to buy top-of-the-line everything... Including a custom overclocked CPU and watercooling. I mostly only use it for development and slicing for my printer... and email

Cheers,

Troy.

[alaris2 1]

so, before the end of the world, I figured a quick update of where things got to -

1) I can now load any .stl files, including damaged ones that meshlab won't load

2) I can slice and create support (simple only) any geometry, including inside-out, non-manifold, intersecting objects (-ve space) and all the other billions of combinations of broken geometry that seems to exist in stl files. no wonder so many slicers just barf at it.

phase 2 took somewhat longer than i expected, but I can now slice (almost correctly, see below) pretty much anything - even Ian's files!

(if you're reading this Ian - what is the difference between checoo and monboo?)

I said almost anything - there are 2 outstanding geometry errors I have no current fix for. I'm hoping they aren't very important in the real world..

1) infinitely thin faces (a face defined as being double sided has 0 thickness) - did you want these to print? or are they 'invisible' ?

2) incredibly thin triangle faces pointing along the z axis - these appear to give rounding errors when exported to stl (may also happen with a very dense mesh) which results in the surface not being watertight. this is no problem in that I can ignore it, but may occasionally give rise to miniature support structures or other anomalies as a side effect.

not too late to throw in your ideas for features - but I'd like to 'freeze' the feature list beginning of next year so the first version is well defined.

[IRobertI 520]

Here's a quirky and probably too obscure and hard to implement idea for ya. Yesterday I wanted the ability to define different regions for different amount of infill. This would probably be quite straight forward if it was just based on height, but it's not... What I'd like is to be able to select, in the 3d visualiser, an area that will be sliced differently than the rest of the model. A simple box select would probably suffice. The reason is that on occasion a large portion of a model needs little to no infill while other parts need more (for strength).

Another scenario where it could be handy is to specify different layer heights depending on where more detail is needed. Say the majority of the object is a simple box and then there's a small portion that is really detailed. It would speed up the print considerably if you didn't have to print the whole thing at 0.05mm to get the detail you wanted for just that tiny area. Speeds and temp would probably have to be specified as well.

How's that for an idea?

Oh and that pause at height feature daid added to cura recently, that'd be nice to have.

And I'm not sure if it's been mentioned but if the slicer could handle the thin wall problem that would be awesome. As an example, if a wall is say 1mm thick some slicers will leave a gap between the two shells. If the slicer was smart enough to understand that one more internal loop/shell at 0.2mm (or 0.3mm with overlap perhaps for a stronger part) could fill the void that'd be sweet. I believe KISSlicer calls this "crowning" and it sort of works, it's not quite there yet but it's close (edit: a new beta just came out with improvements to that, maybe it's fixed already).

[alaris2 1]

those are great ideas Robert - I'm compiling a list, I'll summarize the current features requested in a moment when I've finished formatting it.

don't worry about how mad or difficult the idea is - if it's too far off the wall I can only say no

as it happens, your second idea is something i wanted too, and I've found a way to achieve it I think.

[alaris2 1]

for reference, here are the ideas submitted so far in one post to save you having to trawl through the whole thread again -

1) Ability to flip STL models around properly. (also rotate, etc. - transformation matrix)

2) Ability to handle large CAD models.

3) Fixing the issue whereby the infill does not properly touch the walls

4) Making it have the ability to set wall thickness in 3D, (avoids staircase effect & holes in the top of thin arches)

5) Ability to print infill in different material from the main body. (as well as support)

6) More options for infill patterns. So square, circle, hexagon, straight lines only, waves, concentric infill

7) Individual speed settings for the different types of lines being put down (outer shell, inner shell, infill, support etc)

8) Ability to user define areas where support should exist, not just based on an angular parameter, but

by perhaps entering sets of XY co ordinates of the bedplate defining squares where support should exist. Or not.

9) Smart bridging that can look at a bridge and decide what will create the shortest jumps etc. If you're going to span a 20mm*5mm hole you'd make it jump the 5mm distance first for example.

 

10) Being able to specify roughly where the z-scar will end up

11) When printing more than one separate object at once, pick where the printer will jump between the objects (to minimize surface imperfections).

12) Something similar to Netfabb's half height outer shells. And not just the lazy skeinforge way of stacking two half height layers straight on top of each other. They should follow the outer shape of the object.

13) Different kinds of top-/downskin patterns

 

14) Speeed, lots and lots of speed

15) look at the gcode visualisation

16) variable speed for different parts of the model

17) "Good support". eg. starts small and then as it gets closer to what it's supposed to support it branches out - reduces material waste and makes it easier to clean.

18) support material with no raft on top - instead, very thin infill, then a raft, then finished off by a proper solid top layer. allows support to be dissolved to leave a nice surface finish

19) commandline slicer which produces GCode (doesn't print it)

20) Comments to see different "sections" of the GCode, layers/skirt/fill/outlines stuff like that. (for GCode preview and the "per type" speed adjustments).

21) Progress report on console output, with option model error output.

22) Slicing EVERYTHING, even is the model is bad, not manifold, contains holes etc.

23) Combing, staying inside the model during moves is important for print quality.

24) Thicker first layer

25) versions for

26) ability to define different regions for different amount of infill. (for parts which contain both aesthetic & structural elements)

27) different layer heights depending on where more detail is needed.

28) pause at height feature

29) handle the thin wall problem - if a wall is say 1mm thick some slicers will leave a gap between the two shells. (crowning in KS)

[tom 0]

Any update on this slicer?

[alaris2 1]

well I was replying about 2 hrs ago and then photobucket drowned in adware scripts and all my cookies vanished and I had to re-enter every single p/w for everything.. ;(

so I'll try again with imageshack..

not nearly as exciting after all that effort but it's a 64m long wind turbine blade, which I accidentally sliced at 0.08mm layers.

it took almost 3 minutes to slice too :(

needless to say, I didn't print it. did you know they're not quite round like that?

[alaris2 1]

that's slice 76 incidentally, in case anyone cares

so yes, it progresses - unfortunately I don't get much time to work on it, so slowly.

[msurunner 2]

64 m? .08 layers? As in 800,000 layers? If that's true, I have to say 3 minutes is FANTASTIC.

"needless to say, I didn't print it." Does that mean you have g-code generation/backended it to Cura with Daid?

[alaris2 1]

I forgot to sanity check the dimensions of the model I downloaded, so yes, 64m. First time l sliced it I had debug on and ran out of HD space.

g-code is in progress I hope. I'm negotiating with Daid to have it integrated with Cura-it Makes no sense for me to reinvent wheels that he's already done such a good job of.

[Daid 306]

g-code is in progress I hope.

I just did some GCode export for my own slicer, should be easy to adept that for your intermediate format. I did notice my slicer is faster then that it can write the GCode to disk

 

I'm negotiating with Daid to have it integrated with Cura-it Makes no sense for me to reinvent wheels that he's already done such a good job of.

I'm working towards having multiple slicers in Cura. Is quite some work due to my bad code :-)

(Also, my own slicer just produced it's first GCode, without any infill so far)

[tom 0]

Thanks for the updates guys. I look forward to hearing more.

[alaris2 1]

we should all be writing one slicer (ideally one where I do no work and everyone else makes a perfect slicer I can use instead there are at least 4 people writing a new slicer here - this is a dilution of effort

any chance the others could hurry along with their code a bit (I'll go and play minecraft for a month so that mine becomes redundant?

[tom 0]

we should all be writing one slicer (ideally one where I do no work and everyone else makes a perfect slicer I can use instead there are at least 4 people writing a new slicer here - this is a dilution of effort

any chance the others could hurry along with their code a bit (I'll go and play minecraft for a month so that mine becomes redundant?

This is why I watch this thread haha. Just waiting for the next better thing while I keep calibrating etc...

I'd contribute if I could, but unfortunately besides simple web languages I don't know much when it comes to programming.

[codemaven 0]

I've been playing with mine whenever I get a chance... But I still have nothing really worth showing though... I spent a couple of hours last night chasing a red-herring in my algorithm that sorts line segments into continuous paths... I'd really like to spend some more time on it, but unfortunately I spend 8 hours a day writing code at work, and then have an hour commute home to my girlfriend... so I'm lucky to find 30 minutes in a month to devote to my own projects.

[alaris2 1]

Daid is best placed then to overtake our efforts and achieve world domination! go Daid!

[Daid 306]

I did my first print with my own slicer code. Just set the insets amount to 20 so it produced a 100% filled print, and it worked :-)

[alaris2 1]

insets = shell?

[Daid 306]

Yes.

[alaris2 1]

hmm. I scratched my head for several hours trying to decide how to do shells without massively slowing everything down. I haven't come up with anything yet.

any suggestions welcome, otherwise it looks like Daid is well ahead so I'll pass the thread over to him

congrats Daid and good luck, but make sure you address all the features people wanted - we expect only the best from you

[Daid 306]

I used clipper:

http://www.angusj.com/delphi/clipper.php

it has an offset function. (my only external library I used next to libc, and it was easy to compile into the code) Did add a bit of runtime, as it now takes 10 seconds to generate the GCode for a 20 shell Ultimaker robot. (10mb of GCode)

[alaris2 1]

ahh, you stayed in polygon land, I wondered about that.

I got the GPU to do most of the hard work for me, which guarantees that if it looks OK on screen, it will slice OK too (all broken geometry is automatically fixed).

the difference in speed is tremendous, but it has one small drawback.. there's no way to do shells in glsl :(

the only solution I can think of would be an application which fixed broken geometry meshes first and generated a 'thickness' function (pure offset isn't robust but better than nothing) - this could then be fed to the GPU to maximize speed but the advantage of fixing broken geometry is then lost..

[Daid 306]

You can do shells in GLSL ;-) but you need multiple passes, with every pass of the shader you shrink the "polygon" a bit. But it's quite slow actually. I have a bit of python code which does this. But speed and limitations by different video cards caused me to abandon that route.

[codemaven 0]

Hmm, sounds like you're both taking much different approaches than i am. My slicing function returns an array of 2d polygons for each continuous loop on each layer with normals on the line segments. I'm just scaling those polygons by multiplying each point. A negative number for polygons with exterior normals (outside facing walls) and a positive scale for interior normals (inside facing surfaces.. i.e. holes).

Cheers,

Troy.