Slashdot Mirror
Computer-Aided Lego Art Project
rsk writes "Justin Voskuhl, a Google engineer, in a 2-fold bid to fight boredom and figure out something to cover a large barren wall in his living room, one weekend developed a Java program using an annealing algorithm to figure out the best layout and colors of Lego blocks to reproduce a source image exclusively in Lego blocks inside a frame. He plans to release the source code soon. I probably would have just painted the wall ..."
OK, I have to show off - I did something similar four years ago. :)
Post
Webpage
I'm a much better programmer now, just for the record.
"Slashdotted"? What's next... "story"? Oh wait...
How about glass tiles on a 100'x30' wall, or a 30'x75' wall?
I wrote the code, my brother in law did the hard parts.
Nyud.net mirror. Slow, but works.
The major algorithmic difference is that lego blocks are not [always] square, and figuring out which combination of sizes to use to cover an arbitrarily shaped block of color is NP-Hard. What he has done here is seriously impressive.
Reminds me of the time my buddy and I were playing some 301 at the dart board. Both of us were pretty wasted. I discovered he couldn't subtract, and that was giving him an advantage, so I started keeping score. Then we discovered I also was too wasted to subtract.
We decided I would sit down and code a score keeping program with a text-based GUI (similar to ye olde Vitamin C Screen Utilities). Each player just entered their darts 10, 13, etc. or D20 for a double 20 T13 for triple 13, and B/DB for bullseye and double bull, then the code would do the math. Apparently writing a parser and an event loop with some event handlers taps a part of my brain unhindered by all the alcohol, etc.
cat
This guy has been doing LEGO mosaics for years, and if you google a bit you'll find others and the code for creating them.
Working on getting this horse running again. Sorry for that guys.
That was my bad, Justin sent me some pictures and I popped them up cause I thought it was awesome... and then I realized what "Slashdotted" meant like 35 seconds later.
The Anita Barrio neighborhood. It's along I-10, on the opposite side from the freeway, facing a park. I don't know the exact address off the top of my head.
Yes, but they're always rectangles, with predictable proportions, (1 by X, with a maximum X) you always stack them horizontally, and there's a very limited color palette.
If you think it's difficult to calculate you're probably modeling it wrong.
Actually, it's easier than that. :) Model with 1x1 blocks on the first pass, using standard interpolation limiting to your available palette colors, then combine horizontally adjacent blocks with the same color as 1xN blocks according to availability.
For a time LEGO sold a few grey-scale mosaics, but even better you could upload an image and they'd send you pieces in black, white and three shades of grey, and instructions to create your image. If you just wanted the pieces (they were 1x1 plates) you could upload an image that had shades in the proportions you needed. And since they sent you bags (of IIRC 270) and not exact counts, you could create an image that maximized the number of pieces you'd receive. If your image required 271 dark grey pieces, for example, you'd get two bags of 270.
Finding any one fit of lego blocks to produce a given image is linear complexity (O(N)). It's the same algorithm used in your video card to rasterize a 3-d polygon model or in photoshop to rescale an image. Definitely not NP-hard.
Growing adjacent spaces of matching color to use larger bricks isn't tough either. Use a simple run-length encoding algorithm (second pass, also O(N)) and then when you're breaking up long stretches into brick-sized stretches in the third pass, add a constraint that within a "same color stretch", a brick edge on the current line doesn't line up with a brick edge on the previous line (this pass is also O(N)).
Final cost: 3 * O(N) = O(N)
This guy's approach of determining brick size and location using simulated annealing sounds like a hammer in search of a nail. Definitely cool and fun to write, but probably not necessary to solve the problem.
How do you resolve conflicts when the rigidity rules say one thing, while the brick value rules say another, and the color dithering rules say yet another? There should be a weighting function, and the impact of that decision will cascade down the mosaic, affecting other decisions. Finding the combination of decisions that yields the optimal (for a given set of weights) arrangement is NP.
What would be really cool would be a robot arm that assembles any source image in a Lego target at a specified scale, after the software calculates exactly which and how many bricks are required in the "palette" bin.
And if that robot arm were made from Lego Mindstorms, that would be even cooler.
If a program could run a Mindstorms arm that is totally rudimentary, put together in under 15 minutes by a human, then upgrade itself into the arm required to assemble these images into Lego sculptures, and then assemble the sculpture, well that would be the coolest.
--
make install -not war
Actually, it's easier than that. :) Model with 1x1 blocks on the first pass, using standard interpolation limiting to your available palette colors, then combine horizontally adjacent blocks with the same color as 1xN blocks according to availability.
And then write it in C++ instead of Java.
That method will result in structurally unsound pieces (not enough interlocking). His code apparently optimizes visual accuracy against structural soundness.
You are forgetting that legos must be interlocking. That somehow is a part of the algorithom unless the guy cheated (the frame/glue holds it together). Assuming the picture is two "nubs" thick, The algorithm must combine 1x2, 2x2, and 4x2 blocks in a way where they hold on to eachother - in addition to dithering and making the photo look more realistic.
I'm willing to bet that the code isn't optomised (hey - it's java!). I bet these calculations can be done in a couple of minutes at most, not 10 hours (assuming he's not feeding it 10 megapixel images). It would also be interesting to compare implementations in different languages (C++, python, lisp, haskell, ...)
It would be more interesting to know why it takes such long time. Doing this in photoshop takes about two minutes, including the editing.
Adventure, Romance, MAD SCIENCE!
He's using simulated annealing. The idea is, you start with some state you can get to easily, and then either a) make a random change to the state or b) make a change that tries to improve the state. You have some variable T that determines what percentage of the time you do a. It starts out at some high percent, and then slowly goes down to 0%. The more slowly you decrease T, the closer to optimal your answer is. You can even find optimal solutions to NP complete problems if you let T decrease infinitely slowly.
Basically, this took ten hours per image because he wanted really good results.