STL problem - globoid worm gear system

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

STL problem - globoid worm gear system

Parkinbot
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/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: STL problem - globoid worm gear system

Ronaldo
​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?

2017-12-26 23:23 GMT-02:00 Parkinbot <[hidden email]>:
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/

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

Re: STL problem - globoid worm gear system

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

Re: STL problem - globoid worm gear system

Ronaldo
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.

2017-12-28 20:35 GMT-02:00 Parkinbot <[hidden email]>:
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


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: STL problem - globoid worm gear system

nophead
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:
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.

2017-12-28 20:35 GMT-02:00 Parkinbot <[hidden email]>:
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


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

Re: STL problem - globoid worm gear system

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

Re: STL problem - globoid worm gear system

Alan Cox
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
Reply | Threaded
Open this post in threaded view
|

Re: STL problem - globoid worm gear system

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

Re: STL problem - globoid worm gear system

cacb

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#a19440

Carsten Arnholm

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: STL problem - globoid worm gear system

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

Re: STL problem - globoid worm gear system

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

Re: STL problem - globoid worm gear system

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

Re: STL problem - globoid worm gear system

Parkinbot
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.

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

Re: STL problem - globoid worm gear system

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

Re: STL problem - globoid worm gear system

Parkinbot
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/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
Reply | Threaded
Open this post in threaded view
|

Re: STL problem - globoid worm gear system

Ronaldo
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 non-convex 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.

2018-01-06 11:05 GMT-02:00 Parkinbot <[hidden email]>:
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/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


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: STL problem - globoid worm gear system

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

Re: STL problem - globoid worm gear system

Ronaldo
Nice job. I will have a look in your code later.

2018-01-31 15:52 GMT-02:00 Parkinbot <[hidden email]>:
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
Reply | Threaded
Open this post in threaded view
|

Re: STL problem - globoid worm gear system

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

Re: STL problem - globoid worm gear system

Parkinbot
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