Tux Cookie Cutter

Sean asked me to conjure up a Tux cookie cutter for the presentation on DIY 3D Printing and the Makerbot Thing-O-Matic I’m doing at the Mid-Hudson Valley LUG meeting tonight and, as is always the case, it took a bit more conjuring than either of us expected.

For Tux pix, one should start with Larry Ewing’s drawings; I used the EPS version to get a scalable vector drawing. Run it through The GIMP, close the outline at the flippers, fill with black, save as PNG. Then import into Inkscape, trace the outline, and something like this pops out:

Tux Outline
Tux Outline

The reason for using Inkscape is that OpenSCAD imports a very limited subset of all possible DXF files and, while Inkscape can (with some care) produce a DXF format that OpenSCAD can import, somehow the shape lacked interior fill. Sean took a slightly different approach with the same tools and managed to create a useful DXF file that produced this chunk o’ bits:

Tux Slab - solid model
Tux Slab - solid model

The DXF import still didn’t work dependably, so I exported the Tux Slab from OpenSCAD to an STL file; if you want to extrude a solid Tux, that’s probably the way to go. Importing the STL in the next steps worked fine.

The Parametric Cookie Cutter by nateoostendorp creates thin cutter walls by subtracting a linear dimension from the X- and Y-axis extents of the shape. Unfortunately, Tux has crazy flipper feet that didn’t respond well to that; the walls developed gaps at the inflection points from self-intersections.

So I started from scratch with a Minkowski sum, which in this case amounts to rubbing a cylinder all over the Tux shape, then intersecting the resulting mega-penguin-post with a slab of the appropriate thickness sitting on the Z=0 plane. The Minkowski enlarges the XY outline by the cylinder’s radius and the Z thickness by twice the cylinder’s height, which I picked to be grossly excessive. Three Minkowskis produce the lip, wall, and tip of the cutter, which then stack up with a Tux-shaped hole subtracted from their midst:

Tux Cookie Cutter - solid model
Tux Cookie Cutter - solid model

The thicknesses and heights all derive directly from the extrusion parameters used to print the thing, because there’s not much room for roundoff. The middle section (the wall) is four threads wide, but Skeinforge divides the interior pair of threads into shorter sections with breakpoints at each sharp corner. The cutter section (the lip) is one thread wide, because I couldn’t get a good result with two threads.

The OpenSCAD preview has trouble with the Minkowski result and produces weird rendering glitches, but the CGAL model comes through fine. Note that Tux now has the opposite chirality, a gross oversight that became obvious only after the third cutter emerged from the Basement Laboratory. Here’s the second cutter:

Tux Cutter - reversed
Tux Cutter - reversed

Each cutter takes about 35 minutes to build, so I boiled the highlights down into a thrilling 6 minute movie.

The OpenSCAD source code, into which you can substitute your very own STL shape file:

// Tux cookie cutter using Minkowski sum
// Ed Nisley KE4ZNU - Sept 2011

//- Extrusion parameters - must match reality!

ThreadThick = 0.33;
ThreadWidth = 2.0 * ThreadThick;

function IntegerMultiple(Size,Unit) = Unit * ceil(Size / Unit);

MaxSize = 110;				// larger than any possible dimension ...

//- Cookie cutter parameters

Size = 100;

TipHeight = IntegerMultiple(8,ThreadThick);
TipThick = 1*ThreadWidth;

WallHeight = IntegerMultiple(7,ThreadThick);
WallThick = 4*ThreadWidth;

LipHeight = IntegerMultiple(1.5,ThreadWidth);
LipThick = IntegerMultiple(5,ThreadWidth);

//- Wrapper for the shape of your choice

module Shape(Size) {

//- A solid slab of Tux goodness in simple STL format
// Choose magic values to:
//		center it in XY
//		reversed across Y axis (prints with handle on bottom)
//		bottom on Z=0
//		make it MaxSize from head to feet

module Tux(Scale) {
  STLscale = 250;
		  file = "/mnt/bulkdata/Project Files/Thing-O-Matic/Tux Cookie Cutter/Tux Plate.stl",

//- Given a Shape(), return enlarged slab of given thickness

module EnlargeSlab(Scale, WallThick, SlabThick) {

	intersection() {
	  minkowski() {


//- Put peg grid on build surface

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

  Range = floor(50 / Space);

	for (x=[-Range:Range])
	  for (y=[-Range:Range])


//- Build it



difference() {
  union() {
	translate([0,0,(WallHeight + LipHeight)])
  Shape(Size);					// punch out cookie hole

11 thoughts on “Tux Cookie Cutter

    1. sync the camera

      I lust after that, even if it requires custom firmware hackage.

      Alas, the DSC-H5 camera manual says nothing about being compatible with any kind of remote control.

      The old Sony DSC-717 has a 2.5 mm TRS jack using their ACC protocol. It’s similar to LANC, but with enough differences to confuse the issue (or at least confuse me). In any event, that sounds like a major project…

  1. Cannon CHDK is your best bet for achieving this, there are lots of supported cameras, most of which are several years old and can be picked up off eBay for only a few dollars. I recently go a Canon A460 For £15 ($23) on eBay and it looks brand new, the key reason I went for that model was because it supports SDHC cards and has an DC-power jack (a lot of camera only support DC power via a very expensive “dummy” battery type adapter). Nearly all of the cameras support a USB trigger, simply applying GND and 5V to the USB connector will cause the firmware to trigger the shutter.

    I actually have done this type of time-lapse but never got round to posting the results. It was based on the work by Marty McGuire (Schmarty) who actually works for MakerBot now (http://creatingwithcode.com/makerbot/automatic-makerbot-time-lapse-photography). I modified the Thing-o-Matic firmware to use one of the spare pins on the Interface connector, a new M-Code would apply 5v on this pin for a second or so which triggers the camera running CHDK. You also need to modify ReplicatorG as it translates the M-Code into the s3g command.

    I am hoping to do some more work on this soon as the results are pretty amazing when you play it back.

    1. it supports SDHC cards and has an DC-power jack

      That sounds compelling. I’ve hacked battery pack replacements, but an actual connector would be exceedingly pleasant.

      I expect the next RepG release will have camera triggering baked in, so I’ll punt until then: too many projects already.

      But I can see picking up a cheap camera before then… thanks for the tip!

Comments are closed.