Skip to content
Open Source 3D Mesh Slicer in Processing: Generates gcode from stl files.
Java
Find file
Failed to load latest commit information.
data Finished Adding Basic GUI Aug 6, 2010
Area.pde Tweaked shell generation. Sep 18, 2010
AreaWriter.pde temporarily disabling shells as they kill my builds Mar 18, 2011
COPYING Initial add of GPLv3 COPYING file. Sep 15, 2010
Configuration.pde Added missing files for config.txt! Aug 16, 2010
Extruder.pde Got Fill? Even seems to do the right thing adding bridges and capping… Sep 12, 2010
Fill.pde Tweaked shell generation. Sep 19, 2010
GUI.pde Slight speedups to textboxes by using noLoop() and redraw() Aug 24, 2010
Hole_Calibration.stl Added debugFlag and two stl examples that should be slicing flat but … Sep 7, 2010
Line.pde Renamed Line2D class to SSLine (SuperSkein Line) to avoid name confli… Sep 6, 2010
Material.pde Got Fill? Even seems to do the right thing adding bridges and capping… Sep 13, 2010
Mesh.pde Adding Daves ASCII STL code Sep 17, 2010
OpenSCAD.pde Initial add of OpenSCAD wrapper and test code. Set OpenSCADTestMode=1… Aug 20, 2010
Path.pde Figured out the Java Area operations. Needs lots of re-work, but the … Sep 10, 2010
Poly.pde Figured out the Java Area operations. Needs lots of re-work, but the … Sep 11, 2010
Slice.pde Figured out the Java Area operations. Needs lots of re-work, but the … Sep 11, 2010
SuperSkein.pde Tweaked shell generation. Sep 19, 2010
Triangle.pde Renamed Line2D class to SSLine (SuperSkein Line) to avoid name confli… Sep 6, 2010
Z_Bracket.stl Added debugFlag and two stl examples that should be slicing flat but … Sep 7, 2010
config.txt Tweaked shell generation. Sep 19, 2010
pjm-rec2.stl Added another pathological STL to use for slice testing. Oct 7, 2010
readme.txt Found a big bad bug in the bounding box generator, which is more impo… Jul 30, 2010
sculpt_dragon.stl first commit Jul 30, 2010

readme.txt

SuperSkein Manual

*Parameters
Currently, we're doing all the parameters with the godawful UI of having you type them in the first screen or so of code in the Processing sketch.  This is terrible but it's what we've got for now.

--->float PrintHeadSpeed = 2000.0;
The F parameter of the gcode.  Higher values make the extruder move more quickly.
(Skeinforge users take note, This is "FeedRate" in Skeinforge.)

--->float FlowRate = 255;
Plastic flow rate.  255 is the maximum speed.  Low values will not work and may jam your extruder!  On MakerBots I've used, values higher than 170 or so extrude.  Your results may vary.
NOTE NOT IMPLEMENTED YET 

--->float LayerThickness = 0.3;
Space between the layers, obviously.  This affects both where the slicer cuts and where the print head moves.  If you want to distort your model I recommend adding a non-proportion-constrained scale function to the Mesh class.


--->String FileName = "sculpt_dragon.stl";


**Modularity note
I think most of the things we'll do to the file are going to be clearly divided between things we do to the whole mesh or to individual layers.  I think rather than cluttering the SuperSkein.pde file we should make every effort to "push down" modifications to the objects they affect.



*Hacking NOTES


Things like the Sink function (lower the mesh so the bottom layer is big rather than small points, esp for character meshes) I don't know if I want them post-processing or pre-processing.

We've got to worry about time; if you run something in post, you're hacking gcode which is a real (SLOW!!) pain because of all that ASCII and file io.  If you do it before you slice, you can save a TON of hack time.  But then again, we keep introducing hazards to the overall modularity and flow.

(Actually now that I think about it doing ops to gcode might be 2/3 of why Skeinforge is so %$#$@ing slow.)

I don't like the idea of losing modularity.  That's probably a deal breaker.  But how much can we get away with?  Let's take a 10,000 ft look.

Functions like sink, they're natively mesh things.  Things which are mesh native we should go ahead and do to the mesh.  I think if we're at least clear about "mesh transforms" and "slice transforms" and "line transforms" we can steer clear of breaking things too bad.

SO WHAT ARE WE GOING TO DO TO THE MESH, YOU MAY ASK!

Okay, how about this:

*slicing
*skinning
*filling
*shelling
*mesh doctoring
*repositioning the mesh
*support material.... RAYS?  YIKES RAYS


Huh.  About support material.

We could definitely do raytracing.  It's really straight forward when you're z-axis aligned.  (Gosh, all the 3D is easy) Buuuuuuuuut it's volume-filling and not edge-defined, so, make a grid.  What you do there is you put dots on your slices (give them two array lists?  Or more perhaps...)
Something went wrong with that request. Please try again.