1. How large portion of your print time is skeinforge (time before the printer start moving)? Please let me know if you use something else. 2. Would you print more if it was quicker? 3 Is there room for a graphics-card accelerated (less wait time) version of skeiforge?
So why am I asking? Short answer, I’m one of those Graduate students that like doing optimizations, especially for graphics cards. Recently my institute (CS @ UiO) started a small hacker-space, and the time skeinforge uses just provokes me.
I’ve used Slic3r pretty much exclusively and generally speaking it takes 1-5% of the time it takes to print the object to slice it. That said, I’m slicing on a pretty old machine and have my print speed turned down as well.
Slicing time has more to do with the complexity of the object than the size so it won’t always be proportional to print time. I think on a new fast computer slicing will take a trivial percentage of your time.
Many of us have abandoned skeinforge long ago. Slic3r (written in perl) is quite performant and usually has operations done on a standard sized model done in 2-5 minutes. There is room for optimizations, there is room for more slicers in general. PyPy speeds up skeinforge quite nicely if you still use it, to the point of only being about 150% the slicing time of slic3r…comes out to about 3-7 minutes a print generally.
No. Slicing isn’t really what’s holding many people back, calibration, etc is. Heck, changing settings and making sure you’ve got it setup for whatever you want to do generally takes a large fraction of the time it would take to slice an object.
It’s really been proven with KISSlicer that the GPU isn’t really needed for these operations. KISSlicers downside is that it is not open source, therefore nobody can change/optimize it except the author. If a new slicer were made that were built from the ground up for modularity, and optimization, operations could take easily under 30 seconds or so. That’s not really worth speeding up with the GPU.
Thank you for quick and good answers. I’m going to look though Slic3r to see how much work it would be to add/covernt parts of it to GPU accelerated code. I prefer contribution instead of competing, and Slic3r is ApacheGPLv3.
@Asgeir_Mortensen competition is good even in the open source community. Competition is what got us Slic3r in the first place. And tbqh, Sound/Alexrj is quite the stickler as far as control over Slic3r. I’d love to see something built from the ground up if you’re good with geometry and 3D model operations. Even better if such a tool had a well documented ABI that everyone could hack on.
And, as a student, constant writeups on your progress, etc would be welcome. I’m interested in how these things are done in code. How a slice is made, etc.
Competition does help innovation and features gcc and llvm are great open source examples. However I’m completely lacking people that even want to think about GUI design.
That said we’re already a team of 5 from UiO, and I’m hoping for a at least one more talented member around February. A well documented call-tree as well as API will make or break this project.
As for writeups, it’s likely there will be paper(s) and they will be free for education and tutoring purposes (that should include printing communities).
@Marcus_Wolschon I’m right there with you on the netbook. Intel ATOM 1.6ghz single core EEE 900a. Slicing times have never really been much of a problem for me. Even a 32mb porche sliced in 5 minutes for me yesterday.
@Asgeir_Mortensen the heart of any slicer is an extremely robust polygon offset routine that handles degenerate cases gracefully. This task, by its nature does not lend itself readily to GPU processing because it’s highly serialised and so SIMD doesn’t bring a significant performance increase.
note that a number of slic3r bugs are directly related to its polygon offset routine (in the C/C++ Clipper library) being less than stellar.
If you’re interested in tackling this routine, see Stefan Huber’s work on straight skeletons for some prerequisite reading. He has created a method that can construct a framework for arbitrary offsetting in O(n log n) time which I strongly suspect is significantly faster than either Clipper or skeinforge.
I’m biased- I’m hoping someone writes it in javascript before I have to for my webskein project
Once such a routine has been found or created, the rest of the slicing process is significantly easier. You’ll also need routines for doing boolean ops on polygons with holes, then you can intersect planes with the STL to get layer outlines, propagate the outlines up and down the stack to generate regions such as solid surfaces, bridge, support candidates, etc, boolean the overlapping regions according to a list of priorities, then offset the borders to generate perimeters, then offset again to get a clipping border for your infill pattern.
