Solid Modeling: Support Puzzle

I’ve been putting this type of support structure inside screw holes & suchlike for years:

Browning Hi-Power Magazine Block - solid model - Generic 1 - support detail
Browning Hi-Power Magazine Block – solid model – Generic 1 – support detail

It’s basically a group of small rectangles rotated around the hole’s axis and about one thread thickness shorter than the overhanging interior.

I’ve found that incorporating exactly the right support structure eliminates Slic3r’s weird growths, eases removal, and generally works better all around.

So doing this for the baseplate of the Glass Tile frame came naturally:

Glass Tile Frame - octagonal support
Glass Tile Frame – octagonal support

This OpenSCAD snippet plunks one of those asterisks in each of four screw holes:

  if (Support)
      for (i=[-1,1], j=[-1,1])
          for (a=[0:45:135])
                translate([0,0,(Screw[LENGTH] - ThreadThick)/2])
                  cube([Screw[OD] - 2*ThreadWidth,2*ThreadWidth,Screw[LENGTH] - ThreadThick],center=true);

The “cubes” overlap in the middle, with no completely coincident faces or common edges, so it’s 2-manifold. Slic3r, however, produces a weird time estimate whenever the model includes those structures:

Slic3r - NaN time estimate
Slic3r – NaN time estimate

NaN stands for Not A Number and means something horrible has happened in the G-Code generation. Fortunately, the G-Code worked perfectly and produced the desired result, but I’m always uneasy when Something Seems Wrong.

Messing around with the code produced a slightly different support structure:

Glass Tile Frame - quad support
Glass Tile Frame – quad support

The one thread thick square on the bottom helps glue the structure to the platform and four ribs work just as well as eight in the octagonal hole:

  Fin = [Screw[OD]/2 - 1.5*ThreadWidth,2*ThreadWidth,ScrewRecess - ThreadThick];
  if (Inserts && SupportInserts)
      for (i=[-1,1], j=[-1,1])
        translate([i*InsertOC.x/2,j*InsertOC.y/2,0]) {
          for (a=[0:90:360])
                translate([Fin.x/2 + ThreadWidth/2,0,(ScrewRecess - ThreadThick)/2])

Which changed the NaN time estimates into actual numbers.

One key difference may be the small hole in the middle. The four ribs (not two!) now overlap by one thread width around the hole, so they’re not quite coincident and Slic3r produces a tidy model:

Glass Tile Frame - quad support - Slic3r
Glass Tile Frame – quad support – Slic3r

The hole eliminates a smear of infill from the center, which may have something to do with the improvement.

In any event, I have an improved copypasta recipe for the next screw holes in need of support, even if I don’t understand why it’s better.

2 thoughts on “Solid Modeling: Support Puzzle

  1. Glancing at the code, it looks to me as though the top and bottom faces are coincident across all the “cubes.” That’s been enough to generate non-manifold geometry for me, if I’m not misreading this.

    I’ve resorted to either making all of them taller and sitting lower than I want and intersecting the set of them with a bounding box to trim them to the coincident faces I want after the implicit union, or translating each one “fudge” (or epsilon) higher on the Z axis than the previous, with fudge typically = 0.001.

    1. The dead-simple asterisk geometry “used to work”, even with all its same-plane faces, so something’s new & different. I think the recent OpenSCAD commit enabling lazy unions (which option, of course, I immediately turned on) makes the for loop return a bunch of non-unioned slabs that gum up my simple assumptions.

      The Right Way now is probably to build the asterisk from 2D squares, linear_extrude the resulting shape to the proper height, then add the footer disk. I’ll try (to remember) that the next time it doesn’t work …

Comments are closed.