[OpenSCAD] Discuss manifoldness, co-incident faces edges etc

nop head nop.head at gmail.com
Thu Nov 14 09:54:24 EST 2019


If you sweep a square around a full epicycle then you would get a self
intersecting mesh but if you do half a cycle and then duplicate it and
reflect it and then union those bits together it should produce a manifold
object that can be printed. That is how somebody on this list does screw
threads with sweep. Yes you could be unlucky with OpenSCAD and nearly
coincident vertices but that is just a bug.

If somebody can describe unambiguously what gets printed when you send a
self intersecting mesh to a 3D printer then that would be a basis for
fixing it because anything that comes out of a 3D printer must be manifold
and free from self intersections.

On Thu, 14 Nov 2019 at 14:45, Tim V. Shaporev <tim.shaporev at auriga.ru>
wrote:

> I am interested in the epicycles sample too because I could not
> comprehend what the problem is (a minute of self-advertising :-)
> https://www.thingiverse.com/thing:3483143
> and I'd appreciate new idea(s)
>
> On 11/14/2019 5:36 PM, Dan Shriver wrote:
> > Thanks Doug. I can provide an example next month when I have access to
> > the code again.  I did epicycles and things like them and one surface
> > looped from the outside into the inside.
> >
> > There probably are tools / algorithms for "fixing" stuff like this since
> > it is a general problem in making 3D volumes (when one has loops, voids).
> >
> > I don't believe I was using sweep at the time.  I think I did some ugly
> > homegrown thing where I did a linear extrude of an epicycle.  I would
> > "gradually" add a term by tacking it on (with a tiny fraction
> > multiplier) doing another extrude, increasing the multiple.... Until the
> > term was at 100% then I'd add a new term....
> >
> > Deprecating STL support sounds like curing a headache with hemlock.  I'm
> > not going to argue that STL isn't a seriously flawed format, but it is
> > accepted by a wide range of 3D printers.  Maybe print a warning to the
> > console that suggests another format(s) on export to STL, nudge people
> > in the right direction but don't force them to abandon something they
> > might require.  You might have meant that yourself as you said you can't
> > remove it but the phrase "deprecate STL" was also used, which spooks me.
> >
> > On Thursday, November 14, 2019, Doug Moen <doug at moens.org
> > <mailto:doug at moens.org>> wrote:
> >
> >     __
> >     On Thu, Nov 14, 2019, at 7:36 AM, Dan Shriver wrote:
> >>     Ideally I'd like to see some way to fix manifold issues.
> >>
> >>     For instance, I like to play with epicycles and the like.
> >>     Unfortunately, these shapes, while aesthetically pleasing tend to
> >>     do a lot of intersecting loops etc.  The end result is they are
> >>     unprintable.
> >
> >     Hi Dan. If you sweep a shape through an epicycle, then technically,
> >     the resulting mesh will be manifold, but it will be self
> intersecting.
> >
> >     I know nophead said something slightly different, but my definition
> >     of "self intersecting" is: there are two faces, anywhere in the
> >     model, that intersect each other.
> >
> >     Normally, a slicer program should be able to print a model that is
> >     manifold but self intersecting. But you may run into problems that
> >     prevent the model from being printable.
> >
> >     One reason why an epicycle mesh might be unprintable is because it
> >     becomes accidently non-manifold as a result of export to STL. At the
> >     point where two regions of the swept path intersect each other,
> >     there might be two vertices that coincide. If the mesh
> >     representation contains topology information, then the topology will
> >     tell the 3D printer slicer that those vertices are actually
> >     distinct, and there's no problem. However, when you export to STL,
> >     then the topology information is lost, and those coinciding vertices
> >     will be identified as the same vertex, and that makes the mesh
> >     non-manifold. Which means you can't print it.
> >
> >     I think that we need to do two things to fix this problem. We need
> >     to change OpenSCAD to preserve topology information when processing
> >     and exporting meshes. And we need to deprecate the STL file format.
> >     Obviously we can't remove STL support. But we need to educate our
> >     users that exporting to STL destroys topology information, which can
> >     sometimes make a mesh unprintable. We need to explain the benefits
> >     of alternate file formats that support topology information, such as
> >     OBJ and 3MF.
> >
> >     ---
> >     I think that OpenSCAD should automatically repair self
> >     intersections, but only in the case where CGAL fails with a
> >     self-intersection error. Otherwise, we should leave the model the
> >     way it is, in order to satisfy users who don't want OpenSCAD to mess
> >     around with their carefully specified mesh for unnecessary reasons.
> >     OpenSCAD should also provide a `repair_self_intersections` module,
> >     so that you can do it yourself. You might need to repair self
> >     intersections if they are causing problems upstream. For example,
> >     you might do this if you are exporting to STL.
> >
> >
> >
> > _______________________________________________
> > OpenSCAD mailing list
> > Discuss at lists.openscad.org
> > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
> >
>
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss at lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20191114/5a6910bb/attachment.html>


More information about the Discuss mailing list