a brand new slicer - does what YOU want?

[alaris2 1]

to explain the commercial thing Daid - I don't think it will affect you and the AGPL shouldn't matter either.

the exclusion is:

1) you wouldn't be able to sell Cura - but you're not anyway are you?

2) you couldn't claim endorsement - which I doubt you'd do anyway

3) you couldn't use the slicer as a means to sell a product (UM), by inferring your product was better than other peoples on account of the slicing (because the slicer is both free and not printer specific) or infer that it was the work of UM (ie. not give credit where credit is due whilst increasing the apparent value of the company).

branding etc. is no problem at all. i expect that. these clauses are there to prevent a certain company starting with M from paying $50 for a feature upgrade to make it work with their printer, then trying to milk it like a cash cow.

about the source code - I simply meant there won't be a publicly accessible github or whatever it's called repository of source code you can just download and start hacking. end user will see it in executable form, pre-configured to work straight out the box.

[alaris2 1]

bit quiet on this topic - I confess I had expected more 'wants' and such.

just as an update - I've written the core code now. it loads 85MB of stl in about 20 seconds and slices it almost as fast. am working on support, interior fill and g-code generation next.

you've still got a chance to throw in your 'wants' before I release something!

[snowygrouch 1]

1) It would be nice to be able to do not just the support in a new matierial, but also the infill.

2) Again, sorting out the "staircase" wall thickness issue, where top of arches can end up with holes even at

2mm "wall thickness".

3) Different feed rates possible for infill and support.

4) 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.

[msurunner 2]

bit quiet on this topic - I confess I had expected more 'wants' and such.

just as an update - I've written the core code now. it loads 85MB of stl in about 20 seconds and slices it almost as fast. am working on support, interior fill and g-code generation next.

you've still got a chance to throw in your 'wants' before I release something!

Nice job on the slice speed! Keep it up! You da man! Chest bump!

If you can get all of the wants we've got here I think we are going to be golden.

[IRobertI 520]

Right, I'll just throw in a few random things that I've wanted from time to time. Sorry if I'm repeating stuff. This is a "stream of conscience" post.

 

• 
  [*:3n9i7s3z] Individual speed settings for the different types of lines being put down (outer shell, inner shell, infill, support etc)
  [*:3n9i7s3z] 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.
  [*:3n9i7s3z] Being able to specify roughly where the z-scar will end up
  [*:3n9i7s3z] When printing more than one separate object at once, pick where the printer will jump between the objects (to minimize surface imperfections).
  [*:3n9i7s3z] Another vote for the "staircase" issue.
  [*:3n9i7s3z] 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. Not much point otherwise IMHO.
  [*:3n9i7s3z] Different kinds of infill patterns
  [*:3n9i7s3z] Different kinds of top-/downskin patterns
  [*:3n9i7s3z] Basic STL manipulation, as in being able to rotate them properly.
  [*:3n9i7s3z] Speeed, lots and lots of speed After I started using KISSlicer printing became fun again. Being able to change a small setting, re-slice, look at the gcode visualisation (this is an essential feature as well btw), change something, re-slice etc in the same time it took cura/SF to slice just one time was a welcome improvement.
  [*:3n9i7s3z] Sometimes I've felt that I wanted to change speeds depending on which part of the model I was printing. Maybe something like a feature that lets you specify speed based on at what height you are in the model could work? So at z z4mm->z10mm set speed to 100, at z10mm-z30mm set speed to 30.
  [*:3n9i7s3z] "Good support". I don't really have any input here more than maybe doing support similarly to KS where it starts small and then as it gets closer to what it's supposed to support it branches out. IIRC Netfabb does it this way as well. It reduces material waste and makes it easier to clean.

 

I think my brain has pooped out enough for the moment. Again, these where just random thoughts as I was typing. But all of them have been something I've wanted at one point or another.

[alaris2 1]

that's awesome robert, sg, keep it up. I'm compiling a list right now with the aim to either do, or at least provide future support for as many things as possible.

[kristen 0]

I'm curious how you're managing to make all these speed improvements. Are you utilizing PC specific instructions ? If you can slice a big STL in 20 seconds on your PC, do you think the program could be ported over to Android and run on an inexpensive dual or quad core ARM tablet ?

[msurunner 2]

PLEASE SAY YES!

[alaris2 1]

well porting might well be possible. I was thinking i'd get it working first on a PC and see if people like it tho. is there a demand for slicing on android?

[msurunner 2]

I'm going to go out on a limb and say that in the very near future there will be. But I'm definitely for some beta testing beforehand in the PC world!

[codemaven 0]

I think the speed comes down to a good design in a fast language... Skeinforge is written in Python, which is not known for speed... As a dynamic language it simply cannot keep up with C++ or even Java. It also (from the little bit I've looked at) seems to be a huge mess of rand bits bolted together without a unifying design....

Simple slicing can be fast, but this will slow down as features are added. Depending on how it's done the in-fills and such can be quite expensive.

I myself have just started working on a slicer in Java as a pet project. This is one thing I've been thinking about for a while. I'm writing it in generic Java so I should be able to build it for Android as-is without any major changes. That is one of my goals. Also I want to run it on the web too, either as a web service or cross-compiled to javascript in the browser.

So far I've been slicing a 1meg stl file with 5100 polygons in about 190 milliseconds. I do not have infill or up/downskins working yet, but I know how to implement it. It's just a matter of finding the time. I'm hoping to have a demonstratable slicer with infill and up/downskins at least (if not g-code generation) soon, however I'm going on holidays next week so I probably won't have time to work on it any more until January. This is only a side project for me, I don't know when / if ever I will release it... If I loose interest I'll happily share the code.

Cheers,

Troy.

[Daid 306]

FYI, without pypy (that I use and gives a 4x speedup) Python is about 50x slower then Java when I measured it. So, yes, Python is a very bad option. Java does a lot better, and C/C++ can get the most speed here.

(And indeed, Skeinforge is a huge bag of random shit hold together with strings)

[codemaven 0]

I used to be a hardcore C++ developer who scoffed at Java developers.... But these days professionally I'm working on high performance Java applications at work for stock market trading.... and I've been impressed. The JVM has improved by leaps and bounds in recent years. We're pushing gigabytes of realtime market data through our Java components without breaking a sweat. I'm still not a fan of a lot of aspects of the language itself, but that too is improving. Java 6 is a big improvement over Java 5, and likewise 7 is a big improvement over 6.

My experience with the latest versions of the JVM is that they tend to perform as good, if not better than similar C++ programs. This is because there is so much optimization in the JIT compiler, most C++ compilers are just not as up-to-date with the latest techniques for optimizing the generated code on the latest CPUs... It still holds true that Java programs load slower than C++ programs, and well tuned C++ programs have the potential to be faster... but in practice this is often not the case.

Cheers,

Troy.

[alaris2 1]

Troy is basically spot on there, especially the point about speed decreasing as you add features.

for example today I had to decide how to handle the massive memory storage requirements that comes with generating support structure for a model that takes the entire Z height of the UM.

even with maximum compression I was topping 4.5GB. I can't really allocate that as memory, but if I allocate it as disk-side storage it will have a massive speed penalty.. all for a corner case that might never happen in practice..

[msurunner 2]

Not to try to make you write 2 sequences, but perhaps a full and lite version?

[alaris2 1]

I might do that - the trouble is that if someone fills the build area with insane detailed model I'll either have to crash miserably or make it work at the expense of 99% of sane models.

to decide where the split needs to be - does anyone have any feel for how large their typical models are? is a z-height of 10cm too small for example?

on a similar note, does anyone have a feel for the finest resolution detail they want to see reproduced (within reason of the nozzle spec obviously) 0.1mm?

[IRobertI 520]

10cm would be cutting it close I think. The tallest things I've printed so far have been 12cm and 14cm.

I assume you're talking about z-height resolution? Because I don't think 0.1mm is possible with a 0.4mm nozzle is it? For layerheight I usually print at 0.16 (don't know why, it just seems to work well) for good prints and go down to 0.1 when I want it more purdy. 0.1mm layers with the half height perimeters I mentioned earlier would probably keep me satisfied.

[codemaven 0]

I normally print at 0.08mm layer height as that is the default in NetFabb, but when I want really nice quality I go as low as 0.04.

Last night I sliced a 147meg STL file (the full fat yoda bust) with my Java slicer at 0.04mm layer height in 24 seconds. That's total time to read the file in and slice it into bsp trees. I'm using 4 worker threads for the time being, but I can change that number. I've started the base code for adding in-fill, but it's not working yet. My design allows for any number of in-fill patterns very easily. I'm thinking of starting with cross-hatching and honeycomb patterns.

I'm not sure how to calculate support structures yet. I can only think of one way to do it, and it's not a very attractive approach...

Cheers,

Troy.

[msurunner 2]

Last night I sliced a 147meg STL file (the full fat yoda bust) with my Java slicer at 0.04mm layer height in 24 seconds. That's total time to read the file in and slice it into bsp trees.

Damn...

I would like the ability to go down to .05, but if that was achievable through a better halfskin then a half thickness wall printed twice, the .1 would be acceptable. That kinda ties into separating infill and skins to allow for either different print speeds or thicknesses.

15 cm would probably be safe, though I'm generally in the <=10 area as well at we are getting to a rather large build volume at that size...

[codemaven 0]

My approach is to take the NetFabb style of things and define different settings for different region types. So you can have different speeds for outer walls, inner walls, upskins, downskins, and infill. I also intend to give every option the ability to skip layers so you could slice it at 0.05mm and do infill and inner walls only on every second layer thus making the visible outer wall happen every 0.05 layers (printed nice and slow for good surface), but everything else inside effectively at 0.1mm layers.

[kristen 0]

Regarding the memory usage, could you have an option to use a cache file on the hard drive if the user doesn't have enough memory. Even my little AMD based netbook has 8gb of ram. I don't remember ever seeing someone completely fill their build space, but it's pretty common to max out 2 axis on a print. I've got several glue carriage designs to try that will all need to be printed vertically to max height.

[alaris2 1]

I normally print at 0.08mm layer height as that is the default in NetFabb, but when I want really nice quality I go as low as 0.04.

Last night I sliced a 147meg STL file (the full fat yoda bust) with my Java slicer at 0.04mm layer height in 24 seconds. That's total time to read the file in and slice it into bsp trees. I'm using 4 worker threads for the time being, but I can change that number. I've started the base code for adding in-fill, but it's not working yet. My design allows for any number of in-fill patterns very easily. I'm thinking of starting with cross-hatching and honeycomb patterns.

I'm not sure how to calculate support structures yet. I can only think of one way to do it, and it's not a very attractive approach...

Cheers,

Troy.

ooh, maybe I should just wait and let you do all the work that's pretty good Troy!

[codemaven 0]

Haha. We'll see how quick it is when It's fully functional... Besides, I probably won't have time to work on it much for a while. I'd like to see what you come up with independently and then maybe we can compare notes.

Cheers,

Troy.

[codemaven 0]

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...

[alaris2 1]

holy moley!

i'm running on a crapped out 1-core P4 :(