<p>If the polyhedron surface and top surface of the cube are exactly coplanar, which they seem to be, it won't work; OpenSCAD operates numerically rather than analytically and which is &quot;inside&quot; or &quot;outside&quot; the other is subject to numerical instability. Whenever using differences you need to make the object being subtracted extend by at least some small epsilon outside the surfact of the object you're subtracting from.</p>

CC BY-SA 4.0
2020-11-28T12:17:17.853Z
I did extend the bottom of the poly down through the bottom of the cube and got the same results. I'll try that again, though.
Josh M.
CC BY-SA 4.0
2020-11-28T04:10:56.853Z
2020-11-28T04:10:56.853Z
R.. GitHub STOP HELPING ICE
<p>Usually when there's an overlap in two objects during a difference action, F6 render will resolve the problem. There's something more than that involved here, as reducing the height of the cube creates a non-manifold object from the difference. user R..'s answer has merit but is not going to solve the problem.</p>
<p>Isolating the cube from the code and exporting the result as an STL allows me to determine that the faces are generated in a manner preventing a proper difference action:</p>
<p><a href="https://i.sstatic.net/QEtXM.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/QEtXM.png" alt="meshmixer image" /></a></p>
<p>This image from meshmixer shows the faces have inverted normals. The order of the points are critical when describing a polyhedron. From the wiki page for <a href="https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/The_OpenSCAD_Language#polyhedron" rel="nofollow noreferrer">OpenSCAD</a>:</p>
<blockquote>
<p>It is arbitrary which point you start with, but all faces must have
points ordered in the same direction . OpenSCAD prefers clockwise when
looking at each face from outside inward. The back is viewed from the
back, the bottom from the bottom, etc. Another way to remember this
ordering requirement is to use the right-hand rule. Using your
right-hand, stick your thumb up and curl your fingers as if giving the
thumbs-up sign, point your thumb into the face, and order the points
in the direction your fingers curl.</p>
</blockquote>
<p>EDIT: I reversed some of the points, haphazardly and luckily picked the correct ones:</p>
<pre><code>        faces = [
            [0, 1, 2], [2, 3, 0],     // bottom
            
            [4, 1, 0], [1, 4, 5],     // side A
            [5, 2, 1], [2, 5, 6],     // side B
            [6, 3, 2], [3, 6, 7],     // side C
            [7, 0, 3], [0, 7, 4],     // side D
            
            [8, 5, 4], [5,   8,  9], // slope A
            [9, 6, 5], [6,   9, 10], // slope B
            [10, 7, 6], [7,  10, 11], // slope C
            [11, 4, 7], [4,  11,  8], // slope D
            
            [10, 9, 8], [8, 11, 10]  // top
</code></pre>
<p><a href="https://i.sstatic.net/GWBMo.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/GWBMo.png" alt="rendered code" /></a></p>

CC BY-SA 4.0
2020-11-28T14:33:43.327Z
Yes, OpenSCAD requires consistent normals, and from my experience actually requires (not just prefers) them pointing inwards if you want CSG functionality to all work right.
R.. GitHub STOP HELPING ICE
CC BY-SA 4.0
2020-11-28T15:59:55.777Z
I wasn't sure about the "requires versus prefers... pointing inwards" reference, but it's "prefers clockwise" according to the wiki.
fred_dot_u
CC BY-SA 4.0
2020-11-28T16:16:31.163Z
Thanks. I had just reordered the points so they were clockwise but had a similar but different issue. I guess I don't understand why (for Side A) `[4, 1, 0]` works but `[0, 4, 1]` does not (as applied to all other faces) -- they are both clockwise looking at the face, but starting from the "top" is perhaps the difference?
Josh M.
CC BY-SA 4.0
2020-11-28T12:13:23.680Z
2020-11-28T12:42:04.410Z
2020-11-28T12:42:04.410Z
fred_dot_u
<p>I'm trying to subtract a polyhedron from a cube, but it is not working (the cube remains solid). However, I can see the cut-out poly in preview mode (but not after a full render).</p>
<p><strong>Preview</strong> -- poly cutout shows on the top (and bottom).</p>
<p><a href="https://i.sstatic.net/Zk1Z5.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/Zk1Z5.png" alt="preview" /></a></p>
<p><strong>Rendered</strong> -- poly cutout not visible.</p>
<p><a href="https://i.sstatic.net/cofDh.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/cofDh.png" alt="rendered" /></a></p>
<p><strong>Poly Exploded</strong> -- pulled the poly to the right to show its shape.</p>
<p><a href="https://i.sstatic.net/VILrM.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/VILrM.png" alt="poly exploded" /></a></p>
<p><strong>Code</strong></p>
<pre><code>size = 30;
wall = 3;
wall_x2 = wall * 2;
nubGap = .125;
nubHeight = 8;
nubOffset = wall + nubGap;
xCutoutSize = size - wall_x2;
yCutoutSize = size - wall_x2;
cutoutLowerY = nubHeight + nubGap;
cutoutUpperOffset = nubOffset + wall;
    
difference() {
    cube([size, size, size]);
    
    translate([wall, wall, 0]) {
        polyhedron(
            points = [
                [0, 0, -10],
                [xCutoutSize, 0, -10],
                [xCutoutSize, yCutoutSize, -10],
                [0, yCutoutSize, -10],
        
                [0, 0, cutoutLowerY],
                [xCutoutSize, 0, cutoutLowerY],
                [xCutoutSize, yCutoutSize, cutoutLowerY],
                [0, yCutoutSize, cutoutLowerY],
        
                [cutoutUpperOffset, cutoutUpperOffset, size],
                [xCutoutSize - cutoutUpperOffset, cutoutUpperOffset, size],
                [xCutoutSize - cutoutUpperOffset, yCutoutSize - cutoutUpperOffset, size],
                [cutoutUpperOffset, yCutoutSize - cutoutUpperOffset, size]
            ],
            faces = [
                [0, 1, 2], [2, 3, 0],     // bottom
                
                [0, 1, 4], [1, 4, 5],     // side A
                [1, 2, 5], [2, 5, 6],     // side B
                [2, 3, 6], [3, 6, 7],     // side C
                [3, 0, 7], [0, 7, 4],     // side D
                
                [4, 5,  8], [5,   8,  9], // slope A
                [5, 6,  9], [6,   9, 10], // slope B
                [6, 7, 10], [7,  10, 11], // slope C
                [7, 4, 11], [4,  11,  8], // slope D
                
                [8, 9, 10], [10, 11,  8]  // top
            ]
        );
    };
};
</code></pre>

<3d-design><openscad>
OpenSCAD not rendering polyhedron
Josh M.
# OpenSCAD not rendering polyhedron

(Asked by: username_0 on 2020-11-28)

I'm trying to subtract a polyhedron from a cube, but it is not working (the cube remains solid). However, I can see the cut-out poly in preview mode (but not after a full render).

**Preview** -- poly cutout shows on the top (and bottom).

[![preview](https://i.sstatic.net/Zk1Z5.png)](https://i.sstatic.net/Zk1Z5.png)

**Rendered** -- poly cutout not visible.

[![rendered](https://i.sstatic.net/cofDh.png)](https://i.sstatic.net/cofDh.png)

**Poly Exploded** -- pulled the poly to the right to show its shape.

[![poly exploded](https://i.sstatic.net/VILrM.png)](https://i.sstatic.net/VILrM.png)

**Code**

```
size = 30;
wall = 3;
wall_x2 = wall * 2;
nubGap = .125;
nubHeight = 8;
nubOffset = wall + nubGap;
xCutoutSize = size - wall_x2;
yCutoutSize = size - wall_x2;
cutoutLowerY = nubHeight + nubGap;
cutoutUpperOffset = nubOffset + wall;
    
difference() {
    cube([size, size, size]);
    
    translate([wall, wall, 0]) {
        polyhedron(
            points = [
                [0, 0, -10],
                [xCutoutSize, 0, -10],
                [xCutoutSize, yCutoutSize, -10],
                [0, yCutoutSize, -10],
        
                [0, 0, cutoutLowerY],
                [xCutoutSize, 0, cutoutLowerY],
                [xCutoutSize, yCutoutSize, cutoutLowerY],
                [0, yCutoutSize, cutoutLowerY],
        
                [cutoutUpperOffset, cutoutUpperOffset, size],
                [xCutoutSize - cutoutUpperOffset, cutoutUpperOffset, size],
                [xCutoutSize - cutoutUpperOffset, yCutoutSize - cutoutUpperOffset, size],
                [cutoutUpperOffset, yCutoutSize - cutoutUpperOffset, size]
            ],
            faces = [
                [0, 1, 2], [2, 3, 0],     // bottom
                
                [0, 1, 4], [1, 4, 5],     // side A
                [1, 2, 5], [2, 5, 6],     // side B
                [2, 3, 6], [3, 6, 7],     // side C
                [3, 0, 7], [0, 7, 4],     // side D
                
                [4, 5,  8], [5,   8,  9], // slope A
                [5, 6,  9], [6,   9, 10], // slope B
                [6, 7, 10], [7,  10, 11], // slope C
                [7, 4, 11], [4,  11,  8], // slope D
                
                [8, 9, 10], [10, 11,  8]  // top
            ]
        );
    };
};

```

**Tags:** 3d-design, openscad


---

## 2 answers

### Answer by username_2 on 2020-11-28. Score: 4 | Accepted answer

Usually when there's an overlap in two objects during a difference action, F6 render will resolve the problem. There's something more than that involved here, as reducing the height of the cube creates a non-manifold object from the difference. user R..'s answer has merit but is not going to solve the problem.

Isolating the cube from the code and exporting the result as an STL allows me to determine that the faces are generated in a manner preventing a proper difference action:

[![meshmixer image](https://i.sstatic.net/QEtXM.png)](https://i.sstatic.net/QEtXM.png)

This image from meshmixer shows the faces have inverted normals. The order of the points are critical when describing a polyhedron. From the wiki page for [OpenSCAD](https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/The_OpenSCAD_Language#polyhedron):

> It is arbitrary which point you start with, but all faces must have
> points ordered in the same direction . OpenSCAD prefers clockwise when
> looking at each face from outside inward. The back is viewed from the
> back, the bottom from the bottom, etc. Another way to remember this
> ordering requirement is to use the right-hand rule. Using your
> right-hand, stick your thumb up and curl your fingers as if giving the
> thumbs-up sign, point your thumb into the face, and order the points
> in the direction your fingers curl.

EDIT: I reversed some of the points, haphazardly and luckily picked the correct ones:

```
        faces = [
            [0, 1, 2], [2, 3, 0],     // bottom
            
            [4, 1, 0], [1, 4, 5],     // side A
            [5, 2, 1], [2, 5, 6],     // side B
            [6, 3, 2], [3, 6, 7],     // side C
            [7, 0, 3], [0, 7, 4],     // side D
            
            [8, 5, 4], [5,   8,  9], // slope A
            [9, 6, 5], [6,   9, 10], // slope B
            [10, 7, 6], [7,  10, 11], // slope C
            [11, 4, 7], [4,  11,  8], // slope D
            
            [10, 9, 8], [8, 11, 10]  // top

```

[![rendered code](https://i.sstatic.net/GWBMo.png)](https://i.sstatic.net/GWBMo.png)

> **Comments:**
> **username_1**: Yes, OpenSCAD requires consistent normals, and from my experience actually requires (not just prefers) them pointing inwards if you want CSG functionality to all work right.  
> **username_2**: I wasn't sure about the "requires versus prefers... pointing inwards" reference, but it's "prefers clockwise" according to the wiki.  
> **username_0**: Thanks. I had just reordered the points so they were clockwise but had a similar but different issue. I guess I don't understand why (for Side A) `[4, 1, 0]` works but `[0, 4, 1]` does not (as applied to all other faces) -- they are both clockwise looking at the face, but starting from the "top" is perhaps the difference?  

---

### Answer by username_1 on 2020-11-28. Score: 2

If the polyhedron surface and top surface of the cube are exactly coplanar, which they seem to be, it won't work; OpenSCAD operates numerically rather than analytically and which is "inside" or "outside" the other is subject to numerical instability. Whenever using differences you need to make the object being subtracted extend by at least some small epsilon outside the surfact of the object you're subtracting from.

> **Comments:**
> **username_0**: I did extend the bottom of the poly down through the bottom of the cube and got the same results. I'll try that again, though.  

---

