On 9/26/20 9:00 AM, discuss-request@lists.openscad.org wrote:
From:
arnholm@arnholm.org
Another thing I tried was using OpenSCAD to convert your .scad file to .csg and then read that into my experimental .csg
interpreter. It reports that at least one of your polygons has wrong winding order:
...Warning: 1st polygon2d contour staring at (0.000000,-1.000000) has wrong winding order
I'm not sure what the polygon point winding order policy is in OpenSCAD (whether it automatically reverses wrong-winded
polygons or not), but wrong winding order can get one into trouble. The documentation at
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Using_the_2D_Subsystem#polygon
does not explain proper winding order clearly, but the examples show CCW winding order for the outer contour.
I double checked the one polyhedron() I used in the design and verified the order of the points is correct.
The documentation for the polygon() says nothing about the order of the points, and the documentation for the linear_extrude()
claims it uses the shadow of the polygon, so it would not matter the order of the points in the polygon().
I found one unnecessary vertex in one of my polygons (three points that were always in a line on line 64), but I'm still not
seeing anything in the source that could be causing all of those errors.
The only thing I'm seeing is that I made the blocks 0.01mm larger than their spacing so that they would overlap by 0.01mm, but
the cutout to save plastic will only overlap by 0.005mm, and I have had trouble with overlaps that were less than 0.01mm.
The attached file fixes this overlap so that it is 0.01mm. Let me know if this makes any difference.
Thanks.
On 27.09.2020 01:33, Douglas Peale wrote:
I double checked the one polyhedron() I used in the design and verified
the order of the points is correct.
That is probably correct then, that warning seems to be a false alarm in
my experimental code. I need to look into it.
The documentation for the polygon() says nothing about the order of the
points, and the documentation for the linear_extrude() claims it uses
the shadow of the polygon, so it would not matter the order of the
points in the polygon().
In general, winding order should matter. But maybe not here.
I think "the shadow" refers to the fact that you can apply a 3d
transformation to a 2d object (e.g. polygon) and linear extrude the
result, which necessarily must take the projection (="shadow") of the
transformed 2d object as starting point for the extrusion. However, this
can cause reversed winding order for the input "shadow", so I am
guessing that OpenSCAD checks for that issue and compensates automatically.
I did a quick test:
p1 = [0,0];
p2 = [100,0];
p3 = [100,50];
p4 = [0,50];
linear_extrude(height=10)
polygon([p1,p2,p3,p4]);
translate([0,100])
linear_extrude(height=10)
polygon([p1,p4,p3,p2]);
translate([0,200])
linear_extrude(height=10)
rotate([0,180,0])
polygon([p1,p2,p3,p4]);
translate([0,300])
linear_extrude(height=10)
rotate([0,135,0])
polygon([p1,p2,p3,p4]);
translate([0,400])
linear_extrude(height=10)
mirror([1,0,0])
polygon([p1,p2,p3,p4]);
... and they all seem to give valid results in "Thrown Together" so it
seems to confirm my guess. Only the first case is CCW winding order.
I found one unnecessary vertex in one of my polygons (three points that
were always in a line on line 64), but I'm still not seeing anything in
the source that could be causing all of those errors.
I did re-run your updated code in OpenSCAD 2019.05 (under Kubuntu
18.04), exported to STL and checked it with polyfix. I got the same
warnings as earlier (polyfix fixed them all). I would recommend checking
STL files posted to Thingiverse with one of the mesh repair applications
avalilable to maximise the chance it will be accepted by most slicers.
The attached file fixes this overlap so that it is 0.01mm. Let me know
if this makes any difference.
It seems to run fine in OpenSCAD, the only issue is the exported STL
still has a number of collapsed faces as noted before. The cause for
that could be in your design somewhere, but I don't know for sure.
Btw, your example discovered a bug in my experimental .csg interpreter,
so that was interesting. You used the # sign with difference, and I had
not taken that properly into account. After fixing that your model went
through my interpreter and the model was computed in 0.6 sec. In this
case there was "only" 6 collapsed faces in the end, also fixable with
polyfix.
Carsten Arnholm