STL problem - globoid worm gear system
On Jan 1, 2018, at 11:43 AM, Parkinbot rudolf@parkinbot.com 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
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/
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/
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/
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/
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 rudolf@parkinbot.com:
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
Discuss@lists.openscad.org
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/
Nice job. I will have a look in your code later.
2018-01-31 15:52 GMT-02:00 Parkinbot rudolf@parkinbot.com:
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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
To everyone who is interested, the math I'm using is rather simple:
- 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. - I do the same with the lower face of the helical gear.
- 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/
Thanks, that is exactly how I finally diid it.
--
Sent from: http://forum.openscad.org/