Monday, March 05, 2007
Bitmapped infill routine
Forrest has been working on bitmap-based infill algorithms for depositing the build material in layers; these have the advantage of being very robust, but they are a bit memory hungry.
Truer words are rarely spoken. Bitmap-based is a bit of a misnomer, though. What I've got is more of a grid-based approach which mathematically is more or less the same thing. I try to set the grid resolution to the minimum positioning increment length (~0.1 mm currently).
I left off working on Slice and Dice (my name for the routines) not long after August in my rush to get Tommelise running mechanically. About a month ago I had Tommelise effectively running and discovered that I had no software to generate instructions for it to print things, so I had to go back to Slice and Dice.
After many adventures and much frustration, I have the processes that transform an STL slice to something that Tommelise can understand more or less running.
I've also had a few inquiries about getting hands on the code from a few Visual Studio wizards amongst the Reprappers. This evening I got the code to a point where I'm not totally ashamed to let it go.
I've given a few more details than this entry has plus a link to the zip file of the code over at the Tommelise blog. You can get at it here.
Be welcome to take it and play with it as you wish. It is in the public domain and you can make what use of it that you will either as actual code to use or as reference for your own work ... or to just have a good laugh at how nasty my coding is.
I make no representations that it either works or works well.
One thing that I am doing that you may find of interest as an approach is this. Slice and Dice does not attempt to directly control Tommelise. Instead, it creates a file which a much smaller control routine takes and turns into driver instructions for Tommelise. This file contains the places to which the extruder head must go when it is turned on.
The file is in ASCII and can be opened in NotePad or the equivalent. Given how big STL files get I wonder if this is not a better way to store information to drive a 3D printer. It certainly takes a lot of the processing pressure off of the PC driving the printer.
I did it this way because I thought that perhaps it would be nice if the printer driver routine could be clicked onto a file like this and drive the printer in background while the Reprapper could use their PC in foreground for the ordinary sorts of things that people use PC's for. As well, as an approach it might be particularly useful for the $100 laptop types who haven't got a lot of processing power or storage space to work with in the first place.
Anyway, those are the sorts of considerations that I had when I put Slice and Dice together. As Adrian mentioned, bitmap infilling is robust, but it is a bit of a memory pig. Right now Slice and Dice takes 125 meg of RAM to accomodate the Visual Studio development environment with Slice and Dice operating. Given that I have 4 gig on my system, however, I can't say that this is much of a problem for me.
As to using a commercial development system, I'm not too concerned. I know that if the demand gets too great I can always translate my code over to Linux compatable JAVA with this sort of software.
For those of you who want to fiddle with Slice and Dice or just look at the code, be welcome!
Links to this post: