With reference to this thread
<http://forum.openscad.org/Parametrichyperbolicwormgearscriptstp22724.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 nonfaulty 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 = (w2w1+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 F6render 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/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
I have no problem to render the intersection of the wormgear_seg.stl with a cube. The same with the wormgear pie I have generated. Besides, I generated the spur gear from the wormgear(), saved its STL, and rendered the intersection of that STL with a cube without any trouble.Are you sure your STL is faulty? By "empty triags" do you mean missing triangles? 20171226 23:23 GMT02:00 Parkinbot <[hidden email]>: With reference to this thread _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.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/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
Good to hear that. Well, read it :) I have tested it with the version 2017.8 . That is the first time I read that a STL file was accepted by CGAL and rejected by other program due to degenerated triangles. Great that you found a better way to do it. I will be waiting for the thingverse publishing. Great project. 20171228 20:35 GMT02:00 Parkinbot <[hidden email]>: Ronaldo _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
I think that happens often because when exporting to STL the vertices are converted to floats from infinite precision rationals. Ones that are very close get collapsed causing degenerate triangles. On 28 December 2017 at 23:28, Ronaldo Persiano <[hidden email]> wrote:
_______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.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/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
In reply to this post by nophead
On Thu, 28 Dec 2017 23:42:51 +0000
nop head <[hidden email]> wrote: > I think that happens often because when exporting to STL the vertices are > converted to floats from infinite precision rationals. Ones that are very > close get collapsed causing degenerate triangles. It's basically a bug in the STL exporter involved. An STL exporter isn't supposed to produce degenerate triangles. It should use a point dictionary so it notices when two points coincide and if so either eliminate the degenerate triangles or jiggle the values so the point (and sometimes several points) are moved by the smallest fractional value to make them distinct IEEE floating point values. OpenSCAD at least defaults away from using binary stl formats which are the worst for this. Alan _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
Administrator

In reply to this post by Parkinbot
> On Dec 29, 2017, at 8:09 AM, Parkinbot <[hidden email]> wrote: > > he 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. > That’s indeed a way to fixup a bad mesh, but not as trivial to implement once you dig deeper, see here for some discussion: https://github.com/openscad/openscad/issues/1580 There was also a bit of discussion on this topic on the mailing list a while back. Carsten implemented an algorithm that seems to work well. He used some proprietary components and couldn’t share his code, but he did outline his algorithm. Cannot find the post atm.. Marius _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
On 30. des. 2017 21:16, Marius Kintel wrote: > >> On Dec 29, 2017, at 8:09 AM, Parkinbot <[hidden email]> wrote: >> >> he 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. >> > That’s indeed a way to fixup a bad mesh, but not as trivial to > implement once you dig deeper, see here for some discussion: > https://github.com/openscad/openscad/issues/1580 > > There was also a bit of discussion on this topic on the mailing list > a while back. Carsten implemented an algorithm that seems to work > well. He used some proprietary components and couldn’t share his code, > but he did outline his algorithm. Cannot find the post atm.. > That post is at: http://forum.openscad.org/Whyisthisnotanerrortd19430.html#a19440 Carsten Arnholm _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
In reply to this post by kintel
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/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
Administrator

> On Jan 1, 2018, at 11:43 AM, Parkinbot <[hidden email]> wrote:
> > I wouldn't mix up mesh repair for input and mesh coarsing for output. > For output, where you start with a supposedly valid representation, [...] One of the initial challenges is to effectively obtain such a valid representation. When using CGAL, this comes as Nef3 polyhedrons with fractional (Gmpq) coordinates. Teasing out a reasonable mesh data format from this is already an annoying problem. Converting from Gmpq to something more manageable (like double precision floats) already introduces topology issues. If we try to run this algorithm _after_ converting to doubles, the problem is basically the same as incoming mesh repair. If we were to solve this in fractional space, we would have a few more freedoms, but even then, an edge collapse isn’t topologypreserving and we’d still need some good heuristics or neighborhood analysis to select valid edges for collapse, and then introduce another cleanup algorithm to deal with the leftover edges. ..or go the other way like Carsten did and base the algorithms on edge splits, and accept that incoming meshes may have been destroyed by an earlier coarsening step. Anyway, this is all stuff we’d love to get to  just significant work to implement and test. Marius _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
Yeah, it looks like the problem has at least on other dimension.
In my imagination a change of representation is like a snaptogrid operation and always a coarsening (surjective map). So, whenever two distinct points are mapped onto the same grid point, we have one of two situations: Either they are neighbored points with respect to exactly two polygons (that share the edge defined by the two points) or not. In the first case it should be safe to merge the points and shorten the polygons, respectively drop them, if they degenerate. The second case will create a topology problem and needs some intelligent treatment, like: find another (more distant) grid point in the neighborhood that can preserve topology. In practice it will be a bit more complicated, as many points can be mapped onto the same grid point and one has to pick out and treat all neighbored points first. Points that don't get treated by this are candidates for second case treatment.  Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
Ok, the worst case is, that distant points snap to distant grid points and
selfintersection occurs, as it will happen in the following 2Dimage when blue points are snapped to red grid points. <http://forum.openscad.org/file/t887/odd.png>  Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
I imagine those are very small polygons that maybe should be collapsed in any
realistic model anyway? What if the snapping primarily is done to a grid one order of precision coarser than mathematically possible? That would leave some room between to resolve vertices that are, close but not topologically related, to avoid snapping together.  Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
In reply to this post by Ronaldo
Ronaldo,
I'm still working on it and completely rearranged, simplified, and also optimized the code by reducing vertex counts as much as possible. However, meanwhile I am almost fed up with this approach, as I am more and more running into obscure CGAL problems, errors, warnings, invalid exports/imports. I feel like a gambler because the stability of solutions seem to heavily depend on harmless parametrizations (which of course have influence on the meshing). Additionally OpenSCAD's GUI tends to brick or at least get unstable as soon as F5rendering exceeds a certain complexity. To me it looks like this method is opening Pandora's box. For now I'm waiting for a version that fixes the missing "alternate construction" bug. At least I can show you a video of my print, which really came out well: https://youtu.be/NK8TeTKRFL4 Ronaldo wrote > Great that you found a better way to do it. I will be waiting for the > thingverse publishing. Great project.  Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
Nice video, Rudolf. It is a vivid proof of the concept. Do you remember our discussion on polygon triangulation some years ago? I was looking over the triangulation of planar polygons because I had troubles with degenerated triangles in almost planar nonconvex polygons. After implementing the triangulation myself I found that CGAL changed the triangulation I had built for another one, not always better. After that, I abandoned my triangulation process. I don't know if that has changed in later OpenSCAD versions. So, I understand your dismay. 20180106 11:05 GMT02:00 Parkinbot <[hidden email]>: Ronaldo, _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
Ronaldo,
you might be interested that I finally put the project online, despite I still haven't found time to try out some more advanced ideas to enhance render quality and time. https://www.thingiverse.com/thing:2776688 The code indeed expects OpenSCAD 2018.1.6 and will not do with 2015.3, which is a pity.  Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
Nice job. I will have a look in your code later. 20180131 15:52 GMT02:00 Parkinbot <[hidden email]>: Ronaldo, _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
In reply to this post by Parkinbot
> 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) This is using slightly more sophisticated math instead of OpenSCAD, but instead of 'virtually hobbing' the worm wheel, I think you can get away with just using the constraints at the extremes of where the worm screw and worm wheel mesh. I'm not sure this is clear enough to make easy sense, but it's not hard to plot the trajectories of contact points on the screw in the reference farm of the wheel: globoidprofiletest.scad <http://forum.openscad.org/file/t2140/globoidprofiletest.scad>  Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
Thanks, that is exactly how I finally diid it.
 Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org 
Free forum by Nabble  Edit this page 