Making Slice and Dice more practical

Continued shipping delays with Netfabb's shipping have given me more time to work on my Slice and Dice alternative app than I had expected. I was able to use Slice and Dice very effectively to turn my light frame STL into printable gcode as you will have seen in my last few blog entries. I then made two decisions which have put me in present limbo.

The first decision had to do with my desire to start working on the problems implicit in printing with polypropylene. Bogdan had developed a lot of know how with polypropylene and characterised it as being a lot like HDPE. Owning some 80 lbs of surplus polypropylene, I decided to have a go.

My first use of it was to try to print my light frame structure. After a few days of that I decided that polypropylene, at least the kind I have, is too rubbery for that kind of application. I then decided to see if I could print something immediately useful, like a bowl, and see if polypropylene was going to be as dishwasher safe as advertised.

I went to Thingiverse and downloaded Vik's beautiful tea bowl. I could have easily designed a bowl, but really liked the look of Vik's. Mind, it wasn't going to look as good in polypropylene as it does in PLA, but never mind. I could throw mine in the dishwasher ... in theory at least.

Vik's tea bowl was a much larger object than my light frame. Hammering the STL through Slice and Dice revealed that the flood routine, which delineates printed and non-printed zones for a slice, did not scale well at all. Replacement of my flood code with a Windows API call for flooding sorted that problem out. Slices that were flooding properly in 8 minutes are now flooding in about 7 seconds.

I am currently working on the fill routine which takes a flooded image and lays out the perimeter and infill roads on the printed areas. That routine, too, isn't scaling well and is taking about 8-9 minutes to process per slice. That means that Vik's bowl will take about 40 hours to lay out the 300-odd slices required for printing. The development of the perimeter roads is taking 99% of the processing time. I am going to have to come up with a new way of doing that process. I have some ideas.

One other little thing that I've found is that the massive amounts of disk space that I am currently using for bitmap image storage can be reduced by more than 98% by the simple expedient of zipping the BMP files using the Windows API and unzipping them only as needed.

Slowly, I make progress while Netfabb hangs fire.