With reference to  this thread
http://forum.openscad.org/Parametric-hyperbolic-worm-gear-scripts-tp22724.html
I am currently evaluating a simple and straight forward method to easily
construct properly fitted globoid worm gear / helical gear pairs on the
basis of a simple 2D gear given as polygon. To everyone who is interested,
the math I'm using is rather simple:

1. I calculate the position of the upper face of a properly twisted (and
   radially distanced) helical gear and do a 360° "Moebius type" sweep with one
   tooth twist.
2. I do the same with the lower face of the helical gear.
3. I difference both donuts from a ring and get a properly shaped worm gear
   (see 1st image)

While CGAL tried its best to make my life miserable, I was finally
successful in outputting a non-faulty STL. CGAL forced me to turn down
resolution significantly.  (40 slices per 360° sweep, distance beetween two
polygon points >0.2)

With this done, it was straight forward to difference the worm gear from a
pie to tailor a perfectly adapted tooth allowing spur gear construction.

z = 20;      // # teeth of wormgear
h = 10;    // height of wormgear
m=2;          // modulus
min_r = 10;  // pitch circle radius of worm
Rad = z+min_r;  // outer cycle radius

wormgear();

module wormgear()
{
w = 180/z;
//  forN(0, z)  // arrange z teeth
difference()
{
pie(25, h-.2, -w-.1, w+.1);
color("gold") translate([Rad, 0, 0]) import("worm1.stl");
}
}

module pie(r = 1, h=1, w1=0, w2=0)
rotate([0, 0, w1])  rotate_extrude(angle =  (w2-w1+360)%360)
translate([0,-h/2])  square([r,h]);

The operation looks like that (golden part marking the subtrahend):
http://forum.openscad.org/file/t887/wormgear.png

and shouldn't be too difficult. OpenSCAD (both 2015.3 and 2017.1) lets me
successfully F6-render it and export a STL. I can also construct an entire
spur gear by a union of 20 pies and export that as STL. Here the full 20:1
system after reimport.
http://forum.openscad.org/file/t887/wormgear1.png

The problem now is that OpenSCAD exports faulty STLs containing empty
triags. Here the single pie element
http://forum.openscad.org/file/t887/wormgear2.png

Any ideas?
To me it appears that OpenSCAD doesn't remove faces being mapped to 'empty'
triags in ASCII STL representation. Wouldn't that be easy to implement?

Here the files:
worm1.stl https://www.dropbox.com/s/igusndl4islaigc/worm1.stl?dl=0
faulty pie STL
https://www.dropbox.com/s/x729s57a3sdexfw/wormgear_seg.stl?dl=0

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

Ronaldo

thanks for checking. You are right, CGAL doesn't complain about this STL
(might have been either a stricken session, or the update to 2017.11 I
installed today resolved it). But see, what Kisslicer reports when loading
the spur gear:
http://forum.openscad.org/file/t887/wormgear3.png
every blue line refers to a "blade edge" triangle indicated in green color.
It is about a hundred instances.

Meanwhile I have ceased to use the involute gear primitive and switched to a
minimalistic geometry, as a worm gear system does not derive any benefit
from involute gears. As expected this speeded up rendering significantly and
squeezed the now faultless STLs by a factor of 6. My test print of a 15:1
system was successful and I will publish the code in Thingiverse, as soon I
find time to comment the code.

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

nophead,

this was my point. Such a collapse can be easily anticipated before
export. The treatment would be to merge a degenerated or blade edge triag
with one of the two neighbor triags have a long edge in common and get a
simpler, but valid STL.

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

Marius,

I wouldn't mix up mesh repair for input and mesh coarsing for output.
For output, where you start with a supposedly valid representation, it is as
easy as merging two vertices too close to be distiguishable by the used
output format into one and suppressing the two facets affected by this
operation.

As the code and STL excerpt below show, STL output is done on the basis of 6
valid decimal digits, while a single (23 bit mantissa) can express the range
-3,40282347 to 3,40282347 which is obviously almost 8.5 decimals. Therefore
any proper STL output must have a coarsening step in the proposed way. I
don't know how OpenSCAD actually deals with it internally, but if I had to
implement it, I would use a compare of the 6 digit decimal representation or
at least a minimal distance criterion that sufficiently covers this loss of
precision.

cube(sqrt(2)); translate([100, 0, 0]) cube(sqrt(2));

...
facet normal 0 -1 -0
outer loop
vertex 1.41421 0 1.41421
vertex 0 0 0
vertex 1.41421 0 0
endloop
endfacet
facet normal -1 0 0
outer loop
vertex 100 0 0
vertex 100 1.41421 1.41421
vertex 100 1.41421 0
endloop
endfacet
...

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