Just a little piece of 3D Printing history. Skeinforge, and SFACT.

(ThantiK) #1

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

This piece of software was DOG slow, and could take hours to slice moderately complex geometry.

(Ben Malcheski) #2

Oh man, that was a slow beast of a program and a real PITA.

(Kurt Wendt) #3

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…

(Michael K Johnson) #4

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

(Ryan Carlyle) #5

“Back in ye olden days of 2011…”

(Griffin Paquette) #6

I will never complain when Cura takes 20 seconds to slice again…

(Dave Durant) #7

There were really only 4-5, maybe 6, settings in Skeinforge that everything else was based on… Once you got those dialed in, the rest was just tweaks.

Whatever else you want to say about it, Skeinforge was FAR ahead of everybody else…

(ThantiK) #8

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

(Dave Durant) #9

Well… Some people knew… :stuck_out_tongue:

edit: wow… things sure have changed… talking about DC extruders in there… LOL.

(Nathaniel Stenzel) #10

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.

(Steve M) #11

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.

(Joe Spanier) #12

back in my day we had oozebane and not this retraction gobbledy gook.

(Dale Dunn) #13

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.

(Ryan Carlyle) #14

@Dale_Dunn RepG running Skeinforge 40 in the background here :smiley:

(Kurt Wendt) #15

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…