I did start writing up a polyhedron checker:

http://forum.openscad.org/Mesh-Polyhedron-Test-Script-td23106.html

I'm not sure how quickly or easily you could run something like that on that
on the polyhedron you're generating, or if it would find the issue that
you're running into, but it should find holes and topologically incorrectly
oriented faces.

It won't detect if you're generating a self-intersecting extrusion profile.

I've run into issues because OpenSCAD doesn't do exact geometry or because
of floating point problems.  So you can get into trouble if you have very
short line segments or wall thickness.

--
Sent from: http://forum.openscad.org/

Disregard the above. I think I introduced a side effect when formatting the
code.

Admin - email* me if you need anything, or if I've done something stupid...

• click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.

The TPP is no simple “trade agreement.”  Fight it! http://www.ourfairdeal.org/  time is running out!

Sent from: http://forum.openscad.org/

OK re-regard the above, I got confounded by a F6 before F5 artifact...

So plotting the points

module plotvv3(vv,size=2)
for(j=vv) plotv3(j,size,"red");

module plotv3(v,size=4,c="blue") { // v=[ [x,y,z], ... ]
for(i=v)
translate([i.x,i.y,i.z])
color(c)
sphere(size,$fn=12);
}

//this makes the shape I want a transtion between
//roman and ogee arches on a pathway that is half
//an ogee arch
//I'd use 6 of these to make the hallways I want
//16 verticies simplifies things

module arches2(verticies=192, thickness = 8, solid = false) {
yxzpath = ogeepolyPath(650, 3, 600, 600, 420, 1, 10);

//echo(yxzpath);
//echo("blah");
//echo(yxzpath[10]);
translate([0,0,750]) cube();
skinv=[
       for (i=[103 : 1 :  105])
          transform(translation(yxzpath[i]) * rotation([0,0,0]), 
                    wave(i,verticies,thickness,solid))
      ];  
echo(len(skinv),skinv=skinv);
plotvv3(skinv,size=0.3);
skin(skinv);

}

Shows:
http://forum.openscad.org/file/t359/arches2_plot_orig.jpg

Looking at the 103-105 points, which are black, red, blue respectively
http://forum.openscad.org/file/t359/Capture_arches2_skinv_plot_103-105.jpg

The 104 & 105 are likely the cause.

Doing,

plotv3(yxzpath);

Shows:
http://forum.openscad.org/file/t359/Capture_arches2_yxzpath.jpg

Looking into ogeepolyPath(),

// Lower Right Outer arc
lro = [ for (i = [0:1:lowerpoints-1]) 

Remove the '-1' fixes that gap.

Then:
http://forum.openscad.org/file/t359/arches2_plot_fixed.jpg

No more CGAL error with a cube().

STL fixed:  arches2_fixed_w_cube.stl
http://forum.openscad.org/file/t359/arches2_fixed_w_cube.stl
No self-intersections.

But Thrown-together still shows purple...
http://forum.openscad.org/file/t359/arches2_fixed_purple.jpg

I suspect that may be a skin() thing...looking...

Admin - email* me if you need anything, or if I've done something stupid...

• click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.

The TPP is no simple “trade agreement.”  Fight it! http://www.ourfairdeal.org/  time is running out!

Sent from: http://forum.openscad.org/

Thanks for all your hard work.  I am confused on some things though:

1. " But Thrown-together still shows purple...
   http://forum.openscad.org/file/t359/arches2_fixed_purple.jpg "
   So that is the kind of thing I have been seeing but the image shows the
   facets in shades of yellow, and only the edges are purple/magenta/pink.  I
   have been operating under the assumption that whole faces/facets should be
   purple/magenta/pink to show a problem.  Another person suggested those
   "edges" were really very narrow facets or gaps.  But it seems hard for me
   to believe that every single face / facet in my object also is bordered on
   all sides by either facets with a very tiny width or holes with a tiny
   width.  Or does this mean I have been looking for the wrong thing in
   "thrown together" and edges with purple/magenta/pink mean there is a
   problem (that is still somewhat confusing because it suggests that somehow
   everything is in error; I'd think it would be almost impossible to generate
   something that was all bad or nearly all bad)?  So I think I don't know how
   to interpret "thrown together" properly

2. the overhang thing you found I believe is the problem, but I don't
   really get how it happens.  Lately I've been doing arches2(16) specifying
   only 16 points per arch.  The advantage of doing that is (given the other
   defaults) the points should be widely enough spaced apart that floating
   point vagaries don't cause two points to end up (with rounding errors) at
   the same coordinate.  Also I set some debug messages in the code to spit
   out how many points each arch had.  All the messages said "16", so with
   equal number of point I don't see how an overhang should happen.  You
   mentioned there might be some problem with skin() (I didn't realize skin()
   had known bugs) which could explain things; otherwise I don't understand
   how when knitting together polygons (with roughly similar shapes, non
   degenerate points, the same order of points, and the same number of
   vertices) gives an overhang

That being said it did occur to me that ogeepolyPath (which is generating
the coordinate path to center the arches on) is generating 402 points,
whereas my wave() routine is generating 105 arch polygons.  I could see
that it might cause a problem (if skin() has to interpolate or do something
like that to make them match).  I did go back to force ogeepolyPath to
generate 105 points so it would match the number of archways being
generated.  Unfortunately I still get the "ERROR: CGAL error in
CGAL_Nef_polyhedron3(): CGAL ERROR: assertion violation! Expr: e_below !=
SHalfedge_handle() File:
/opt/mxe/usr/x86_64-w64-mingw32.static.posix/include/CGAL/Nef_3/SNC_FM_decorator.h
Line: 426 " error when I try to build the hallway, subtract a solid
mirrored version, then add the mirror version

well, to be honest, your coding is a bit callenging. But having played a bit
with your code, I can say that

 translate([0,0,750]) cube();
 skinv=[
       for (i=[0 : 1 :  104])
          reverse(transform(translation(yxzpath[i]) * rotation([0,0,0]),
                    wave(i,verticies,thickness,solid)))
      ];  
skin(skinv);

works well with F6. Note that I had to include a reverse() to correct the
point order. Further I count the 105 polygons from 0 to 104. Your problem
might be that a loop from 104 to 105 will return two identical polygons,
which will trigger the CGAL error, when skinned.

 skinv=[
       for (i=[104 : 1 :  105])  // identical polygons

--
Sent from: http://forum.openscad.org/