Category: Machine Shop

That process produces a grayscale height map PNG image in the proper orientation:

OpenSCAD, however, requires a flat ASCII data file to build a 3D model, as described there.

It turns out that a PGM (“Portable Graymap”) file is almost exactly what we need: a fixed format header in ASCII text, followed by the pixel data in either ASCII or binary. To get an ASCII-formatted PGM file from that PNG image:

convert jellyfish_prep.png -compress None jellyfish.pgm

The top of the PGM file looks like this:

P2
149 159
255
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 255 255 255 255 255 255 255 255 255 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 255 255 255 255 255 255 255 255 255 255
... more data ...

The data isn’t in the XY array layout that OpenSCAD expects; It Would Be Very Nice If OpenSCAD could read PGM files, including the header describing the array size, but it doesn’t. Fortunately, some Bash-fu can handle the reformatting.

First, store the number of pixels along the X axis in a Bash variable:

ImageX=`identify -format '%[fx:w]' ${imagename}_prep.png`

Note the backticks around the whole mess that tell Bash to execute what’s inside and return the value. The -format operation returns the width as an integer, which is what we need.

Now, returning our attention to the PGM file, convert multiple blanks and line ends to single line ends, thus putting one entry on each output line with no other whitespace:

cat filename.pgm | tr -s ' \012' '\012'

Nota bene: there’s a leading blank in the first character string and the escape sequences should read “reverse-slash zero one two” to denote the Unix-style line end character (ASCII 10 = newline). I think the meta-markup works around the usual WordPress formatting, but ya never know what can go wrong.

The first four lines then contain the magic number, X size, Y size, and the maximum data value, respectively:

P2
149
159
255

Those values are all known, because:

• The magic number is P2 for ASCII PGM files. It would be useful to verify this, but …
• The XY values correspond to the image size
• The maximum data value will be 255 because of  the auto-level operation applied to the image’s 8-bit grayscaleness

Strip off the first four lines and wrap the remaining data into an array corresponding to the image size:

tail -n +5 | column -x -c $((8*${ImageX})) > filename.dat

The $((8*${ImageX)) magic comes from the way the column command works: it’s right-aligning each data values in an 8 character column, so you specify the total width of the result in character columns. Think of the parameter as specifying the screen width and you’ll be on the right track.

That fits neatly into a single line of Bash gibberish:

cat filename.pgm | tr -s ' \012' '\012' | tail -n +5 | column -x -c $((8*${ImageX})) > filename.dat

The first complete line of that file goes on basically forever, but it actually has the right stuff. You can examine it thusly:

head -1 filename.dat

The file should then Just Work when sucked into OpenSCAD with the surface() function:

surface("filename.dat",center=true,convexity=10);

And, indeed, it does:

Note that it’s oriented with the head in the +Y direction, the tentacles (or whatever) in the -Y direction, and the freckle over the eye on the proper side. Here’s the original PNG image of the cookie for reference:

Using center=true centers the object on the XY plate, but the base of the solid remains at Z=-1. That makes some sense, as the “solid” part of the model lies below the Z values set by the data: the model includes a one unit thick slab below Z=0 for all points.

The convexity=10 parameter helps OpenSCAD’s quick rendering code (invoked by hitting F5 in the GUI) determine when it can stop looking for intersections between the visible ray and the object. It doesn’t affect the F6 CGAL compilation & export to STL. Because this routine will eventually be used only from the command line, the value doesn’t matter.

That works and the height map looks OK, but the model is too large in all directions and the slab below Z=0 has got to go. But it’s looking good…

While pondering the notion of making cookie cutters, it occurred to me that the process could be automated: a grayscale height map image of the cookie should be enough to define the geometry. The existing height map solutions (like William Adams’s fine work) seem entirely too heavyweight, what with custom Windows or Java programs and suchlike. Some doodling indicates that a simpler solution may suffice for my simple needs, although the devil always hides in the details.

The overall problem with a cookie press involves producing a non-rectangular solid with a bumpy upper surface corresponding to the grayscale values of an image: dark pixels = low points of the surface, light pixels = peaks. The image size controls the XY extent of the solid and the pixel values control the Z, with some known value (likely either black or white) acting as a mask around the perimeter. Given such a solid, you can then wrap a cutter blade and handle around the outline, much as I did for the Tux cutter.

OpenSCAD has a lightly documented surface() function that reads an ASCII text file consisting of an array of numeric values. Each array element defines a 1 × 1 unit square of the resulting 3D object; the example in the doc shows a 10 x 10 array producing a 10 x 10 unit object. Each numeric value sets the height of the surface at the center of the square.

This array, slightly modified from the one in the doc, shows how that works:

9 9 8 7 6 5 5 5 5 1
9 9 7 6 6 4 3 2 1 0
8 7 6 6 4 3 2 1 0 0
7 6 6 4 3 2 1 0 0 0
6 6 4 3 2 1 1 0 0 0
6 6 3 2 1 1 1 0 0 0
6 6 2 1 1 1 9 9 9 0
6 6 1 0 0 0 9 8 9 0
3 1 0 0 0 0 9 9 9 0
9 8 7 6 5 4 3 2 1 0

Feeding that into this OpenSCAD program:

module ShowPegGrid(Space = 10.0,Size = 1.0) {

  Range = floor(50 / Space);

	for (x=[-Range:Range])
	  for (y=[-Range:Range])
		translate([x*Space,y*Space,Size/2])
		  %cube(Size,center=true);

}

ShowPegGrid();
surface("/tmp/test.dat",center=true,convexity=10);

Produces this object, surrounded by a few non-printing 1 unit alignment cubes on the Z=0 plane for scale:

Some things to note:

• The text array looks like it builds downward from the upper left, but the solid model builds from the origin toward the +X and +Y directions, with the first line of the array appearing along Y=0. This reverses the object along the Y axis: the first line of the array is the front side of the object.
• The “center=true” option centers the object in XY around the Z axis, with a 1 unit thick slab below the entire array; the top surface of that slab (at Z=0) represents the level corresponding to 0 elements in the array.
• Each array element becomes a square one unit on a side; the RepRap software chain regards units as millimeters
• The center point of each element’s square is at the nominal height
• The Z coordinate of the edges of those squares linearly interpolate between adjacent centers
• Vertical edges become slanted triangular facets

Remember that STL files contain a triangular tessellation (or whatever you call it in 3D) of the object surface, which means rectangles aren’t natural. The edge interpolation make the whole thing work, because an array of pure square pillars probably won’t be a 2-manifold object: some pillars would share only a common vertical edge. The interpolation does, however, produce a bazillion facets atop the object.

So the problem reduces to generating such an array from a grayscale image, for which some ImageMagick and Bash-fu should suffice, and then manipulating it into a model that will produce a cookie press and cutter. More on that tomorrow…

[Update: image file, height map file, solid modeling, printing]