3dc - A 3D File Format Converter

February 10, 2011

With Kwartzlab's recent 3D printer aquisition, we needed to put together a set of tools for members to create objects that could be printed by the machine. The RepRap printer we purchased has an associated open source project for loading standard 3D object files, called stereolithography (STL) files, and converting them to the printer's machine language, called G-code.

Unfortunately, there was a potential show-stopper issue with the RepRap software - many of the STL files we tried to load, like this 3D version of the Kwartzlab logo I made, were getting corrupted.

Suspecting there was an error with the way the software was parsing the STL files, I decided to write my own translation program to use as a reference when fixing the bug in the RepRap code.

The bulk of the work was done at a late-night hackathon session put on by the Computer Science Club at the University of Waterloo. By the end of the weekend, I had a program that was able to read and write ASCII and binary STL files. This code is now available on my GitHub page.

I ran the "corrupt" file through my translator program...


        $ 3dc stl kwartzlab.stl stlb kwartzlab-bin.stl

... and found that the RepRap software was now able to correctly read the file.

With STL processing now working properly, I'd like to continue working on this 3D conversion tool. My next goal is to add a few more codecs for different file formats, such as OBJ (a versatile format often seen in simple 3D software), and X3D (a next generation format for web-based 3D applications).

I'm also interested in building codecs for some more unique formats like Activision Blizzard's M3 format seen in Starcraft 2. This would give us the ability to create STL files directly from in-game assets, which could be milled or printed from any of Kwartzlab's CNC tools.

Another interesting application for me would be the generation of G-code - the actual instructions that get sent to the CNC machine. This would be a challenge, since each CNC machine has its own quirks, so G-code that works on one machine may not work on another. However, I suspect there are some kinds of toolpath optimizations that could apply to all machines, much in the same way that the GNU Compiler Collection can optimize a program before converting it to machine code.