Re: manifold error
I noticed in a previous reply that I did not reply to all and the OpenSCAD
list was not included and I'm correcting that now.
On Thu, Oct 17, 2024 at 8:46 PM Todd Allen speedebikes@gmail.com wrote:
Try taking one of them, and unioning it with a small cube.
Then try taking the other, and doing the same.
There's a decent chance that there's a problem with one of them, rather
than the problem being with the combination per se.
Thanks! I get the same warning when I union my rounded_prism() with a
cube while the screw_hole() in union with a cube does not produce the
warning. Tomorrow I will try variations of the parameters to
rounded_prism() to see if I can further isolate when the problem arises.
On Thu, Oct 17, 2024 at 6:47 PM Jordan Brown <
openscad@jordan.maileater.net> wrote:
On 10/17/2024 12:30 PM, Todd Allen wrote:
I'm not sure what you mean by "a difference of two objects which each
render separately when the Manifold backup is enabled".
Do you mean that you have Manifold enabled, and you have two objects A
and B that render OK individually but when you try to render them together
you get an error?
With the Manifold backend enabled I can produce an object with a call of
BOSL2's rounded_prism(parameter_list_a) that renders and I can produce an
object with a call of BOSL2's screw_hole(parameter_list_b) that renders but
difference() {rounded_prism(parameter_list_a);
screw_hole(parameter_list_b);}
produces:
"WARNING: PolySet -> Manifold conversion failed: NotManifold
Trying to repair and reconstruct mesh.."
When I disable the option to stop on first warning the difference() does
successfully render so I should have called this a Manifold warning instead
of calling it an error.
OK.
Try taking one of them, and unioning it with a small cube.
Then try taking the other, and doing the same.
There's a decent chance that there's a problem with one of them, rather
than the problem being with the combination per se.
I think BOSL2 modules like these are generally "just" polyhedron calls
(with a lot of calculation to get the parameters, of course) and so if they
build the polyhedron wrong they will end up with the standard OpenSCAD
bad-polyhedron behavior: preview is fine, rendered by itself is fine, any
boolean operation is bad.
After you try the "one at a time with a cube" test above, if you send me
the relevant calls I'll see if I can spot the problem.
Your suggestion to union a cube with each object to detect those improperly
formed was useful. It is easy to produce a rounded prism which fails this
test, just enabling any rounding appears sufficient. For example:
include <BOSL2/std.scad>
include <BOSL2/rounding.scad>
union() {cube(3, center=true); rounded_prism(square(10), square(10),
height=10, joint_top=1);}
when rendered with manifold produces the warning:
"WARNING: PolySet -> Manifold conversion failed: NotManifold"
On Fri, Oct 18, 2024 at 10:09 AM Todd Allen speedebikes@gmail.com wrote:
I noticed in a previous reply that I did not reply to all and the OpenSCAD
list was not included and I'm correcting that now.
On Thu, Oct 17, 2024 at 8:46 PM Todd Allen speedebikes@gmail.com wrote:
Try taking one of them, and unioning it with a small cube.
Then try taking the other, and doing the same.
There's a decent chance that there's a problem with one of them, rather
than the problem being with the combination per se.
Thanks! I get the same warning when I union my rounded_prism() with a
cube while the screw_hole() in union with a cube does not produce the
warning. Tomorrow I will try variations of the parameters to
rounded_prism() to see if I can further isolate when the problem arises.
On Thu, Oct 17, 2024 at 6:47 PM Jordan Brown <
openscad@jordan.maileater.net> wrote:
On 10/17/2024 12:30 PM, Todd Allen wrote:
I'm not sure what you mean by "a difference of two objects which each
render separately when the Manifold backup is enabled".
Do you mean that you have Manifold enabled, and you have two objects A
and B that render OK individually but when you try to render them together
you get an error?
With the Manifold backend enabled I can produce an object with a call of
BOSL2's rounded_prism(parameter_list_a) that renders and I can produce an
object with a call of BOSL2's screw_hole(parameter_list_b) that renders but
difference() {rounded_prism(parameter_list_a);
screw_hole(parameter_list_b);}
produces:
"WARNING: PolySet -> Manifold conversion failed: NotManifold
Trying to repair and reconstruct mesh.."
When I disable the option to stop on first warning the difference() does
successfully render so I should have called this a Manifold warning instead
of calling it an error.
OK.
Try taking one of them, and unioning it with a small cube.
Then try taking the other, and doing the same.
There's a decent chance that there's a problem with one of them, rather
than the problem being with the combination per se.
I think BOSL2 modules like these are generally "just" polyhedron calls
(with a lot of calculation to get the parameters, of course) and so if they
build the polyhedron wrong they will end up with the standard OpenSCAD
bad-polyhedron behavior: preview is fine, rendered by itself is fine, any
boolean operation is bad.
After you try the "one at a time with a cube" test above, if you send me
the relevant calls I'll see if I can spot the problem.
On 10/18/2024 8:16 AM, Todd Allen wrote:
Your suggestion to union a cube with each object to detect those
improperly formed was useful. It is easy to produce a rounded prism
which fails this test, just enabling any rounding appears sufficient.
For example:
include <BOSL2/std.scad>
include <BOSL2/rounding.scad>
union() {cube(3, center=true); rounded_prism(square(10), square(10),
height=10, joint_top=1);}
when rendered with manifold produces the warning:
"WARNING: PolySet -> Manifold conversion failed: NotManifold"
This looks to me like a bug in BOSL2, or arguably a bug/gap in Manifold.
There are numerous points that are very very close to being duplicates,
but are not exactly the same. This indicates that BOSL2 is calculating
the same point twice using different arithmetic, and floating point
inaccuracy means that the two calculations end up very slightly
different. I believe the CGAL implementation snaps everything to a grid
to address this sort of problem; it seems that the Manifold
implementation does not.
Here's a slightly simpler demonstration, with lower resolution so there
are fewer points.
union() {
cube();
rounded_prism(square(10), square(10), height=10, joint_top=1, splinesteps=1);
}
Here are the points in that figure (extracted from the function form of
rounded_prism()):
[[9, 1, 5], [10, -2.22045e-16, 4], [1, 1, 5], [-2.22045e-16, -2.22045e-16, 4],
[1, 1, 5], [-2.22045e-16, -2.22045e-16, 4], [1, 9, 5], [-2.22045e-16, 10, 4],
[1, 9, 5], [-2.22045e-16, 10, 4], [9, 9, 5], [10, 10, 4], [9, 9, 5],
[10, 10, 4], [9, 1, 5], [10, -2.22045e-16, 4], [9, 1, 5], [1, 1, 5], [1, 9, 5],
[9, 9, 5], [10, 10, -5], [0, 10, -5], [0, 0, -5], [10, 0, -5], [10, 0, -5],
[0, 0, -5], [0, 0, 4], [10, 0, 4], [0, 0, -5], [0, 10, -5], [0, 10, 4],
[0, 0, 4], [0, 10, -5], [10, 10, -5], [10, 10, 4], [0, 10, 4], [10, 10, -5],
[10, 0, -5], [10, 0, 4], [10, 10, 4]]
And here are the not-quite-duplicates in that list (as index, value,
index, value):
ECHO: [1, [10, -2.22045e-16, 4], 27, [10, 0, 4]]
ECHO: [1, [10, -2.22045e-16, 4], 38, [10, 0, 4]]
ECHO: [3, [-2.22045e-16, -2.22045e-16, 4], 26, [0, 0, 4]]
ECHO: [3, [-2.22045e-16, -2.22045e-16, 4], 31, [0, 0, 4]]
ECHO: [5, [-2.22045e-16, -2.22045e-16, 4], 26, [0, 0, 4]]
ECHO: [5, [-2.22045e-16, -2.22045e-16, 4], 31, [0, 0, 4]]
ECHO: [7, [-2.22045e-16, 10, 4], 30, [0, 10, 4]]
ECHO: [7, [-2.22045e-16, 10, 4], 35, [0, 10, 4]]
ECHO: [9, [-2.22045e-16, 10, 4], 30, [0, 10, 4]]
ECHO: [9, [-2.22045e-16, 10, 4], 35, [0, 10, 4]]
ECHO: [15, [10, -2.22045e-16, 4], 27, [10, 0, 4]]
ECHO: [15, [10, -2.22045e-16, 4], 38, [10, 0, 4]]
There are also a number of exact duplicates, but I don't think they
cause problems.
But manifold doesn't really care about coordinates when checking for
manifoldness, it just cares about vertex indices in the list of
triangles. Previously, openscad would snap vertices to a grid and merge
identical vertices, but that can lose manifoldness in general and it is
really hard to fix, so it is no longer doing that when the mesh PolySet
can directly be imported into manifold.
On 19/10/2024 00:42, Jordan Brown via Discuss wrote:
On 10/18/2024 8:16 AM, Todd Allen wrote:
Your suggestion to union a cube with each object to detect those
improperly formed was useful. It is easy to produce a rounded prism
which fails this test, just enabling any rounding appears
sufficient. For example:
include <BOSL2/std.scad>
include <BOSL2/rounding.scad>
union() {cube(3, center=true); rounded_prism(square(10), square(10),
height=10, joint_top=1);}
when rendered with manifold produces the warning:
"WARNING: PolySet -> Manifold conversion failed: NotManifold"
This looks to me like a bug in BOSL2, or arguably a bug/gap in Manifold.
There are numerous points that are very very close to being
duplicates, but are not exactly the same. This indicates that BOSL2
is calculating the same point twice using different arithmetic, and
floating point inaccuracy means that the two calculations end up very
slightly different. I believe the CGAL implementation snaps
everything to a grid to address this sort of problem; it seems that
the Manifold implementation does not.
Here's a slightly simpler demonstration, with lower resolution so
there are fewer points.
union() {
cube();
rounded_prism(square(10), square(10), height=10, joint_top=1, splinesteps=1);
}
Here are the points in that figure (extracted from the function form
of rounded_prism()):
[[9, 1, 5], [10, -2.22045e-16, 4], [1, 1, 5], [-2.22045e-16, -2.22045e-16, 4],
[1, 1, 5], [-2.22045e-16, -2.22045e-16, 4], [1, 9, 5], [-2.22045e-16, 10, 4],
[1, 9, 5], [-2.22045e-16, 10, 4], [9, 9, 5], [10, 10, 4], [9, 9, 5],
[10, 10, 4], [9, 1, 5], [10, -2.22045e-16, 4], [9, 1, 5], [1, 1, 5], [1, 9, 5],
[9, 9, 5], [10, 10, -5], [0, 10, -5], [0, 0, -5], [10, 0, -5], [10, 0, -5],
[0, 0, -5], [0, 0, 4], [10, 0, 4], [0, 0, -5], [0, 10, -5], [0, 10, 4],
[0, 0, 4], [0, 10, -5], [10, 10, -5], [10, 10, 4], [0, 10, 4], [10, 10, -5],
[10, 0, -5], [10, 0, 4], [10, 10, 4]]
And here are the not-quite-duplicates in that list (as index, value,
index, value):
ECHO: [1, [10, -2.22045e-16, 4], 27, [10, 0, 4]]
ECHO: [1, [10, -2.22045e-16, 4], 38, [10, 0, 4]]
ECHO: [3, [-2.22045e-16, -2.22045e-16, 4], 26, [0, 0, 4]]
ECHO: [3, [-2.22045e-16, -2.22045e-16, 4], 31, [0, 0, 4]]
ECHO: [5, [-2.22045e-16, -2.22045e-16, 4], 26, [0, 0, 4]]
ECHO: [5, [-2.22045e-16, -2.22045e-16, 4], 31, [0, 0, 4]]
ECHO: [7, [-2.22045e-16, 10, 4], 30, [0, 10, 4]]
ECHO: [7, [-2.22045e-16, 10, 4], 35, [0, 10, 4]]
ECHO: [9, [-2.22045e-16, 10, 4], 30, [0, 10, 4]]
ECHO: [9, [-2.22045e-16, 10, 4], 35, [0, 10, 4]]
ECHO: [15, [10, -2.22045e-16, 4], 27, [10, 0, 4]]
ECHO: [15, [10, -2.22045e-16, 4], 38, [10, 0, 4]]
There are also a number of exact duplicates, but I don't think they
cause problems.
OpenSCAD mailing list
To unsubscribe send an email todiscuss-leave@lists.openscad.org
On 10/18/2024 9:52 AM, Chun Kit LAM via Discuss wrote:
But manifold doesn't really care about coordinates when checking for
manifoldness, it just cares about vertex indices in the list of
triangles. Previously, openscad would snap vertices to a grid and
merge identical vertices, but that can lose manifoldness in general
and it is really hard to fix, so it is no longer doing that when the
mesh PolySet can directly be imported into manifold.
Are you saying that vertexes shared between faces must use the same
indexes? Experiments indicate that there's no such requirement. I
constructed a cube out of 24 vertexes, and Manifold seemed perfectly
happy with it. Correcting the 2e-16 values in the rounded prism to
zero, without eliminating the duplication, made the problem go away.
I'm not really a fan of the grid-snap scheme; it causes problems on its
own. Getting rid of it might be a win, but will likely cause problems
like this one. (But I admit I have no experience with not using it.)
I'd like to think that we could have a scheme that snapped together
"clusters" of points that are very close to one another (say, a
difference of less than one part in 10^14), and gave up if a cluster
ever spanned the limit. (That is, if point A is considered close to B,
and B is considered close to C, but A is not close to C.) Such a scheme
seems like it could have a very high accuracy rate, fixing FP precision
problems without merging points that should be distinct. But I suspect
that it would also be quite expensive.
Are you saying that vertexes shared between faces must use the same
indexes?
Both yes and no. If you mean vertices shared between triangles must use
the same indices, yes. But you can have vertices with the same
coordinate, so they can have different indices and are not shared by
triangles, despite triangles containing them can be touching
geometrically (if you consider coordinates).
The topological definition of manifoldness used in manifold is actually
very simple, see
https://github.com/elalish/manifold/wiki/Manifold-Library#manifoldness-definition
Every edge of every triangle must contain the same two vertices (by
index) as exactly one other triangle edge, and the start and end
vertices must switch places between these two edges. The triangle
vertices must appear in counter-clockwise order when viewed from the
outside of the manifold.
I think the issue is in the polyhedron triangle list not being manifold.
E.g. there may be a tiny open hole in the mesh, but merging vertices
close to each other may make the hole disappear because all vertices
around the hole are merged into one. If I recall correctly, openscad
should try the CGAL way of repairing meshes when manifold cannot import
the mesh, no idea why it doesn't work in this case.
On 19/10/2024 01:24, Jordan Brown wrote:
On 10/18/2024 9:52 AM, Chun Kit LAM via Discuss wrote:
But manifold doesn't really care about coordinates when checking for
manifoldness, it just cares about vertex indices in the list of
triangles. Previously, openscad would snap vertices to a grid and
merge identical vertices, but that can lose manifoldness in general
and it is really hard to fix, so it is no longer doing that when the
mesh PolySet can directly be imported into manifold.
Are you saying that vertexes shared between faces must use the same
indexes? Experiments indicate that there's no such requirement. I
constructed a cube out of 24 vertexes, and Manifold seemed perfectly
happy with it. Correcting the 2e-16 values in the rounded prism to
zero, without eliminating the duplication, made the problem go away.
I'm not really a fan of the grid-snap scheme; it causes problems on
its own. Getting rid of it might be a win, but will likely cause
problems like this one. (But I admit I have no experience with not
using it.) I'd like to think that we could have a scheme that snapped
together "clusters" of points that are very close to one another (say,
a difference of less than one part in 10^14), and gave up if a cluster
ever spanned the limit. (That is, if point A is considered close to
B, and B is considered close to C, but A is not close to C.) Such a
scheme seems like it could have a very high accuracy rate, fixing FP
precision problems without merging points that should be distinct.
But I suspect that it would also be quite expensive.
If I recall correctly, openscad should try the CGAL way of repairing
meshes when manifold cannot import
the mesh, no idea why it doesn't work in this case.
I reported this incorrectly as an error which stopped rendering. But it is
only a warning. However I had the option set to stop at first warning.
Disabling that option allows this to successfully render.
If this sort of mesh issue is expected to be commonly corrected by the
automatic repair process perhaps it would be ok to downgrade this message
from WARNING to INFO and only after the repair fails issue a warning or let
it error out.
On Fri, Oct 18, 2024 at 12:45 PM Chun Kit LAM via Discuss <
discuss@lists.openscad.org> wrote:
Are you saying that vertexes shared between faces must use the same
indexes?
Both yes and no. If you mean vertices shared between triangles must use
the same indices, yes. But you can have vertices with the same
coordinate, so they can have different indices and are not shared by
triangles, despite triangles containing them can be touching
geometrically (if you consider coordinates).
The topological definition of manifoldness used in manifold is actually
very simple, see
https://github.com/elalish/manifold/wiki/Manifold-Library#manifoldness-definition
Every edge of every triangle must contain the same two vertices (by
index) as exactly one other triangle edge, and the start and end
vertices must switch places between these two edges. The triangle
vertices must appear in counter-clockwise order when viewed from the
outside of the manifold.
I think the issue is in the polyhedron triangle list not being manifold.
E.g. there may be a tiny open hole in the mesh, but merging vertices
close to each other may make the hole disappear because all vertices
around the hole are merged into one. If I recall correctly, openscad
should try the CGAL way of repairing meshes when manifold cannot import
the mesh, no idea why it doesn't work in this case.
On 19/10/2024 01:24, Jordan Brown wrote:
On 10/18/2024 9:52 AM, Chun Kit LAM via Discuss wrote:
But manifold doesn't really care about coordinates when checking for
manifoldness, it just cares about vertex indices in the list of
triangles. Previously, openscad would snap vertices to a grid and
merge identical vertices, but that can lose manifoldness in general
and it is really hard to fix, so it is no longer doing that when the
mesh PolySet can directly be imported into manifold.
Are you saying that vertexes shared between faces must use the same
indexes? Experiments indicate that there's no such requirement. I
constructed a cube out of 24 vertexes, and Manifold seemed perfectly
happy with it. Correcting the 2e-16 values in the rounded prism to
zero, without eliminating the duplication, made the problem go away.
I'm not really a fan of the grid-snap scheme; it causes problems on
its own. Getting rid of it might be a win, but will likely cause
problems like this one. (But I admit I have no experience with not
using it.) I'd like to think that we could have a scheme that snapped
together "clusters" of points that are very close to one another (say,
a difference of less than one part in 10^14), and gave up if a cluster
ever spanned the limit. (That is, if point A is considered close to
B, and B is considered close to C, but A is not close to C.) Such a
scheme seems like it could have a very high accuracy rate, fixing FP
precision problems without merging points that should be distinct.
But I suspect that it would also be quite expensive.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
There is an OpenSCAD issue about this:
https://github.com/openscad/openscad/issues/5135. I thought they WERE
going to make that an informational message rather than a warning. I
raised the point that it's basically impossible to reasonably use OpenSCAD
without setting stop on first warning because it just causes an error to
cascade into pages of garbage and hide the true problem.
If OpenSCAD is going to be picky then BOSL2 has to run vnf_merge_points()
to look for the duplicate points and combine them in the topology. You
can do this now if you want to make it work. We don't do this
automatically because we are nervous that it will be slow, though for the
above rounded_prism example it's not terrible on my machine, boosting
preview time from 0.08s to 0.3 s, so a factor of three slower, but still
fast enough. However, if you round all the edges preview time goes from
0.7s to 5s which is getting annoying. (I did this tests with a large
splinesteps value, so it doesn't need to be quite so bad.) So run time can
be a potential concern at least sometimes. Almost every interesting shape
BOSL2 creates is going to have duplicate non-exact points, so longer term
it raises questions about basically complicating things throughout BOSL2 to
track edges, for example, to reduce the points that need to be checked for
merges. Maybe if they ever introduce structures outside of textmetrics
this will seem more reasonable to do. (Note that the rounded square prism
is constructed from 26 bezier patches, one for each face, edge and corner
and I don't see a reasonable way to actually track the faces that meet from
different patches at the same edge to directly exploit the knowledge that
the patches share a boundary.)
On Fri, Oct 18, 2024 at 4:01 PM Todd Allen via Discuss <
discuss@lists.openscad.org> wrote:
If I recall correctly, openscad should try the CGAL way of repairing
meshes when manifold cannot import
the mesh, no idea why it doesn't work in this case.
I reported this incorrectly as an error which stopped rendering. But it
is only a warning. However I had the option set to stop at first warning.
Disabling that option allows this to successfully render.
If this sort of mesh issue is expected to be commonly corrected by the
automatic repair process perhaps it would be ok to downgrade this message
from WARNING to INFO and only after the repair fails issue a warning or let
it error out.
On Fri, Oct 18, 2024 at 12:45 PM Chun Kit LAM via Discuss <
discuss@lists.openscad.org> wrote:
Are you saying that vertexes shared between faces must use the same
indexes?
Both yes and no. If you mean vertices shared between triangles must use
the same indices, yes. But you can have vertices with the same
coordinate, so they can have different indices and are not shared by
triangles, despite triangles containing them can be touching
geometrically (if you consider coordinates).
The topological definition of manifoldness used in manifold is actually
very simple, see
https://github.com/elalish/manifold/wiki/Manifold-Library#manifoldness-definition
Every edge of every triangle must contain the same two vertices (by
index) as exactly one other triangle edge, and the start and end
vertices must switch places between these two edges. The triangle
vertices must appear in counter-clockwise order when viewed from the
outside of the manifold.
I think the issue is in the polyhedron triangle list not being manifold.
E.g. there may be a tiny open hole in the mesh, but merging vertices
close to each other may make the hole disappear because all vertices
around the hole are merged into one. If I recall correctly, openscad
should try the CGAL way of repairing meshes when manifold cannot import
the mesh, no idea why it doesn't work in this case.
On 19/10/2024 01:24, Jordan Brown wrote:
On 10/18/2024 9:52 AM, Chun Kit LAM via Discuss wrote:
But manifold doesn't really care about coordinates when checking for
manifoldness, it just cares about vertex indices in the list of
triangles. Previously, openscad would snap vertices to a grid and
merge identical vertices, but that can lose manifoldness in general
and it is really hard to fix, so it is no longer doing that when the
mesh PolySet can directly be imported into manifold.
Are you saying that vertexes shared between faces must use the same
indexes? Experiments indicate that there's no such requirement. I
constructed a cube out of 24 vertexes, and Manifold seemed perfectly
happy with it. Correcting the 2e-16 values in the rounded prism to
zero, without eliminating the duplication, made the problem go away.
I'm not really a fan of the grid-snap scheme; it causes problems on
its own. Getting rid of it might be a win, but will likely cause
problems like this one. (But I admit I have no experience with not
using it.) I'd like to think that we could have a scheme that snapped
together "clusters" of points that are very close to one another (say,
a difference of less than one part in 10^14), and gave up if a cluster
ever spanned the limit. (That is, if point A is considered close to
B, and B is considered close to C, but A is not close to C.) Such a
scheme seems like it could have a very high accuracy rate, fixing FP
precision problems without merging points that should be distinct.
But I suspect that it would also be quite expensive.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
On 10/18/2024 1:38 PM, Adrian Mariano via Discuss wrote:
If OpenSCAD is going to be picky then BOSL2 has to run
vnf_merge_points() to look for the duplicate points and combine them
in the topology.
If there's a practical requirement to merge nearby points, it should
certainly be implemented in C++ rather than in OpenSCAD-language.
But maybe it could be done only on general polyhedra - polyhedron(),
import(), maybe polygon() and the extrudes - rather than later in the
pipeline. We can "just know" that internally-constructed shapes (cubes,
spheres, et cetera) are "safe", so wouldn't need to process them.
There are two issues here:
- openscad userspace computation is slow.
- warning levels
For 1, there are ways to improve this situation, but it will take quite
a bit of effort and I don't have too much time to pull it off now.
Basically just make the interpretation using bytecode and skip all the
expensive hashtable lookup for each variable/function argument, as well
as AST traversal. It is not hard, but it is quite tedious to rewrite
everything and make sure the behavior is compatible.
For warning levels, IMO fixing non-manifold geometry is probably common
enough that it can be regarded as a debug level info.
On 19/10/2024 04:38, Adrian Mariano via Discuss wrote:
There is an OpenSCAD issue about this:
https://github.com/openscad/openscad/issues/5135. I thought they WERE
going to make that an informational message rather than a warning. I
raised the point that it's basically impossible to reasonably use
OpenSCAD without setting stop on first warning because it just causes
an error to cascade into pages of garbage and hide the true problem.
If OpenSCAD is going to be picky then BOSL2 has to run
vnf_merge_points() to look for the duplicate points and combine them
in the topology. You can do this now if you want to make it work.
We don't do this automatically because we are nervous that it will be
slow, though for the above rounded_prism example it's not terrible on
my machine, boosting preview time from 0.08s to 0.3 s, so a factor of
three slower, but still fast enough. However, if you round all the
edges preview time goes from 0.7s to 5s which is getting annoying. (I
did this tests with a large splinesteps value, so it doesn't need to
be quite so bad.) So run time can be a potential concern at least
sometimes. Almost every interesting shape BOSL2 creates is going to
have duplicate non-exact points, so longer term it raises questions
about basically complicating things throughout BOSL2 to track edges,
for example, to reduce the points that need to be checked for merges.
Maybe if they ever introduce structures outside of textmetrics this
will seem more reasonable to do. (Note that the rounded square prism
is constructed from 26 bezier patches, one for each face, edge and
corner and I don't see a reasonable way to actually track the faces
that meet from different patches at the same edge to directly exploit
the knowledge that the patches share a boundary.)
On Fri, Oct 18, 2024 at 4:01 PM Todd Allen via Discuss
discuss@lists.openscad.org wrote:
If I recall correctly, openscad should try the CGAL way of
repairing meshes when manifold cannot import
the mesh, no idea why it doesn't work in this case.
I reported this incorrectly as an error which stopped rendering.
But it is only a warning. However I had the option set to stop at
first warning. Disabling that option allows this to successfully
render.
If this sort of mesh issue is expected to be commonly corrected by
the automatic repair process perhaps it would be ok to downgrade
this message from WARNING to INFO and only after the repair fails
issue a warning or let it error out.
On Fri, Oct 18, 2024 at 12:45 PM Chun Kit LAM via Discuss
<discuss@lists.openscad.org> wrote:
> Are you saying that vertexes shared between faces must use
the same
indexes?
Both yes and no. If you mean vertices shared between triangles
must use
the same indices, yes. But you can have vertices with the same
coordinate, so they can have different indices and are not
shared by
triangles, despite triangles containing them can be touching
geometrically (if you consider coordinates).
The topological definition of manifoldness used in manifold is
actually
very simple, see
https://github.com/elalish/manifold/wiki/Manifold-Library#manifoldness-definition
> Every edge of every triangle must contain the same two
vertices (by
index) as exactly one other triangle edge, and the start and end
vertices must switch places between these two edges. The triangle
vertices must appear in counter-clockwise order when viewed
from the
outside of the manifold.
I think the issue is in the polyhedron triangle list not being
manifold.
E.g. there may be a tiny open hole in the mesh, but merging
vertices
close to each other may make the hole disappear because all
vertices
around the hole are merged into one. If I recall correctly,
openscad
should try the CGAL way of repairing meshes when manifold
cannot import
the mesh, no idea why it doesn't work in this case.
On 19/10/2024 01:24, Jordan Brown wrote:
On 10/18/2024 9:52 AM, Chun Kit LAM via Discuss wrote:
But manifold doesn't really care about coordinates when
checking for
manifoldness, it just cares about vertex indices in the
list of
triangles. Previously, openscad would snap vertices to a
grid and
merge identical vertices, but that can lose manifoldness in
general
and it is really hard to fix, so it is no longer doing that
when the
mesh PolySet can directly be imported into manifold.
Are you saying that vertexes shared between faces must use
the same
indexes? Experiments indicate that there's no such
requirement. I
constructed a cube out of 24 vertexes, and Manifold seemed
perfectly
happy with it. Correcting the 2e-16 values in the rounded
prism to
zero, without eliminating the duplication, made the problem
go away.
I'm not really a fan of the grid-snap scheme; it causes
problems on
its own. Getting rid of it might be a win, but will likely
cause
problems like this one. (But I admit I have no experience
with *not*
using it.) I'd like to think that we could have a scheme
that snapped
together "clusters" of points that are very close to one
another (say,
a difference of less than one part in 10^14), and gave up if
a cluster
ever spanned the limit. (That is, if point A is considered
close to
B, and B is considered close to C, but A is not close to
C.) Such a
scheme seems like it could have a very high accuracy rate,
fixing FP
precision problems without merging points that should be
distinct.
But I suspect that it would also be quite expensive.
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email todiscuss-leave@lists.openscad.org