3D coding

Well, I decided to have a bit of fun this weekend.

Basically, the 3D printing need several bits of software.

• Something to let you design 3D models - currently using openscad
• Something to processed the output STL in to GCODE, currently using skeinforge
• Something to send the GCODE to the printer and otherwise control the printer - currently using repsnapper
• Firmware in the printer - currently using my hacked about version of shapercube code

I have tinkered with the firmware - made the print speeds consistent even at angles and various other subtle changes. All going nicely. I'll probably do new firmware from scratch, especially if I make new ARM based hardware - but that will be some way down the road.

What I have been playing with this weekend is the STL to GCODE bit. STL is a file format that basically just gives you a list of 3D triangles which you hope make the surface of something solid. The software basically turns that in to print instructions as to where to move the head (X, Y and Z), how fast (F) and how much plastic to extrude (E). You need to consider the outline/surface, filled layers, partly filled layers, layers that are flying over thin area, speed, temperature, all sorts. Skeinforge does a damn good job, and has lots of plug-ins, but is all in python. So far I have ended up writing a post processor for it to lift the head when moving over existing printed output to reduce problems.

Naturally I want to have a bash at this as it is a challenge, and I am doing it in C to be faster as well.

First the STL is sliced in to 2D closed loops that are the solid area for each layer in the model. That bit was actually very easy, though some of the STL files need a slight cleanup as they have flat interior surfaces facing each other and taking no space which makes 2D shapes with dead-end cuts in to the shape, rather annoyingly. It also quite easily makes split straight lines (i.e. unnecessarily two segments rather than one) as you need two triangles for a flat rectangular surface. I have cleanup that handles both, but probably needs to be smarter.

Then you need a toolkit of 2D stuff, and that is where it gets more messy. Obviously primitives like "how far is a point from a line" and "where do two lines intersect" is easy enough. I could remember some from school, but googling you find plenty of worked examples.

Another key thing is the ability to inset a new path that is a distance inside an existing path. In principle this is simple, but you have to allow for mitered corners that are too long and interior corners that consume the line totally, however it was pretty straight forward. The big problem though is bits that overlap or go inside out because the original area is too small at that point. I have the inset working pretty well so can make the perimeter extrude path for each layer now. I even have some overlap code, but messy and not fool proof yet.

So this is where the proper 2D polygon toolkit comes in - you need to identify intersections within a polygon and remove overlap resulting from an inset. You need to be able to perform some key operations on multiple polygons, including union, intersection and difference.

It turns out that this is pretty simple to brute force this, which is what I started with, but does not scale well for speed. There are, it seems some key algorithms such as Bentley-Ottmann which are quick ways to find intersections between polygons. Of course once I have the intersections I then have to carve up what I get to make union, intersection and difference logic, but that bit should not be too hard.

So, I have only got as far as trying to code these 2D tools. Once done, I can then work out the areas to be filled - either solid (because close to top or bottom of an object) or sparse (because totally interior to the shape) - and also where areas are flying over thin air! For that I plan to make them outset in to the adjacent areas to create an anchor for the fill, and working out what is a sensible fill direction to span the space. The fill algorithm itself should not be that complex once I have pinned down the polygons to be filled. This is an area where skienforge is pretty crude, and I hope I can do better.

Finally, once I have the extrude path for perimeter and fill, I have to check for internal overlaps and sharp corners and adjust flow rate for the exact material to extrude to fill the space correctly. Then I can determine the E (extrude) parameters for each path to be extruded, and finally make actual GCODE.

So, maybe half way there. Maybe next weekend I'll finish it. I had hoped it was a one-weekend project, but sadly not, especially with stopping to watch the F1 (well done Lewis).

I hope end result is better than skeinforge, or at least as good. It will be different. I think it will be a lot faster (signs so far are that it is). But the main thing is I will have learned a lot doing it - which is why it is fun in the first place.