Week 9: Processing...

It's crazy how little is happening in school nowadays. With AP tests over, half of every school day is a study hall. Gives me plenty of time to work on this project.

Anyways, I've been implementing the GUI, linking controls and commands and functionality. For example, I can select which serial port and projector to use, and the layers shown in the preview window are based on chosen settings.

But there's not too much more to show off (it all looks the same as yet), but big things are coming.

Week 8: GUIs Galore

I figured it was about time for me to make this program into something that I could actually use, so I began to put in all the controls I, as an end user, might need. I keep the 2D preview window, add a slew of buttons and combo boxes, a progress bar, and retain the text window for a log, and get this:

Why Qt Creator is amazing. Making this is a cinch.

It's significantly more complex than last week's iteration, and will need a bit of work to debug. Then I'll plug in some hardware and see what happens.

Good news about using both the computer monitor and an external projector on the 3D printer itself - Qt makes managing displays extremely easy with a built-in library to do just that. This means that the only remaining part I need to look up are serial port controls. I'll get to it.

Week 7: How to Make a Polygon!

I'm elated. I just typed about one hundred lines of code, describing a fairly complicated algorithm I created on the fly, sure that it would fail horribly, and it worked. The first time. Practice makes perfect after all.

That algorithm took the lines created from the intersection of the STL 3D mesh and some plane, removed duplicates, then joined them together into polygons. Each line endpoint was joined to its nearest neighbor within a specified tolerance (for more robust results than other algorithms), and the end result was a set of disjoint polygons. Voila!

Filled polygons and a black canvas in the back.

That concludes the hard part of this program. All that's left to do is display images on a projector, interspersed with sending serial commands to the 3D printer itself. In fact, notice the black background: that's a full screen window ready to display those images. The year's coming to a close, and so is this program.

Week 6, and I'm Almost Done!

I'm back from the FIRST FTC championship with great news - we're division champions (thereby in the top 5 teams out of perhaps 5000 worldwide)! Here's our team logo plus ourselves and our winning bot in the background:

Team FTC 4290 - our best year yet!

One team member put together an amazing wrap-up video here. See if you can figure out why we call the robot "GiraPHPHe."

In other news, the 3D printer control software is progressing nicely. I'm putting the finishing touches on the GUI and slicing logic. For example, I can now do this:

Slices at z = 19 through 28 mm of a brain lobe and Yoda.

I love these cross-section animations. Not only do the look amazing, but they also mean I'm closing in on a final product. Once I fill in these shapes and change the entire thing to a full-screen view (perhaps on a second monitor), I ought to be able to test out the printer. I wonder if I have time this week... it's so tantalizingly close!

Week 5. Sort of.

Wish me luck, because I'm going to miss 2/3 of class this week for the FIRST FTC Robotics World Championships in St. Louis, MO! My team, FTC 4290, is tuned up and our chances look good. We're looking forwards to the competition.

Unfortunately, that means I've only had a bit of time to clean up code and do a little bit of 3D geometry manipulation in my code. But I promise that more's coming!

Thus, without further ado, I'll make my way to the Gateway to the West...

Week 4: Successful Slicing

Sounds kind of like a cooking show, doesn't it? You slice cheese, you slice apples, you slice 3D STL mesh files. Well, bon appetit! Here's where I am as of this week:

A 2D layer ("slice") of a 3D triangle mesh

Here you see the 2D layer formed by intersecting a pretty little Porsche with the plane z = 14mm. I've added a nifty little checkbox and layer height selector for the convenience of the user, although everything will need to be automated later. However, I bet I could put this into the 3D printer I'm building and get something recognizable out of it - I have only now to fine-tune my algorithms and connect to peripherals. Onward and forward!

Week 3: A Little Bit Further

I have to admit I was coding a bit slowly this week - the FIRST robotics world championship (Go FTC 4290 and FRC 418!) is coming up, so I've been getting ahead on homework. But that doesn't mean I haven't been able to do much.

I've started manipulating the 3D meshes themselves. They're loaded into memory, where I calculate their bounding box (as before) and render them in 2D from a top view. Here's what it looks like:

First attempts at displaying a 3D mesh.

The user can now open a file, see it to scale on screen, then drag it around. The light grey square is the build platform; anything the 3D printer can make must fit inside it. Thus the user is able to open multiple files and arrange them as he sees fit. Here I've opened a bust of Yoda and half a human brain. It works well.

Next week I'll start adding in slicing capabilities - the heart of the machine.

Week 2: QT Static Compilation

The project's coming along nicely this week. I finished porting my pure C++ STL-reading code over to Qt (the cross-platform GUI framework), first of all, integrating everything into one application. I think this will be easier to manage than using two programs as I had originally envisioned. In any case, I can now duplicate last week's feat with a GUI:

Integrated GUI and STL file management

But I spent much more time on something a little more under-the-hood: QT deployment. Once I finish my application, I want to compile it to a single executable file for simplicity of use. Unfortunately, neither the Qt library nor the Qt IDE, Qt Creator, support this use out-of-the-box. Instead, as shipped, they require one to provide the end user with the executable and a host of compiled QT libraries, which makes for a bulky installation. The only upside is that this allows easy plugin and upgrade management - but I need neither of those. Thus I had to recompile the QT toolchain for "static" executable compiling, i.e., my program and all Qt libraries will be put into a single exe. The file will be larger, but easier to use. Here's how to do it, following instructions from here.

1) Download Qt with MinGW and install. Make sure to add the MinGW environment in the installation.

2) You'll also need Windows PowerShell 3.0 or higher and 7-Zip.

3) Download this Windows PowerShell script.

4) Now, the default Windows setting is that PowerShell scripts are not allowed to run. Follow this guide to allow execution of the script.

5) Run the script; it'll take a few hours to gather all its resources and execute. You'll now have a statically compiled Qt distribution.

5) To use this static Qt distribution, follow along with the rest of the aforementioned tutorial.

And that's it. So I now have a statically compiled version of Qt, ready to deploy my 3D printer driver anywhere. Next week? Some math and algorithms sound in order.

Final Project Part 1: STL Files

We're now on the home stretch of this Advanced Computer Programming class, so the class is starting to work on final projects. I decided to program a 3D printer from scratch. Should be fun :).

The basic idea is this: the SLA DLP 3D printer (which I'm building on the side) uses a standard computer projector to solidify subsequent layers of light-curable resin. The result is a physical object. So my program needs to take as input an STL file, which represents a 3D mesh of triangles. It then needs to calculate the cross section of the file at each layer height (of which there are many - objects 4" high with 0.1mm accuracy take 1000 layers) and send a corresponding image to the projector. At the same time, it should connect via serial communication to a microcontroller which moves a build platform to change layers.

My focus this week was the basics - just read in and process a binary STL file. I began by downloading some sample files here. Here's a 3D model of part of a pump:

An example STL file.

The STL file format itself is pretty simple: an 80 byte header, a 4 byte uint representing the number of triangles in the file, and then repetitions of a block of data representing each triangle: a surface normal represented by three floats, three points each represented by three more floats, and an extra 2 byte uint.

Result of reading in aforementioned example.

So here's what I came up with after a little tinkering. This file's 80 byte header contained "Uncompressed stl file", there were 178689 triangles in the file, and the object has the bounding box (every triangle fits inside) 1 < x < 5.2646, 1 < y < 8.587, and 0.4 < z < 3.8309. This looks promising!

Having succeeded with my goal for the week, I started to learn Qt, the popular "cross-platform application framework" that should let me easily create a GUI for my project. It's amazingly user-friendly, so I was able to do this with a few hours of work:

As yet, this little window has a fully functional menu ("New", "Open", "Save", "Exit", etc.), a text output panel on the left, and a graphical display panel on the right. The plan is to open an STL file, display its 2D shadow on the right, allow the user to place it anywhere on the printer build platform, and then, well, print. Each of those green square represents a different STL file - I can drag them around. Next up is translating my STL-reading code to Qt language so I can combine the two.

All in all, not a bad week's work!

A New Year and New Ideas

Happy New Year! 2015 is here.

Our class is discussing new ideas for this CS course, and, besides reasonable things like a calendar, people want, e.g., a Fajita Friday. Food in a computer science course. Who would have thought? But some also want to make a larger project, perhaps authored by the entire class. That could be interesting.

I'd like to make an efficient 3D printer control system, but that's just me. I doubt many will want to work on a project they could never use. Perhaps we could build a MIDI sound controller.

Actually, this could be fun: hold a Core War tournament. Core War is a 1984 computer game / competition that pits two programs against one another in an isolated area of memory. Competitors write programs (called "warriors") in an assembly-like language called Redcode. Every student in the class could write warriors and submit them to a competition system - perhaps one that we also write - and would be free to do so until the end of the year. Give awards for the program with the highest rank at the end of the year, the one with the most time in top place, etc, etc. It'd occupy an entire semester but not need much work from any individual, although each person is free to submit as many warriors as they wish. The source code could be freely shared with the world afterward.

Whatever happens, this is going to be a great semester.