# Godel Escher Bach QR Code shadow cube

## by SashimiTabernacleChoir, published

## Description

The shadow of this cube in different directions gives QR codes pointing to the Wikipedia articles for Kurt Godel, M.C. Escher, and J.S. Bach respectively. Also a pretty challenging print test. Note that QR codes cannot be read in mirror image, so only 3 of the 6 possible cube orientations cast a readable shadow.

Notes. This was generated using a reduced-url QR code generator, a paint program to connect disconnected sections, Inkscape to convert to dxf, and OpenScad to extrude, rotate, and intersect the 3 images. OpenScad rendering took almost 30 minutes on a fast computer.

QR codes are fortunately very forgiving of fairly large modifications due to their built-in parity and redundancy schemes, and I verified readability of the images up through the dxf stage. (Although I got pretty close to the limit on one image, and my camera QR scanner had to rescan a few times to get a read.)

This is a complex image. To get a readable shadow your light source will need to be pretty far away to get a flat pass through. Perhaps someday I'll do a version with transformed geometry, matching specific close-up point sources.

If you can't get it to print cleanly enough to read, hey, claim it's a Borg Cube and gift it to your Trekkie friends.

## Recent Comments

view allI think this one may be in the category "cool in principle but not in practice". For one thing I'm no longer convinced all the mass in the interior is supported.

## Tags

## License

## Give a Shout Out

## Instructions

Best to print this in black; then you may be able to get a QR scanner read looking directly at faces rather than shadows.

#### File Name

#### Downloads

#### Size

Please Login to Comment

I think this one may be in the category "cool in principle but not in practice". For one thing I'm no longer convinced all the mass in the interior is supported.

I hadn't thought about this in a storage density context. For this cube, 3 x 4296 bytes would be an (unattainable) upper limit. The actual capacity would be much much less than that because you have to seriously distort the pattern to get enough connectivity to provide support for all the pieces,

which typically are pretty disconnected in a QR.

An interesting question though is what would happen if you took a sphere of radius R, and sliced out a distorted QR with edge size L = a * R for some a

&

lt; sqrt(2). (Visualize this as a sphere with a square tunnel running through it, except the square tunnel isn't empty, it is a QR extrusion.) Now radially slice n such QR sections through the sphere starting at n different 'excavation' points on the surface. That would seemingly give us a higher storage capacity per object volume than the cube in this posting. But what are the conditions on n, a, and the excavation point locations that guarantee the n QR images will not contaminate each other or leave unsupported pieces of material inside the print? There will certainly be an upper limit on n unless a goes to zero. For that matter, it seems intuitive that the cube 'thing' pictured here will not have any unsupported interior chunks, but I have no idea how that might be proven.

Interesting.

i'm interested in what the typical storage capacity of one of these could be.

what would the error correction rate be here ?

according to the wiki article: en.wikipedia.org/wiki/QR_code#Storage

you can store a maximum of 4,296 alphanumeric characters per face.

how much could someone expe

ct to store one of these ?

and how would the light source effect that capacity ?