# STL problem - globoid worm gear system

20 messages
Open this post in threaded view
|

## STL problem - globoid worm gear system

Open this post in threaded view
|

## Re: STL problem - globoid worm gear system

Open this post in threaded view
|

## Re: STL problem - globoid worm gear system

Open this post in threaded view
|

## Re: STL problem - globoid worm gear system

Open this post in threaded view
|

## Re: STL problem - globoid worm gear system

Open this post in threaded view
|

## Re: STL problem - globoid worm gear system

 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
Open this post in threaded view
|

## Re: STL problem - globoid worm gear system

 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 co-incide 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
Open this post in threaded view
|

## Re: STL problem - globoid worm gear system

 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/1580There 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
Open this post in threaded view
|

## Re: STL problem - globoid worm gear system

 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/Why-is-this-not-an-error-td19430.html#a19440Carsten Arnholm _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Open this post in threaded view
|

## Re: STL problem - globoid worm gear system

 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
Open this post in threaded view
|

## Re: STL problem - globoid worm gear system

 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 topology-preserving 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
Open this post in threaded view
|

## Re: STL problem - globoid worm gear system

 Yeah, it looks like the problem has at least on other dimension. In my imagination a change of representation is like a snap-to-grid 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
Open this post in threaded view
|

## Re: STL problem - globoid worm gear system

 Ok, the worst case is, that distant points snap to distant grid points and self-intersection occurs, as it will happen in the following 2D-image  when blue points are snapped to red grid points. -- Sent from: http://forum.openscad.org/_______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Open this post in threaded view
|

## Re: STL problem - globoid worm gear system

 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
Open this post in threaded view
|

## Re: STL problem - globoid worm gear system

 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 F5-rendering 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/NK8TeTKRFL4Ronaldo 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
Open this post in threaded view
|

## Re: STL problem - globoid worm gear system

Open this post in threaded view
|

## Re: STL problem - globoid worm gear system

 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:2776688The 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
Open this post in threaded view
|

## Re: STL problem - globoid worm gear system

 Nice job. I will have a look in your code later.2018-01-31 15:52 GMT-02:00 Parkinbot :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 _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org