NH
nop head
Thu, Nov 14, 2019 12:45 PM
Not sure why you say they are unprintable. If you give the curve some width
it becomes something you can print. It has intersecting loops but that
doesn't mean it has a self intersecting mesh.
On Thu, 14 Nov 2019 at 12:37, Dan Shriver tabbydan@gmail.com 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.
On Thursday, November 14, 2019, Doug Moen doug@moens.org wrote:
On Thu, Nov 14, 2019, at 2:47 AM, nop head wrote:
It isn't only during STL export that this goes wrong. A lot of OpenSCAD
operations use a PolySet representation, which is a polygon soup of
doubles. Whenever it converts from CGAL rationals to PolySet doubles is can
cause self intersections and degenerate triangles. Any of these will give a
CGAL exception if they get converted back to NefPolyhedra to do another CSG
operation. This is the source of endless CGAL exceptions that people
report. To avoid them the geometry has be manifold and free of
self-intersections even after its vertices are snapped to a grid and or
truncated. So you have to avoid close vertices as well.
This is fixable, at least partly. We need to change the PolySet
representation to include a vertex table, which contains the topology
information.
When we convert a Nef Polyhedron to a Polyset, the algorithm is:
- Using the CGAL representation of coordinates (rational numbers),
construct the vertex table. Two vertexes which have the same coordinates as
rational numbers will have the same vertex ID.
- Once the vertex table is constructed and vertex IDs are assigned,
then we convert rational numbers to floating point. At this stage, errors
may be introduced. For example, two distinct vertexes that are very close
together might merge into one due to floating point imprecision. But these
vertexes will still have different vertex IDs, so the topology is preserved.
At this point, we can export the Polyset as a 3MF file (or as any file
format that has a vertex table), and the topology will be correct. In the
case of 3MF, if the topology is valid then the mesh is valid for 3D
printing. There is still a problem with CGAL, but I'll address that.
When we import a 3MF file, we can test if it has correct topology (test
that it is manifold). For example, we could use CMeshObject::
IsManifoldAndOriented() from lib3mf, a library we already link to. The
documentation says this operation is fast. If the mesh is not manifold,
then it is badly damaged: according to the 3MF standard, it isn't 3D
printable. CGAL operations won't work: I think the conversion to a Nef
Polyhedron will just fail. We could issue an error message, or we could
print a warning and set a not_manifold flag on the PolySet object, to be
consulted if a CGAL operation fails.
I would like to change the polyhedron() operator, to perform the same
fast validation test on the output (is it manifold). We print a warning if
the polyhedron isn't manifold, and set a flag. Maybe there is more we can
do. The polyhedron() arguments include a vertex table, so we preserve that
vertex table in the PolySet.
When we import a 3MF file, the mesh may be self-intersecting. This is
legal, according to the 3MF standard. A mesh that is manifold but self
intersecting should be 3D printable, according to the standard. But CGAL
operations may fail, if the self intersection occurs in the neighbourhood
of where CGAL needs to split faces. CGAL 5.0 throws a specific exception
when it detects self-intersection, which we can catch and handle.
In order to conform to the 3MF standard, OpenSCAD is required to be
robust in the presence of self-intersection. CGAL boolean operations don't
support this, however, and I so far haven't found a competing mesh library
whose boolean operations support this. Such a library probably doesn't
exist. That means we need to repair the self-intersections in order for
CGAL to succeed.
CGAL 5 has a function for detecting self-intersection:
CGAL::Polygon_mesh_processing::does_self_intersect(). CGAL 5 has a suite of
mesh repair functions, but the documentation for these functions does not
mention repairing self-intersection. However, libigl has a CGAL-compatible
API for repairing self intersections
(include/igl/copyleft/cgal/SelfIntersectMesh.h). Maybe we can use it?
So in a lot of cases there is no "topology information" to preserve.
Whenever you do F6 and don't get the "simple:" report then the final result
is a PolySet, but even if the final result is a CGAL NefPolyhedron PolySets
might have been use for intermediate results.
So I don't think the problem is fixable for 3MF export without changing
PolySet to contain topology and also fix all the places that truncate or
snap to grid to fix the topology, which is hard. If one only needs to
design manifold geometry without self intersections then PolySets don't
need to store topology but the truncation problem sill needs to be fixed.
I don't really understand the rationale for "the places that truncate or
snap to grid to fix the topology". It sounds like a bad idea? We should be
using alternate methods? But I don't know.
My approach is not to repair the topology, if at all possible, because
there's no good way to do that. Instead, we should always try to maintain
valid topology (by storing a vertex table in PolySet). The result of a CGAL
operation will always contain valid topology. 3MF files are required to
contain valid topology, even if the vertex values are off and there is
self-intersection. Whenever we import a mesh or evaluate a polyhedron() or
polygon() call, we should test for valid topology and complain loudly if
the topology is bad. If a CGAL operation fails on a mesh or polygon due to
bad topology, then we report an error that mentions bad topology. Maybe we
can experiment with the CGAL functions for repairing topology and see if
they help?
We should definitely repair self intersections. I don't think that
starting from polygon soup and snapping to a grid is a valid way to repair
self intersections. I think that self-intersection repair should use
topology information (the vertex table) as a starting point. That way we
don't have to guess what the topology should be, we know. The libigl
self-intersection repair algorithm DOES use a vertex table for the input
mesh. This gives me hope that we could be using more robust/effective
methods for dealing with defective meshes.
Not sure why you say they are unprintable. If you give the curve some width
it becomes something you can print. It has intersecting loops but that
doesn't mean it has a self intersecting mesh.
On Thu, 14 Nov 2019 at 12:37, Dan Shriver <tabbydan@gmail.com> 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.
>
> On Thursday, November 14, 2019, Doug Moen <doug@moens.org> wrote:
>
>> On Thu, Nov 14, 2019, at 2:47 AM, nop head wrote:
>>
>> It isn't only during STL export that this goes wrong. A lot of OpenSCAD
>> operations use a PolySet representation, which is a polygon soup of
>> doubles. Whenever it converts from CGAL rationals to PolySet doubles is can
>> cause self intersections and degenerate triangles. Any of these will give a
>> CGAL exception if they get converted back to NefPolyhedra to do another CSG
>> operation. This is the source of endless CGAL exceptions that people
>> report. To avoid them the geometry has be manifold and free of
>> self-intersections even after its vertices are snapped to a grid and or
>> truncated. So you have to avoid close vertices as well.
>>
>>
>> This is fixable, at least partly. We need to change the PolySet
>> representation to include a vertex table, which contains the topology
>> information.
>>
>> When we convert a Nef Polyhedron to a Polyset, the algorithm is:
>> 1) Using the CGAL representation of coordinates (rational numbers),
>> construct the vertex table. Two vertexes which have the same coordinates as
>> rational numbers will have the same vertex ID.
>> 2) Once the vertex table is constructed and vertex IDs are assigned,
>> then we convert rational numbers to floating point. At this stage, errors
>> may be introduced. For example, two distinct vertexes that are very close
>> together might merge into one due to floating point imprecision. But these
>> vertexes will still have different vertex IDs, so the topology is preserved.
>>
>> At this point, we can export the Polyset as a 3MF file (or as any file
>> format that has a vertex table), and the topology will be correct. In the
>> case of 3MF, if the topology is valid then the mesh is valid for 3D
>> printing. There is still a problem with CGAL, but I'll address that.
>>
>> When we import a 3MF file, we can test if it has correct topology (test
>> that it is manifold). For example, we could use CMeshObject::
>> IsManifoldAndOriented() from lib3mf, a library we already link to. The
>> documentation says this operation is fast. If the mesh is not manifold,
>> then it is badly damaged: according to the 3MF standard, it isn't 3D
>> printable. CGAL operations won't work: I think the conversion to a Nef
>> Polyhedron will just fail. We could issue an error message, or we could
>> print a warning and set a not_manifold flag on the PolySet object, to be
>> consulted if a CGAL operation fails.
>>
>> I would like to change the polyhedron() operator, to perform the same
>> fast validation test on the output (is it manifold). We print a warning if
>> the polyhedron isn't manifold, and set a flag. Maybe there is more we can
>> do. The polyhedron() arguments include a vertex table, so we preserve that
>> vertex table in the PolySet.
>>
>> When we import a 3MF file, the mesh may be self-intersecting. This is
>> legal, according to the 3MF standard. A mesh that is manifold but self
>> intersecting should be 3D printable, according to the standard. But CGAL
>> operations may fail, if the self intersection occurs in the neighbourhood
>> of where CGAL needs to split faces. CGAL 5.0 throws a specific exception
>> when it detects self-intersection, which we can catch and handle.
>>
>> In order to conform to the 3MF standard, OpenSCAD is required to be
>> robust in the presence of self-intersection. CGAL boolean operations don't
>> support this, however, and I so far haven't found a competing mesh library
>> whose boolean operations support this. Such a library probably doesn't
>> exist. That means we need to repair the self-intersections in order for
>> CGAL to succeed.
>>
>> CGAL 5 has a function for detecting self-intersection:
>> CGAL::Polygon_mesh_processing::does_self_intersect(). CGAL 5 has a suite of
>> mesh repair functions, but the documentation for these functions does not
>> mention repairing self-intersection. However, libigl has a CGAL-compatible
>> API for repairing self intersections
>> (include/igl/copyleft/cgal/SelfIntersectMesh.h). Maybe we can use it?
>>
>> So in a lot of cases there is no "topology information" to preserve.
>> Whenever you do F6 and don't get the "simple:" report then the final result
>> is a PolySet, but even if the final result is a CGAL NefPolyhedron PolySets
>> might have been use for intermediate results.
>>
>> So I don't think the problem is fixable for 3MF export without changing
>> PolySet to contain topology and also fix all the places that truncate or
>> snap to grid to fix the topology, which is hard. If one only needs to
>> design manifold geometry without self intersections then PolySets don't
>> need to store topology but the truncation problem sill needs to be fixed.
>>
>>
>> I don't really understand the rationale for "the places that truncate or
>> snap to grid to fix the topology". It sounds like a bad idea? We should be
>> using alternate methods? But I don't know.
>>
>> My approach is not to repair the topology, if at all possible, because
>> there's no good way to do that. Instead, we should always try to maintain
>> valid topology (by storing a vertex table in PolySet). The result of a CGAL
>> operation will always contain valid topology. 3MF files are required to
>> contain valid topology, even if the vertex values are off and there is
>> self-intersection. Whenever we import a mesh or evaluate a polyhedron() or
>> polygon() call, we should test for valid topology and complain loudly if
>> the topology is bad. If a CGAL operation fails on a mesh or polygon due to
>> bad topology, then we report an error that mentions bad topology. Maybe we
>> can experiment with the CGAL functions for repairing topology and see if
>> they help?
>>
>> We should definitely repair self intersections. I don't think that
>> starting from polygon soup and snapping to a grid is a valid way to repair
>> self intersections. I think that self-intersection repair should use
>> topology information (the vertex table) as a starting point. That way we
>> don't have to guess what the topology should be, we know. The libigl
>> self-intersection repair algorithm DOES use a vertex table for the input
>> mesh. This gives me hope that we could be using more robust/effective
>> methods for dealing with defective meshes.
>>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
RP
Ronaldo Persiano
Thu, Nov 14, 2019 1:39 PM
@dough
How a self-intersection could be repaired? Before figuring a process out to
do it I need to understand what outcome the process should have. What would
be the repair of the linear_extrusion of a single polygon tracking the
figure of an 8?
@dough
How a self-intersection could be repaired? Before figuring a process out to
do it I need to understand what outcome the process should have. What would
be the repair of the linear_extrusion of a single polygon tracking the
figure of an 8?
DM
Doug Moen
Thu, Nov 14, 2019 1:53 PM
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.
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.
TV
Tim V. Shaporev
Thu, Nov 14, 2019 2:34 PM
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@moens.org
mailto:doug@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@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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@moens.org
> <mailto:doug@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@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
DS
Dan Shriver
Thu, Nov 14, 2019 2:36 PM
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@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.
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@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.
>
>
>
NH
nop head
Thu, Nov 14, 2019 2:54 PM
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@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@moens.org
mailto:doug@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
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@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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@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@moens.org
> > <mailto:doug@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@lists.openscad.org
> > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
> >
>
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
DS
Dan Shriver
Thu, Nov 14, 2019 2:58 PM
If you want to see it, before I get back to the box where it is saved,
check this list for my posts. I posted questions about it over a year ago
(ignore posts from me about ogee / arches, hyperbolic trig, etc) might even
be two years ago.
On Thursday, November 14, 2019, Tim V. Shaporev tim.shaporev@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@moens.org <mailto:
doug@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@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
If you want to see it, before I get back to the box where it is saved,
check this list for my posts. I posted questions about it over a year ago
(ignore posts from me about ogee / arches, hyperbolic trig, etc) might even
be two years ago.
On Thursday, November 14, 2019, Tim V. Shaporev <tim.shaporev@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@moens.org <mailto:
>> doug@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@lists.openscad.org
>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>>
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
DM
Doug Moen
Thu, Nov 14, 2019 3:13 PM
On Thu, Nov 14, 2019, at 8:39 AM, Ronaldo Persiano wrote:
@doug
How a self-intersection could be repaired? Before figuring a process out to do it I need to understand what outcome the process should have. What would be the repair of the linear_extrusion of a single polygon tracking the figure of an 8?
I have never written a mesh repair algorithm, so I'm not an expert.
A mesh is self intersecting if any two faces intersect. Repairing the intersection of two faces involves splitting both faces into smaller triangles.
In a linear extrusion of a figure "8", there will be two rectangular faces that intersect, and these each need to be split into two smaller rectangles.
If I was doing this, then I would add a repair_self_intersections module to OpenSCAD, using C++. I would call the libIGL API for repairing self intersections. I wouldn't attempt to implement the algorithm myself. Then I would apply the repair_self_intersections module to the linear extrusion of a figure 8, and see what the output looks like.
Note: According to my intuition, a repair algorithm would need topology information (a vertex table), and it would require the mesh to be manifold, in order to succeed.
Note: In the polygon shaped like an "8", if there is a single point in the "points" list at the location where the lines cross, and if this point is referenced twice in the path, then the polygon is not manifold. The linear extrude of a non-manifold polygon creates a non-manifold mesh. I would expect the repair process to fail. To make the polygon manifold, each point in the points list must be referenced only once in the path. With the current design of OpenSCAD, you also need to ensure that there are no duplicated points in the points list, which means that the point at the location where the lines path cannot be a vertex. This puts some otherwise valid polygons off limits in OpenSCAD. In the future, OpenSCAD should preserve the topology information in the representation of polygons and meshes. With this change, it will be possible to have duplicated points in the points list.
On Thu, Nov 14, 2019, at 8:39 AM, Ronaldo Persiano wrote:
> @doug
>
> How a self-intersection could be repaired? Before figuring a process out to do it I need to understand what outcome the process should have. What would be the repair of the linear_extrusion of a single polygon tracking the figure of an 8?
I have never written a mesh repair algorithm, so I'm not an expert.
A mesh is self intersecting if any two faces intersect. Repairing the intersection of two faces involves splitting both faces into smaller triangles.
In a linear extrusion of a figure "8", there will be two rectangular faces that intersect, and these each need to be split into two smaller rectangles.
If I was doing this, then I would add a `repair_self_intersections` module to OpenSCAD, using C++. I would call the libIGL API for repairing self intersections. I wouldn't attempt to implement the algorithm myself. Then I would apply the `repair_self_intersections` module to the linear extrusion of a figure 8, and see what the output looks like.
Note: According to my intuition, a repair algorithm would need topology information (a vertex table), and it would require the mesh to be manifold, in order to succeed.
Note: In the polygon shaped like an "8", if there is a single point in the "points" list at the location where the lines cross, and if this point is referenced twice in the path, then the polygon is not manifold. The linear extrude of a non-manifold polygon creates a non-manifold mesh. I would expect the repair process to fail. To make the polygon manifold, each point in the points list must be referenced only once in the path. With the current design of OpenSCAD, you also need to ensure that there are no duplicated points in the points list, which means that the point at the location where the lines path cannot be a vertex. This puts some otherwise valid polygons off limits in OpenSCAD. In the future, OpenSCAD should preserve the topology information in the representation of polygons and meshes. With this change, it will be possible to have duplicated points in the points list.
DM
Doug Moen
Thu, Nov 14, 2019 3:30 PM
On Thu, Nov 14, 2019, at 9:54 AM, nop head wrote:
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, Nov 14, 2019, at 9:54 AM, nop head wrote:
> 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.
The 3MF standard describes unambiguously what gets printed when you send a self intersecting mesh to a 3D printer.
It is called "the positive fill rule". https://github.com/3MFConsortium/spec_core/blob/master/3MF%20Core%20Specification.md#411-fill-rule
Lots of slicers now support the 3MF standard. The ones I use (Cura, Prusa Slicer) support 3MF.
A
arnholm@arnholm.org
Thu, Nov 14, 2019 3:32 PM
On 2019-11-14 16:13, Doug Moen wrote:
On Thu, Nov 14, 2019, at 8:39 AM, Ronaldo Persiano wrote:
I have never written a mesh repair algorithm, so I'm not an expert.
A mesh is self intersecting if any two faces intersect. Repairing the
intersection of two faces involves splitting both faces into smaller
triangles.
I have played around with mesh repair, as part of AngelCAD you get
"polyfix" which is a mesh repair utility that can improve quite a few
models and sometimes cure them completely by making them 2-manifold.
I think self-intersections are almost always a sign of something else
gone wrong, it is typically a body that overlaps itself and and not a
result of a boolean operation. A self-overlapping volume is physically
impossible. There are lots of ways to use bodies that are not
2-manifold, but a self overlapping volume seems like an obvious mistake.
Attempting to automatically repair the kind of self intersection you
describe, i.e. two faces intersecting will give "interesting" results.
If you split the two faces into say 4 triangles it implies creating a
4-manifold edge... so an automatic repair attempt of such issues is
mostly self defeating. I would keep it as a separate issue most likely
requiring the user to fix something he did wrong.
Carsten Arnholm
On 2019-11-14 16:13, Doug Moen wrote:
> On Thu, Nov 14, 2019, at 8:39 AM, Ronaldo Persiano wrote:
> I have never written a mesh repair algorithm, so I'm not an expert.
>
> A mesh is self intersecting if any two faces intersect. Repairing the
> intersection of two faces involves splitting both faces into smaller
> triangles.
I have played around with mesh repair, as part of AngelCAD you get
"polyfix" which is a mesh repair utility that can improve quite a few
models and sometimes cure them completely by making them 2-manifold.
I think self-intersections are almost always a sign of something else
gone wrong, it is typically a body that overlaps itself and and not a
result of a boolean operation. A self-overlapping volume is physically
impossible. There are lots of ways to use bodies that are not
2-manifold, but a self overlapping volume seems like an obvious mistake.
Attempting to automatically repair the kind of self intersection you
describe, i.e. two faces intersecting will give "interesting" results.
If you split the two faces into say 4 triangles it implies creating a
4-manifold edge... so an automatic repair attempt of such issues is
mostly self defeating. I would keep it as a separate issue most likely
requiring the user to fix something he did wrong.
Carsten Arnholm
