<p>It is interesting that the WTH line and the next line both should remove a cylinder of the same diameter from the same location.  Only the height is different.</p>

<p>It could be interesting to remove the first King/Queen line and see if there is a change.</p>

<p>Have you checked the STL file with another tool, other than OpenSCAD?  There may be a kink in the STL that confuses the geometry engine in OpenSCAD.  The first difference could be catching the kink, and the second one carving out the magnet body in the bottom.</p>

CC BY-SA 4.0
2019-08-19T16:33:54.923Z
Also maybe try intersection instead of difference to see what happens.
R.. GitHub STOP HELPING ICE
CC BY-SA 4.0
2019-08-19T20:20:54.340Z
Excellent explanation, thanks. The "WTH" cylinder is centered on the queen piece, and that has a sphere with _lots_ of faces on top. So it looks like the "kink" is inside the queen where the sphere and the base cube overlap, and by accident, my trial-and-error removing of cylinders also removed just the right spot.
Florian Echtler
CC BY-SA 4.0
2019-08-19T15:36:13.297Z
2019-08-19T15:36:13.297Z
cmm
<p>I see you've accepted cmm's answer, but I'd still like to take a stab at the mechanism of the failure based on your comment on it:</p>

<blockquote>
  <p>Excellent explanation, thanks. The "WTH" cylinder is centered on the queen piece, and that has a sphere with lots of faces on top. So it looks like the "kink" is inside the queen where the sphere and the base cube overlap, and by accident, my trial-and-error removing of cylinders also removed just the right spot.</p>
</blockquote>

<p>My guess is that if you look at the triangle set of the STL file, you'll find the interior of the queen contains the parts of the cube that are inside the sphere and the parts of the sphere that are inside the cube; they may not even be clipped to meet each other properly where they cross each other's surfaces. Sadly there are lots of tools producing invalid STL files like this. The longer cylinder is probaly sufficient to overlap with where the cube and sphere cross, forcing OpenSCAD to break down the model in that region and recompute the mesh where the components overlap. Without that recomputation, the differences likely end up interacting with just the "sphere part" of the STL mesh.</p>

<p>This explanation also seems to be consistent with the description of the thing on thingiverse:</p>

<blockquote>
  <p>I much preferred the style of Bauhaus set that TeamTeaUSA's designed, but there was a lot of fiddling with the queen and the knight wouldn't print without supports. So I nestled the queen's sphere further into the body so it would print standing up, added supports for the knight and plated the whole thing.</p>
</blockquote>

<p>where it looks like the creator took someone else's STL files and moved parts around to create an overlap, likely without proper tooling that could regenerate a valid mesh.</p>

CC BY-SA 4.0
2019-08-20T02:36:35.717Z
2019-08-20T02:36:35.717Z
R.. GitHub STOP HELPING ICE
<p>I've tried to remix this model: <a href="https://www.thingiverse.com/thing:90933" rel="nofollow noreferrer">https://www.thingiverse.com/thing:90933</a> (Bauhaus chess set) by scaling it down and inserting little magnet holes into the pieces' underside. My SCAD file looks as follows:</p>

<pre><code>difference() { 

    scale([0.5,0.5,0.5]) import("Bauhaus2Set.stl");

    translate([ 6, 11  ,0]) cylinder(h=20.5,r=2.5,center=true,$fn=20); // WTH?

    // King/Queen
    translate([ 6, 11  ,0]) cylinder(h=3.5,r=2.5,center=true,<span class="math-container">$fn=20);
    translate([-6, 11  ,0]) cylinder(h=3.5,r=2.5,center=true,$</span>fn=20);

    // Rooks
    translate([ 6,-11.5,0]) cylinder(h=3.5,r=2.5,center=true,<span class="math-container">$fn=20);
    translate([-6,-11.5,0]) cylinder(h=3.5,r=2.5,center=true,$</span>fn=20);

[...]
</code></pre>

<p>Note the third line with "WTH?" - I've done quite some trial-and-error, and if I remove that line, then I don't get any subtracted holes anymore when I render the whole thing (F6). In preview (F5), the holes are always present, but in the final render, I need to include the larger subtracted cylinder or it won't work.</p>

<p>The STL file seems to be fine in itself, what's going on here?</p>

CC BY-SA 4.0
2019-08-19T12:39:32.137Z
What are the z extents of the original model?
R.. GitHub STOP HELPING ICE
CC BY-SA 4.0
2019-08-19T16:33:29.510Z
OK, I confirmed that the original model doesn't extend below z=0, so I think this is either a bug in openscad or (probably more likely) an error in the mesh.
R.. GitHub STOP HELPING ICE
<stl><openscad>
OpenSCAD weirdness with imported STL
Florian Echtler
# OpenSCAD weirdness with imported STL

(Asked by: username_0 on 2019-08-19)

I've tried to remix this model: https://www.thingiverse.com/thing:90933 (Bauhaus chess set) by scaling it down and inserting little magnet holes into the pieces' underside. My SCAD file looks as follows:
difference() { 

    scale([0.5,0.5,0.5]) import("Bauhaus2Set.stl");

    translate([ 6, 11  ,0]) cylinder(h=20.5,r=2.5,center=true,$fn=20); // WTH?

    // King/Queen
    translate([ 6, 11  ,0]) cylinder(h=3.5,r=2.5,center=true,$fn=20);
    translate([-6, 11  ,0]) cylinder(h=3.5,r=2.5,center=true,$fn=20);

    // Rooks
    translate([ 6,-11.5,0]) cylinder(h=3.5,r=2.5,center=true,$fn=20);
    translate([-6,-11.5,0]) cylinder(h=3.5,r=2.5,center=true,$fn=20);

[...]

Note the third line with "WTH?" - I've done quite some trial-and-error, and if I remove that line, then I don't get any subtracted holes anymore when I render the whole thing (F6). In preview (F5), the holes are always present, but in the final render, I need to include the larger subtracted cylinder or it won't work.
The STL file seems to be fine in itself, what's going on here?

**Tags:** stl, openscad
> **Comments:**
> **username_1**: What are the z extents of the original model?  
> **username_1**: OK, I confirmed that the original model doesn't extend below z=0, so I think this is either a bug in openscad or (probably more likely) an error in the mesh.  

---

## 2 answers

### Answer by username_2 on 2019-08-19. Score: 1 | Accepted answer

It is interesting that the WTH line and the next line both should remove a cylinder of the same diameter from the same location. Only the height is different.

It could be interesting to remove the first King/Queen line and see if there is a change.

Have you checked the STL file with another tool, other than OpenSCAD? There may be a kink in the STL that confuses the geometry engine in OpenSCAD. The first difference could be catching the kink, and the second one carving out the magnet body in the bottom.

> **Comments:**
> **username_1**: Also maybe try intersection instead of difference to see what happens.  
> **username_0**: Excellent explanation, thanks. The "WTH" cylinder is centered on the queen piece, and that has a sphere with _lots_ of faces on top. So it looks like the "kink" is inside the queen where the sphere and the base cube overlap, and by accident, my trial-and-error removing of cylinders also removed just the right spot.  

---

### Answer by username_1 on 2019-08-20. Score: 4

I see you've accepted cmm's answer, but I'd still like to take a stab at the mechanism of the failure based on your comment on it:

> Excellent explanation, thanks. The "WTH" cylinder is centered on the queen piece, and that has a sphere with lots of faces on top. So it looks like the "kink" is inside the queen where the sphere and the base cube overlap, and by accident, my trial-and-error removing of cylinders also removed just the right spot.

My guess is that if you look at the triangle set of the STL file, you'll find the interior of the queen contains the parts of the cube that are inside the sphere and the parts of the sphere that are inside the cube; they may not even be clipped to meet each other properly where they cross each other's surfaces. Sadly there are lots of tools producing invalid STL files like this. The longer cylinder is probaly sufficient to overlap with where the cube and sphere cross, forcing OpenSCAD to break down the model in that region and recompute the mesh where the components overlap. Without that recomputation, the differences likely end up interacting with just the "sphere part" of the STL mesh.

This explanation also seems to be consistent with the description of the thing on thingiverse:

> I much preferred the style of Bauhaus set that TeamTeaUSA's designed, but there was a lot of fiddling with the queen and the knight wouldn't print without supports. So I nestled the queen's sphere further into the body so it would print standing up, added supports for the knight and plated the whole thing.

where it looks like the creator took someone else's STL files and moved parts around to create an overlap, likely without proper tooling that could regenerate a valid mesh.


---

