Just a little piece of 3D Printing history. Skeinforge, and SFACT.
Back when we all used this, it was almost impossible to know what was actually wrong with your printer. So many settings in skeinforge would have been better as automatically calculated values, and most people didn’t know what affected what, and in what manner or why.
With the introduction of “SFACT”, lots of those settings which would mess your slicing up disappeared, and people started focusing on sane calculated values in the slicer. From there, people started realizing the importance of correct E_STEP values, etc
No WONDER It was slow. Yeah - I knew it was Python based. And, AFAIK - Python is essentially a Scripting language - or interpreted - like BASIC. And, this - since its not compiled - it runs slow - Of Course! And - yeah - it was the backbone behind RepG - which is what I used on my MBI CupCake!
So - back in those day - I knew it was slow. As such, I was always VERY Careful about how I designed objects - and purposely limited how many Polys made up the object! Huge # of polys - and HELL - you could Wait hours, or it would simply Crash RepG/Skeinforge! Well, even to this day - I try not to go really nuts with hi-poly counts. Even though slicers like Cura are more advance…
@Kurt_Wendt that’s kind of a misunderconception. Python is a byte-compiled language, and it is possible to write reasonably fast code in it. It’s also possible to write slow code in any language!
By way of comparison, Java is also a byte-compiled language, but it doesn’t bundle the compiler with the runtime or offer a interpreter prompt the way Python does.
@Dave_Durant The problem was that people didn’t understand which settings affected which other values, so there could be 1 variable, that affected like 3-4 other things.
I seemed to have an intuitive sense for how things linked together, but most people didn’t at the time. It was all rather new. I remember running Skeinforge/SFACT on PyPy, a JIT-compiled python interpreter written in python.
Skeinforge and SFact did not use numpy or scipy. Someone had a github project for a Skeinforge with numpy though. Scipy includes numpy. Numpy can add massive speed improvements to data crunching. I use it in my bucketmill cnc milling toolpath generator. It made bucketmill roughly 10 times faster.
man, I spent days tweaking skeinforge, adding my own little tweaks to it, got it printing to perfection. I honestly miss skeinforge but holy moly was it ever slow. That’s the only reason I stopped using it, speed.
I’m lucky. Being a relative noob, I started on Skeinforge 40 and never had to deal with DC extruders, or trying to calibrate and program by the length of extrudate. Even so, my first prints were shockingly bad by today’s standards. I never did get really good at tuning, though my prints were functional. When Simply3d came along, I gladly paid. But without Skeinforge, I doubt I could have gotten off the ground with 3d printing.
Yup - that’s what I was using too! I was still using RepG up until about 6 months ago to control and run prints jobs on my “SupercupCake” - but, alas - the SCC is now sadly in storage…
