TR
Thomas Richter
Sun, Jan 12, 2025 8:08 AM
I create concave polyhedra of several thousand faces. For details about the purpose see https://lists.openscad.org/empathy/thread/LY26O7U4CLHPW3BGQIDLSAE6FRVVHEUG
My question is not about building the shape, that's solved, but about a strange error I experience with certain input values. An example causing the error can be found on Github:
https://github.com/trses/screw-nut-knobs/blob/boolean-glitch/analytical-solution.scad
When I render the shape I get this error:
WARNING: PolySet -> Manifold conversion failed: NotManifold
Trying to repair and reconstruct mesh..
ERROR: [manifold] Input mesh is not closed!
ERROR: [manifold] Surface_mesh -> Manifold conversion failed: NotManifold
This happens in very rare situations (e. g.: ARMS = 13, 1.97 <= _armPitch <= 2.17, _q = 182, _q = 208 and ARMS = 17, 1.93 <= _armPitch <= 2.18, _q = 204). Since the values are similar I believe there is a geometrical reason but I have no idea how I could debug this and figure out the actual cause.
If you comment out line 163 (subtract hollow sphere) it doesn't happen (though the shape will look strange then). The polyhedron itself is built correctly, I have checked it several times by hand.
My platform is an Apple Silicon M3 CPU.
I would like to know if others experience the same behavior (on other platforms) with the example provided and if so, what is the cause or at least what could I do to debug it. My impression is that it happens when the shape to subtract from is complex and very tiny faces are generated. Unfortunately, the error message is not very helpful.
Is this an already known glitch?
Second question related to this: In case this is a shortcoming of the rendering engine: Is there any chance to catch this error by means of the source code and handle it by, e. g., adjusting the _armPitch value?
If this question is assumed to be spam, please let me know how I should have brought this problem up. I have already asked the question in one of the last messages of the other thread but it seems that it got lost there.
I create concave polyhedra of several thousand faces. For details about the purpose see https://lists.openscad.org/empathy/thread/LY26O7U4CLHPW3BGQIDLSAE6FRVVHEUG
My question is not about building the shape, that's solved, but about a strange error I experience with certain input values. An example causing the error can be found on Github:
https://github.com/trses/screw-nut-knobs/blob/boolean-glitch/analytical-solution.scad
When I render the shape I get this error:
WARNING: PolySet -> Manifold conversion failed: NotManifold
Trying to repair and reconstruct mesh..
ERROR: [manifold] Input mesh is not closed!
ERROR: [manifold] Surface_mesh -> Manifold conversion failed: NotManifold
This happens in very rare situations (e. g.: ARMS = 13, 1.97 <= _armPitch <= 2.17, _q = 182, _q = 208 and ARMS = 17, 1.93 <= _armPitch <= 2.18, _q = 204). Since the values are similar I believe there is a geometrical reason but I have no idea how I could debug this and figure out the actual cause.
If you comment out line 163 (subtract hollow sphere) it doesn't happen (though the shape will look strange then). The polyhedron itself is built correctly, I have checked it several times by hand.
My platform is an Apple Silicon M3 CPU.
I would like to know if others experience the same behavior (on other platforms) with the example provided and if so, what is the cause or at least what could I do to debug it. My impression is that it happens when the shape to subtract from is complex and very tiny faces are generated. Unfortunately, the error message is not very helpful.
Is this an already known glitch?
Second question related to this: In case this is a shortcoming of the rendering engine: Is there any chance to catch this error by means of the source code and handle it by, e. g., adjusting the _armPitch value?
If this question is assumed to be spam, please let me know how I should have brought this problem up. I have already asked the question in one of the last messages of the other thread but it seems that it got lost there.
JB
Jordan Brown
Sun, Jan 12, 2025 3:53 PM
First, try replacing the difference-with-a-sphere with a union with a cube(), placing the cube away from the model. It’s very likely that the problem is with the polyhedron or how it’s handled, and is being reported when we try to get ready for a more complex operation, so let’s make the rest of the problem as simple as possible.
Look at the polyhedron using View/Thrown Together, looking for any hint, no matter how small, of purple.
Look at the design of your polyhedron. Are there any cases where you expect two points that are calculated independently to be the “same” point? Ideally, every point in the points array is distinct.
Other people know of automated polyhedron checkers, but I don’t.
First, try replacing the difference-with-a-sphere with a union with a cube(), placing the cube away from the model. It’s very likely that the problem is with the polyhedron or how it’s handled, and is being reported when we try to get ready for a more complex operation, so let’s make the rest of the problem as simple as possible.
Look at the polyhedron using View/Thrown Together, looking for any hint, no matter how small, of purple.
Look at the design of your polyhedron. Are there any cases where you expect two points that are calculated independently to be the “same” point? Ideally, every point in the points array is distinct.
Other people know of automated polyhedron checkers, but I don’t.
AM
Adrian Mariano
Sun, Jan 12, 2025 4:02 PM
Jordan, I tried replacing the difference with a union with a cube and the
problem goes away. BOSL2 has an automated checker but it may run all day
on a polyhedron that big. I can try it and see.
On Sun, Jan 12, 2025 at 10:54 AM Jordan Brown via Discuss <
discuss@lists.openscad.org> wrote:
First, try replacing the difference-with-a-sphere with a union with a
cube(), placing the cube away from the model. It’s very likely that the
problem is with the polyhedron or how it’s handled, and is being reported
when we try to get ready for a more complex operation, so let’s make the
rest of the problem as simple as possible.
Look at the polyhedron using View/Thrown Together, looking for any hint,
no matter how small, of purple.
Look at the design of your polyhedron. Are there any cases where you
expect two points that are calculated independently to be the “same” point?
Ideally, every point in the points array is distinct.
Other people know of automated polyhedron checkers, but I don’t.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Jordan, I tried replacing the difference with a union with a cube and the
problem goes away. BOSL2 has an automated checker but it may run all day
on a polyhedron that big. I can try it and see.
On Sun, Jan 12, 2025 at 10:54 AM Jordan Brown via Discuss <
discuss@lists.openscad.org> wrote:
> First, try replacing the difference-with-a-sphere with a union with a
> cube(), placing the cube away from the model. It’s very likely that the
> problem is with the polyhedron or how it’s handled, and is being reported
> when we try to get ready for a more complex operation, so let’s make the
> rest of the problem as simple as possible.
>
> Look at the polyhedron using View/Thrown Together, looking for any hint,
> no matter how small, of purple.
>
> Look at the design of your polyhedron. Are there any cases where you
> expect two points that are calculated independently to be the “same” point?
> Ideally, every point in the points array is distinct.
>
> Other people know of automated polyhedron checkers, but I don’t.
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
RW
Raymond West
Sun, Jan 12, 2025 4:09 PM
It would help if you posted an image of what you're trying to create,
and possibly some code. I can't help if you are trying to use bos2l or
you refer to github/elsewhere.
I find in f5 render, a lot of my stuff breaks up. However, in manifold
rendering f6, generally works. You can check, as Jordan hinted, by
including a cube when you f6, do it as the object is evolved. If you get
just a cube, then you know where you've screwed up.
On 12/01/2025 08:08, Thomas Richter via Discuss wrote:
I create concave polyhedra of several thousand faces. For details about the purpose see https://lists.openscad.org/empathy/thread/LY26O7U4CLHPW3BGQIDLSAE6FRVVHEUG
My question is not about building the shape, that's solved, but about a strange error I experience with certain input values. An example causing the error can be found on Github:
https://github.com/trses/screw-nut-knobs/blob/boolean-glitch/analytical-solution.scad
When I render the shape I get this error:
WARNING: PolySet -> Manifold conversion failed: NotManifold
Trying to repair and reconstruct mesh..
ERROR: [manifold] Input mesh is not closed!
ERROR: [manifold] Surface_mesh -> Manifold conversion failed: NotManifold
This happens in very rare situations (e. g.: ARMS = 13, 1.97 <= _armPitch <= 2.17, _q = 182, _q = 208 and ARMS = 17, 1.93 <= _armPitch <= 2.18, _q = 204). Since the values are similar I believe there is a geometrical reason but I have no idea how I could debug this and figure out the actual cause.
If you comment out line 163 (subtract hollow sphere) it doesn't happen (though the shape will look strange then). The polyhedron itself is built correctly, I have checked it several times by hand.
My platform is an Apple Silicon M3 CPU.
I would like to know if others experience the same behavior (on other platforms) with the example provided and if so, what is the cause or at least what could I do to debug it. My impression is that it happens when the shape to subtract from is complex and very tiny faces are generated. Unfortunately, the error message is not very helpful.
Is this an already known glitch?
Second question related to this: In case this is a shortcoming of the rendering engine: Is there any chance to catch this error by means of the source code and handle it by, e. g., adjusting the _armPitch value?
If this question is assumed to be spam, please let me know how I should have brought this problem up. I have already asked the question in one of the last messages of the other thread but it seems that it got lost there.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
It would help if you posted an image of what you're trying to create,
and possibly some code. I can't help if you are trying to use bos2l or
you refer to github/elsewhere.
I find in f5 render, a lot of my stuff breaks up. However, in manifold
rendering f6, generally works. You can check, as Jordan hinted, by
including a cube when you f6, do it as the object is evolved. If you get
just a cube, then you know where you've screwed up.
On 12/01/2025 08:08, Thomas Richter via Discuss wrote:
> I create concave polyhedra of several thousand faces. For details about the purpose see https://lists.openscad.org/empathy/thread/LY26O7U4CLHPW3BGQIDLSAE6FRVVHEUG
>
> My question is not about building the shape, that's solved, but about a strange error I experience with certain input values. An example causing the error can be found on Github:
>
> https://github.com/trses/screw-nut-knobs/blob/boolean-glitch/analytical-solution.scad
>
> When I render the shape I get this error:
>
> WARNING: PolySet -> Manifold conversion failed: NotManifold
> Trying to repair and reconstruct mesh..
> ERROR: [manifold] Input mesh is not closed!
> ERROR: [manifold] Surface_mesh -> Manifold conversion failed: NotManifold
>
> This happens in very rare situations (e. g.: ARMS = 13, 1.97 <= _armPitch <= 2.17, _q = 182, _q = 208 and ARMS = 17, 1.93 <= _armPitch <= 2.18, _q = 204). Since the values are similar I believe there is a geometrical reason but I have no idea how I could debug this and figure out the actual cause.
>
> If you comment out line 163 (subtract hollow sphere) it doesn't happen (though the shape will look strange then). The polyhedron itself is built correctly, I have checked it several times by hand.
>
> My platform is an Apple Silicon M3 CPU.
>
> I would like to know if others experience the same behavior (on other platforms) with the example provided and if so, what is the cause or at least what could I do to debug it. My impression is that it happens when the shape to subtract from is complex and very tiny faces are generated. Unfortunately, the error message is not very helpful.
>
> Is this an already known glitch?
>
> Second question related to this: In case this is a shortcoming of the rendering engine: Is there any chance to catch this error by means of the source code and handle it by, e. g., adjusting the _armPitch value?
>
> If this question is assumed to be spam, please let me know how I should have brought this problem up. I have already asked the question in one of the last messages of the other thread but it seems that it got lost there.
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
AM
Adrian Mariano
Sun, Jan 12, 2025 4:41 PM
He did post (a link to) the full code.
Actually I got fooled when I viewed the shape with "thrown together". He
explicitly calls render() in his code, which bypasses the thrown-together
process. I actually figured this out because the BOSL2 polyhedron
validator produced a long list of errors like this:
ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[0.0319137,
-16.3794, 18.4927], [-0.932485, -16.0686, 18.6187]] indices: [3217, 3216]"
ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[0.949081,
-16.81, 18.2839], [0.0319137, -16.3794, 18.4927]] indices: [3218, 3217]"
ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[1.80419,
-17.3535, 17.9945], [0.949081, -16.81, 18.2839]] indices: [3219, 3218]"
ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[2.1411,
-17.6335, 17.8396], [1.80419, -17.3535, 17.9945]] indices: [3220, 3219]"
ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[2.4012,
-17.281, 17.9945], [2.1411, -17.6335, 17.8396]] indices: [3221, 3220]"
ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[3.10139,
-16.5486, 18.2839], [2.4012, -17.281, 17.9945]] indices: [3222, 3221]"
I am not sure why that render() call is there. It doesn't seem to do
anything other than preventing the user from using preview and hiding
errors. With render() removed, and thrown together enabled, the face
reversal is obvious as seen below. So the conclusion is: the polyhedron
has reversed faces, hence it is invalid.
[image: image.png]
On Sun, Jan 12, 2025 at 11:10 AM Raymond West via Discuss <
discuss@lists.openscad.org> wrote:
It would help if you posted an image of what you're trying to create,
and possibly some code. I can't help if you are trying to use bos2l or
you refer to github/elsewhere.
I find in f5 render, a lot of my stuff breaks up. However, in manifold
rendering f6, generally works. You can check, as Jordan hinted, by
including a cube when you f6, do it as the object is evolved. If you get
just a cube, then you know where you've screwed up.
On 12/01/2025 08:08, Thomas Richter via Discuss wrote:
I create concave polyhedra of several thousand faces. For details about
My question is not about building the shape, that's solved, but about a
strange error I experience with certain input values. An example causing
the error can be found on Github:
When I render the shape I get this error:
WARNING: PolySet -> Manifold conversion failed: NotManifold
Trying to repair and reconstruct mesh..
ERROR: [manifold] Input mesh is not closed!
ERROR: [manifold] Surface_mesh -> Manifold conversion failed: NotManifold
This happens in very rare situations (e. g.: ARMS = 13, 1.97 <=
_armPitch <= 2.17, _q = 182, _q = 208 and ARMS = 17, 1.93 <= _armPitch <=
2.18, _q = 204). Since the values are similar I believe there is a
geometrical reason but I have no idea how I could debug this and figure out
the actual cause.
If you comment out line 163 (subtract hollow sphere) it doesn't happen
(though the shape will look strange then). The polyhedron itself is built
correctly, I have checked it several times by hand.
My platform is an Apple Silicon M3 CPU.
I would like to know if others experience the same behavior (on other
platforms) with the example provided and if so, what is the cause or at
least what could I do to debug it. My impression is that it happens when
the shape to subtract from is complex and very tiny faces are generated.
Unfortunately, the error message is not very helpful.
Is this an already known glitch?
Second question related to this: In case this is a shortcoming of the
rendering engine: Is there any chance to catch this error by means of the
source code and handle it by, e. g., adjusting the _armPitch value?
If this question is assumed to be spam, please let me know how I should
have brought this problem up. I have already asked the question in one of
the last messages of the other thread but it seems that it got lost there.
He did post (a link to) the full code.
Actually I got fooled when I viewed the shape with "thrown together". He
explicitly calls render() in his code, which bypasses the thrown-together
process. I actually figured this out because the BOSL2 polyhedron
validator produced a long list of errors like this:
ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[0.0319137,
-16.3794, 18.4927], [-0.932485, -16.0686, 18.6187]] indices: [3217, 3216]"
ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[0.949081,
-16.81, 18.2839], [0.0319137, -16.3794, 18.4927]] indices: [3218, 3217]"
ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[1.80419,
-17.3535, 17.9945], [0.949081, -16.81, 18.2839]] indices: [3219, 3218]"
ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[2.1411,
-17.6335, 17.8396], [1.80419, -17.3535, 17.9945]] indices: [3220, 3219]"
ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[2.4012,
-17.281, 17.9945], [2.1411, -17.6335, 17.8396]] indices: [3221, 3220]"
ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[3.10139,
-16.5486, 18.2839], [2.4012, -17.281, 17.9945]] indices: [3222, 3221]"
I am not sure why that render() call is there. It doesn't seem to do
anything other than preventing the user from using preview and hiding
errors. With render() removed, and thrown together enabled, the face
reversal is obvious as seen below. So the conclusion is: the polyhedron
has reversed faces, hence it is invalid.
[image: image.png]
On Sun, Jan 12, 2025 at 11:10 AM Raymond West via Discuss <
discuss@lists.openscad.org> wrote:
> It would help if you posted an image of what you're trying to create,
> and possibly some code. I can't help if you are trying to use bos2l or
> you refer to github/elsewhere.
>
> I find in f5 render, a lot of my stuff breaks up. However, in manifold
> rendering f6, generally works. You can check, as Jordan hinted, by
> including a cube when you f6, do it as the object is evolved. If you get
> just a cube, then you know where you've screwed up.
>
> On 12/01/2025 08:08, Thomas Richter via Discuss wrote:
> > I create concave polyhedra of several thousand faces. For details about
> the purpose see
> https://lists.openscad.org/empathy/thread/LY26O7U4CLHPW3BGQIDLSAE6FRVVHEUG
> >
> > My question is not about building the shape, that's solved, but about a
> strange error I experience with certain input values. An example causing
> the error can be found on Github:
> >
> >
> https://github.com/trses/screw-nut-knobs/blob/boolean-glitch/analytical-solution.scad
> >
> > When I render the shape I get this error:
> >
> > WARNING: PolySet -> Manifold conversion failed: NotManifold
> > Trying to repair and reconstruct mesh..
> > ERROR: [manifold] Input mesh is not closed!
> > ERROR: [manifold] Surface_mesh -> Manifold conversion failed: NotManifold
> >
> > This happens in very rare situations (e. g.: ARMS = 13, 1.97 <=
> _armPitch <= 2.17, _q = 182, _q = 208 and ARMS = 17, 1.93 <= _armPitch <=
> 2.18, _q = 204). Since the values are similar I believe there is a
> geometrical reason but I have no idea how I could debug this and figure out
> the actual cause.
> >
> > If you comment out line 163 (subtract hollow sphere) it doesn't happen
> (though the shape will look strange then). The polyhedron itself is built
> correctly, I have checked it several times by hand.
> >
> > My platform is an Apple Silicon M3 CPU.
> >
> > I would like to know if others experience the same behavior (on other
> platforms) with the example provided and if so, what is the cause or at
> least what could I do to debug it. My impression is that it happens when
> the shape to subtract from is complex and very tiny faces are generated.
> Unfortunately, the error message is not very helpful.
> >
> > Is this an already known glitch?
> >
> > Second question related to this: In case this is a shortcoming of the
> rendering engine: Is there any chance to catch this error by means of the
> source code and handle it by, e. g., adjusting the _armPitch value?
> >
> > If this question is assumed to be spam, please let me know how I should
> have brought this problem up. I have already asked the question in one of
> the last messages of the other thread but it seems that it got lost there.
> > _______________________________________________
> > 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
>
RW
Raymond West
Sun, Jan 12, 2025 6:17 PM
Hi, I never followed the link, I'm not sure if the image is what was
wanted, but not difficult to create, or something like. I guess the
roundover could be smaller, but it's all parametric anyway.
code attached below. No rendering problems. similar to a post a few days
ago.
on 12/01/2025 16:41, Adrian Mariano via Discuss wrote:
He did post (a link to) the full code.
Actually I got fooled when I viewed the shape with "thrown together".
He explicitly calls render() in his code, which bypasses the
thrown-together process. I actually figured this out because the
BOSL2 polyhedron validator produced a long list of errors like this:
ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at
[[0.0319137, -16.3794, 18.4927], [-0.932485, -16.0686, 18.6187]]
indices: [3217, 3216]"
ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at
[[0.949081, -16.81, 18.2839], [0.0319137, -16.3794, 18.4927]] indices:
[3218, 3217]"
ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at
[[1.80419, -17.3535, 17.9945], [0.949081, -16.81, 18.2839]] indices:
[3219, 3218]"
ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[2.1411,
-17.6335, 17.8396], [1.80419, -17.3535, 17.9945]] indices: [3220, 3219]"
ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[2.4012,
-17.281, 17.9945], [2.1411, -17.6335, 17.8396]] indices: [3221, 3220]"
ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at
[[3.10139, -16.5486, 18.2839], [2.4012, -17.281, 17.9945]] indices:
[3222, 3221]"
I am not sure why that render() call is there. It doesn't seem to do
anything other than preventing the user from using preview and hiding
errors. With render() removed, and thrown together enabled, the face
reversal is obvious as seen below. So the conclusion is: the
polyhedron has reversed faces, hence it is invalid.
image.png
On Sun, Jan 12, 2025 at 11:10 AM Raymond West via Discuss
discuss@lists.openscad.org wrote:
It would help if you posted an image of what you're trying to create,
and possibly some code. I can't help if you are trying to use
bos2l or
you refer to github/elsewhere.
I find in f5 render, a lot of my stuff breaks up. However, in
manifold
rendering f6, generally works. You can check, as Jordan hinted, by
including a cube when you f6, do it as the object is evolved. If
you get
just a cube, then you know where you've screwed up.
On 12/01/2025 08:08, Thomas Richter via Discuss wrote:
I create concave polyhedra of several thousand faces. For
details about the purpose see
https://lists.openscad.org/empathy/thread/LY26O7U4CLHPW3BGQIDLSAE6FRVVHEUG
My question is not about building the shape, that's solved, but
about a strange error I experience with certain input values. An
example causing the error can be found on Github:
https://github.com/trses/screw-nut-knobs/blob/boolean-glitch/analytical-solution.scad
When I render the shape I get this error:
WARNING: PolySet -> Manifold conversion failed: NotManifold
Trying to repair and reconstruct mesh..
ERROR: [manifold] Input mesh is not closed!
ERROR: [manifold] Surface_mesh -> Manifold conversion failed:
This happens in very rare situations (e. g.: ARMS = 13, 1.97 <=
_armPitch <= 2.17, _q = 182, _q = 208 and ARMS = 17, 1.93 <=
_armPitch <= 2.18, _q = 204). Since the values are similar I
believe there is a geometrical reason but I have no idea how I
could debug this and figure out the actual cause.
If you comment out line 163 (subtract hollow sphere) it doesn't
happen (though the shape will look strange then). The polyhedron
itself is built correctly, I have checked it several times by hand.
My platform is an Apple Silicon M3 CPU.
I would like to know if others experience the same behavior (on
other platforms) with the example provided and if so, what is the
cause or at least what could I do to debug it. My impression is
that it happens when the shape to subtract from is complex and
very tiny faces are generated. Unfortunately, the error message is
not very helpful.
Is this an already known glitch?
Second question related to this: In case this is a shortcoming
of the rendering engine: Is there any chance to catch this error
by means of the source code and handle it by, e. g., adjusting the
_armPitch value?
If this question is assumed to be spam, please let me know how I
should have brought this problem up. I have already asked the
question in one of the last messages of the other thread but it
seems that it got lost there.
_______________________________________________
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
Hi, I never followed the link, I'm not sure if the image is what was
wanted, but not difficult to create, or something like. I guess the
roundover could be smaller, but it's all parametric anyway.
code attached below. No rendering problems. similar to a post a few days
ago.
on 12/01/2025 16:41, Adrian Mariano via Discuss wrote:
> He did post (a link to) the full code.
>
> Actually I got fooled when I viewed the shape with "thrown together".
> He explicitly calls render() in his code, which bypasses the
> thrown-together process. I actually figured this out because the
> BOSL2 polyhedron validator produced a long list of errors like this:
>
> ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at
> [[0.0319137, -16.3794, 18.4927], [-0.932485, -16.0686, 18.6187]]
> indices: [3217, 3216]"
> ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at
> [[0.949081, -16.81, 18.2839], [0.0319137, -16.3794, 18.4927]] indices:
> [3218, 3217]"
> ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at
> [[1.80419, -17.3535, 17.9945], [0.949081, -16.81, 18.2839]] indices:
> [3219, 3218]"
> ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[2.1411,
> -17.6335, 17.8396], [1.80419, -17.3535, 17.9945]] indices: [3220, 3219]"
> ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[2.4012,
> -17.281, 17.9945], [2.1411, -17.6335, 17.8396]] indices: [3221, 3220]"
> ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at
> [[3.10139, -16.5486, 18.2839], [2.4012, -17.281, 17.9945]] indices:
> [3222, 3221]"
>
> I am not sure why that render() call is there. It doesn't seem to do
> anything other than preventing the user from using preview and hiding
> errors. With render() removed, and thrown together enabled, the face
> reversal is obvious as seen below. So the conclusion is: the
> polyhedron has reversed faces, hence it is invalid.
>
>
> image.png
>
>
>
>
>
> On Sun, Jan 12, 2025 at 11:10 AM Raymond West via Discuss
> <discuss@lists.openscad.org> wrote:
>
> It would help if you posted an image of what you're trying to create,
> and possibly some code. I can't help if you are trying to use
> bos2l or
> you refer to github/elsewhere.
>
> I find in f5 render, a lot of my stuff breaks up. However, in
> manifold
> rendering f6, generally works. You can check, as Jordan hinted, by
> including a cube when you f6, do it as the object is evolved. If
> you get
> just a cube, then you know where you've screwed up.
>
> On 12/01/2025 08:08, Thomas Richter via Discuss wrote:
> > I create concave polyhedra of several thousand faces. For
> details about the purpose see
> https://lists.openscad.org/empathy/thread/LY26O7U4CLHPW3BGQIDLSAE6FRVVHEUG
> >
> > My question is not about building the shape, that's solved, but
> about a strange error I experience with certain input values. An
> example causing the error can be found on Github:
> >
> >
> https://github.com/trses/screw-nut-knobs/blob/boolean-glitch/analytical-solution.scad
> >
> > When I render the shape I get this error:
> >
> > WARNING: PolySet -> Manifold conversion failed: NotManifold
> > Trying to repair and reconstruct mesh..
> > ERROR: [manifold] Input mesh is not closed!
> > ERROR: [manifold] Surface_mesh -> Manifold conversion failed:
> NotManifold
> >
> > This happens in very rare situations (e. g.: ARMS = 13, 1.97 <=
> _armPitch <= 2.17, _q = 182, _q = 208 and ARMS = 17, 1.93 <=
> _armPitch <= 2.18, _q = 204). Since the values are similar I
> believe there is a geometrical reason but I have no idea how I
> could debug this and figure out the actual cause.
> >
> > If you comment out line 163 (subtract hollow sphere) it doesn't
> happen (though the shape will look strange then). The polyhedron
> itself is built correctly, I have checked it several times by hand.
> >
> > My platform is an Apple Silicon M3 CPU.
> >
> > I would like to know if others experience the same behavior (on
> other platforms) with the example provided and if so, what is the
> cause or at least what could I do to debug it. My impression is
> that it happens when the shape to subtract from is complex and
> very tiny faces are generated. Unfortunately, the error message is
> not very helpful.
> >
> > Is this an already known glitch?
> >
> > Second question related to this: In case this is a shortcoming
> of the rendering engine: Is there any chance to catch this error
> by means of the source code and handle it by, e. g., adjusting the
> _armPitch value?
> >
> > If this question is assumed to be spam, please let me know how I
> should have brought this problem up. I have already asked the
> question in one of the last messages of the other thread but it
> seems that it got lost there.
> > _______________________________________________
> > 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
TR
Thomas Richter
Sun, Jan 12, 2025 6:48 PM
Thank you for this insight. I misunderstood the manual and oriented the side faces counterclockwise instead of clockwise. After fixing this the purple is all gone, the problem persists with boolean operations, goes away without boolean operations.
The render() was there because the misoriented side faces made the body appearing transparent. Unfortunately this didn't lead to any insight on my side :-(
I checked with a script that all points - copied from output with echo - are unique.
I have uploaded the version with the fixed faces:
https://github.com/trses/screw-nut-knobs/blob/boolean-glitch/analytical-solution.scad
I flushed the caches before every experiment and made the following observations when trying to render (not preview), see lines 167 - 179:
- difference with the polyhedron and a hollow sphere: problem persists
- union with the polyhedron and a cube someplace else: problem persists
- commenting out the difference / union rendering just the polyhedron: problem goes away.
What does this mean?
Am 12.01.2025 um 17:41 schrieb Adrian Mariano via Discuss discuss@lists.openscad.org:
He did post (a link to) the full code.
Actually I got fooled when I viewed the shape with "thrown together". He explicitly calls render() in his code, which bypasses the thrown-together process. I actually figured this out because the BOSL2 polyhedron validator produced a long list of errors like this:
ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[0.0319137, -16.3794, 18.4927], [-0.932485, -16.0686, 18.6187]] indices: [3217, 3216]"
ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[0.949081, -16.81, 18.2839], [0.0319137, -16.3794, 18.4927]] indices: [3218, 3217]"
ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[1.80419, -17.3535, 17.9945], [0.949081, -16.81, 18.2839]] indices: [3219, 3218]"
ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[2.1411, -17.6335, 17.8396], [1.80419, -17.3535, 17.9945]] indices: [3220, 3219]"
ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[2.4012, -17.281, 17.9945], [2.1411, -17.6335, 17.8396]] indices: [3221, 3220]"
ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[3.10139, -16.5486, 18.2839], [2.4012, -17.281, 17.9945]] indices: [3222, 3221]"
I am not sure why that render() call is there. It doesn't seem to do anything other than preventing the user from using preview and hiding errors. With render() removed, and thrown together enabled, the face reversal is obvious as seen below. So the conclusion is: the polyhedron has reversed faces, hence it is invalid.
<image.png>
On Sun, Jan 12, 2025 at 11:10 AM Raymond West via Discuss discuss@lists.openscad.org wrote:
It would help if you posted an image of what you're trying to create,
and possibly some code. I can't help if you are trying to use bos2l or
you refer to github/elsewhere.
I find in f5 render, a lot of my stuff breaks up. However, in manifold
rendering f6, generally works. You can check, as Jordan hinted, by
including a cube when you f6, do it as the object is evolved. If you get
just a cube, then you know where you've screwed up.
On 12/01/2025 08:08, Thomas Richter via Discuss wrote:
I create concave polyhedra of several thousand faces. For details about the purpose see https://lists.openscad.org/empathy/thread/LY26O7U4CLHPW3BGQIDLSAE6FRVVHEUG
My question is not about building the shape, that's solved, but about a strange error I experience with certain input values. An example causing the error can be found on Github:
https://github.com/trses/screw-nut-knobs/blob/boolean-glitch/analytical-solution.scad
When I render the shape I get this error:
WARNING: PolySet -> Manifold conversion failed: NotManifold
Trying to repair and reconstruct mesh..
ERROR: [manifold] Input mesh is not closed!
ERROR: [manifold] Surface_mesh -> Manifold conversion failed: NotManifold
This happens in very rare situations (e. g.: ARMS = 13, 1.97 <= _armPitch <= 2.17, _q = 182, _q = 208 and ARMS = 17, 1.93 <= _armPitch <= 2.18, _q = 204). Since the values are similar I believe there is a geometrical reason but I have no idea how I could debug this and figure out the actual cause.
If you comment out line 163 (subtract hollow sphere) it doesn't happen (though the shape will look strange then). The polyhedron itself is built correctly, I have checked it several times by hand.
My platform is an Apple Silicon M3 CPU.
I would like to know if others experience the same behavior (on other platforms) with the example provided and if so, what is the cause or at least what could I do to debug it. My impression is that it happens when the shape to subtract from is complex and very tiny faces are generated. Unfortunately, the error message is not very helpful.
Is this an already known glitch?
Second question related to this: In case this is a shortcoming of the rendering engine: Is there any chance to catch this error by means of the source code and handle it by, e. g., adjusting the _armPitch value?
If this question is assumed to be spam, please let me know how I should have brought this problem up. I have already asked the question in one of the last messages of the other thread but it seems that it got lost there.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Thank you for this insight. I misunderstood the manual and oriented the side faces counterclockwise instead of clockwise. After fixing this the purple is all gone, the problem persists with boolean operations, goes away without boolean operations.
The render() was there because the misoriented side faces made the body appearing transparent. Unfortunately this didn't lead to any insight on my side :-(
I checked with a script that all points - copied from output with echo - are unique.
I have uploaded the version with the fixed faces:
https://github.com/trses/screw-nut-knobs/blob/boolean-glitch/analytical-solution.scad
I flushed the caches before every experiment and made the following observations when trying to render (not preview), see lines 167 - 179:
- difference with the polyhedron and a hollow sphere: problem persists
- union with the polyhedron and a cube someplace else: problem persists
- commenting out the difference / union rendering just the polyhedron: problem goes away.
What does this mean?
> Am 12.01.2025 um 17:41 schrieb Adrian Mariano via Discuss <discuss@lists.openscad.org>:
>
> He did post (a link to) the full code.
>
> Actually I got fooled when I viewed the shape with "thrown together". He explicitly calls render() in his code, which bypasses the thrown-together process. I actually figured this out because the BOSL2 polyhedron validator produced a long list of errors like this:
>
> ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[0.0319137, -16.3794, 18.4927], [-0.932485, -16.0686, 18.6187]] indices: [3217, 3216]"
> ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[0.949081, -16.81, 18.2839], [0.0319137, -16.3794, 18.4927]] indices: [3218, 3217]"
> ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[1.80419, -17.3535, 17.9945], [0.949081, -16.81, 18.2839]] indices: [3219, 3218]"
> ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[2.1411, -17.6335, 17.8396], [1.80419, -17.3535, 17.9945]] indices: [3220, 3219]"
> ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[2.4012, -17.281, 17.9945], [2.1411, -17.6335, 17.8396]] indices: [3221, 3220]"
> ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[3.10139, -16.5486, 18.2839], [2.4012, -17.281, 17.9945]] indices: [3222, 3221]"
>
> I am not sure why that render() call is there. It doesn't seem to do anything other than preventing the user from using preview and hiding errors. With render() removed, and thrown together enabled, the face reversal is obvious as seen below. So the conclusion is: the polyhedron has reversed faces, hence it is invalid.
>
>
> <image.png>
>
>
>
>
>
> On Sun, Jan 12, 2025 at 11:10 AM Raymond West via Discuss <discuss@lists.openscad.org> wrote:
> It would help if you posted an image of what you're trying to create,
> and possibly some code. I can't help if you are trying to use bos2l or
> you refer to github/elsewhere.
>
> I find in f5 render, a lot of my stuff breaks up. However, in manifold
> rendering f6, generally works. You can check, as Jordan hinted, by
> including a cube when you f6, do it as the object is evolved. If you get
> just a cube, then you know where you've screwed up.
>
> On 12/01/2025 08:08, Thomas Richter via Discuss wrote:
> > I create concave polyhedra of several thousand faces. For details about the purpose see https://lists.openscad.org/empathy/thread/LY26O7U4CLHPW3BGQIDLSAE6FRVVHEUG
> >
> > My question is not about building the shape, that's solved, but about a strange error I experience with certain input values. An example causing the error can be found on Github:
> >
> > https://github.com/trses/screw-nut-knobs/blob/boolean-glitch/analytical-solution.scad
> >
> > When I render the shape I get this error:
> >
> > WARNING: PolySet -> Manifold conversion failed: NotManifold
> > Trying to repair and reconstruct mesh..
> > ERROR: [manifold] Input mesh is not closed!
> > ERROR: [manifold] Surface_mesh -> Manifold conversion failed: NotManifold
> >
> > This happens in very rare situations (e. g.: ARMS = 13, 1.97 <= _armPitch <= 2.17, _q = 182, _q = 208 and ARMS = 17, 1.93 <= _armPitch <= 2.18, _q = 204). Since the values are similar I believe there is a geometrical reason but I have no idea how I could debug this and figure out the actual cause.
> >
> > If you comment out line 163 (subtract hollow sphere) it doesn't happen (though the shape will look strange then). The polyhedron itself is built correctly, I have checked it several times by hand.
> >
> > My platform is an Apple Silicon M3 CPU.
> >
> > I would like to know if others experience the same behavior (on other platforms) with the example provided and if so, what is the cause or at least what could I do to debug it. My impression is that it happens when the shape to subtract from is complex and very tiny faces are generated. Unfortunately, the error message is not very helpful.
> >
> > Is this an already known glitch?
> >
> > Second question related to this: In case this is a shortcoming of the rendering engine: Is there any chance to catch this error by means of the source code and handle it by, e. g., adjusting the _armPitch value?
> >
> > If this question is assumed to be spam, please let me know how I should have brought this problem up. I have already asked the question in one of the last messages of the other thread but it seems that it got lost there.
> > _______________________________________________
> > 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 to discuss-leave@lists.openscad.org
RW
Raymond West
Sun, Jan 12, 2025 7:16 PM
On 12/01/2025 18:48, Thomas Richter via Discuss wrote:
difference with the polyhedron and a hollow sphere: problem persists
- union with the polyhedron and a cube someplace else: problem persists
- commenting out the difference / union rendering just the polyhedron: problem goes away.
Create another copy of your 'working' polyhedra, so you have two on the
screen. You will probably get none! If you are 3d printing, the slicer
may say it is not watertight. If you understand MeshLab, that may help -
it's useful for reducing the number of facets. However, there is a
problem still with the polyhedra you have created, in that case, (In
language I understand ), it does not know which points should connect to
others, in union or difference. If it is that sort of scalloped knob you
are concerned with, look at it to build it from shapes you know work, at
the simplest level (even then you can get problems) so, build stuff from
squares/circles, mostly extrude works, as does rotate, translate and
scale, the basic stuff. No need to use bosl2, whatever. Minkowski is
slow, but render at $fn=50, say, to see if it is OK, then go for 150, or
100.
However, it is possible to fail in trying to difference two cylinders at
slight angles, But don't ask me to replicate it sod's law is paramount..
On 12/01/2025 18:48, Thomas Richter via Discuss wrote:
> difference with the polyhedron and a hollow sphere: problem persists
> - union with the polyhedron and a cube someplace else: problem persists
> - commenting out the difference / union rendering just the polyhedron: problem goes away.
Create another copy of your 'working' polyhedra, so you have two on the
screen. You will probably get none! If you are 3d printing, the slicer
may say it is not watertight. If you understand MeshLab, that may help -
it's useful for reducing the number of facets. However, there is a
problem still with the polyhedra you have created, in that case, (In
language I understand ), it does not know which points should connect to
others, in union or difference. If it is that sort of scalloped knob you
are concerned with, look at it to build it from shapes you know work, at
the simplest level (even then you can get problems) so, build stuff from
squares/circles, mostly extrude works, as does rotate, translate and
scale, the basic stuff. No need to use bosl2, whatever. Minkowski is
slow, but render at $fn=50, say, to see if it is OK, then go for 150, or
100.
However, it is possible to fail in trying to difference two cylinders at
slight angles, But don't ask me to replicate it sod's law is paramount..
AM
Adrian Mariano
Sun, Jan 12, 2025 7:29 PM
A polyhedron by itself never produces an error, even if it is invalid. If
it fails when you union with a cube then that means your polyhedron is
somehow invalid.
On Sun, Jan 12, 2025 at 1:49 PM Thomas Richter via Discuss <
discuss@lists.openscad.org> wrote:
Thank you for this insight. I misunderstood the manual and oriented the
side faces counterclockwise instead of clockwise. After fixing this the
purple is all gone, the problem persists with boolean operations, goes away
without boolean operations.
The render() was there because the misoriented side faces made the body
appearing transparent. Unfortunately this didn't lead to any insight on my
side :-(
I checked with a script that all points - copied from output with echo -
are unique.
I have uploaded the version with the fixed faces:
https://github.com/trses/screw-nut-knobs/blob/boolean-glitch/analytical-solution.scad
I flushed the caches before every experiment and made the following
observations when trying to render (not preview), see lines 167 - 179:
- difference with the polyhedron and a hollow sphere: problem persists
- union with the polyhedron and a cube someplace else: problem persists
- commenting out the difference / union rendering just the polyhedron:
problem goes away.
What does this mean?
Am 12.01.2025 um 17:41 schrieb Adrian Mariano via Discuss <
He did post (a link to) the full code.
Actually I got fooled when I viewed the shape with "thrown together".
He explicitly calls render() in his code, which bypasses the
thrown-together process. I actually figured this out because the BOSL2
polyhedron validator produced a long list of errors like this:
ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at
[[0.0319137, -16.3794, 18.4927], [-0.932485, -16.0686, 18.6187]] indices:
[3217, 3216]"
ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[0.949081,
-16.81, 18.2839], [0.0319137, -16.3794, 18.4927]] indices: [3218, 3217]"
ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[1.80419,
-17.3535, 17.9945], [0.949081, -16.81, 18.2839]] indices: [3219, 3218]"
ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[2.1411,
-17.6335, 17.8396], [1.80419, -17.3535, 17.9945]] indices: [3220, 3219]"
ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[2.4012,
-17.281, 17.9945], [2.1411, -17.6335, 17.8396]] indices: [3221, 3220]"
ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[3.10139,
-16.5486, 18.2839], [2.4012, -17.281, 17.9945]] indices: [3222, 3221]"
I am not sure why that render() call is there. It doesn't seem to do
anything other than preventing the user from using preview and hiding
errors. With render() removed, and thrown together enabled, the face
reversal is obvious as seen below. So the conclusion is: the polyhedron
has reversed faces, hence it is invalid.
<image.png>
On Sun, Jan 12, 2025 at 11:10 AM Raymond West via Discuss <
It would help if you posted an image of what you're trying to create,
and possibly some code. I can't help if you are trying to use bos2l or
you refer to github/elsewhere.
I find in f5 render, a lot of my stuff breaks up. However, in manifold
rendering f6, generally works. You can check, as Jordan hinted, by
including a cube when you f6, do it as the object is evolved. If you get
just a cube, then you know where you've screwed up.
On 12/01/2025 08:08, Thomas Richter via Discuss wrote:
I create concave polyhedra of several thousand faces. For details
My question is not about building the shape, that's solved, but about
a strange error I experience with certain input values. An example causing
the error can be found on Github:
When I render the shape I get this error:
WARNING: PolySet -> Manifold conversion failed: NotManifold
Trying to repair and reconstruct mesh..
ERROR: [manifold] Input mesh is not closed!
ERROR: [manifold] Surface_mesh -> Manifold conversion failed:
This happens in very rare situations (e. g.: ARMS = 13, 1.97 <=
_armPitch <= 2.17, _q = 182, _q = 208 and ARMS = 17, 1.93 <= _armPitch <=
2.18, _q = 204). Since the values are similar I believe there is a
geometrical reason but I have no idea how I could debug this and figure out
the actual cause.
If you comment out line 163 (subtract hollow sphere) it doesn't happen
(though the shape will look strange then). The polyhedron itself is built
correctly, I have checked it several times by hand.
My platform is an Apple Silicon M3 CPU.
I would like to know if others experience the same behavior (on other
platforms) with the example provided and if so, what is the cause or at
least what could I do to debug it. My impression is that it happens when
the shape to subtract from is complex and very tiny faces are generated.
Unfortunately, the error message is not very helpful.
Is this an already known glitch?
Second question related to this: In case this is a shortcoming of the
rendering engine: Is there any chance to catch this error by means of the
source code and handle it by, e. g., adjusting the _armPitch value?
If this question is assumed to be spam, please let me know how I
should have brought this problem up. I have already asked the question in
one of the last messages of the other thread but it seems that it got lost
there.
A polyhedron by itself never produces an error, even if it is invalid. If
it fails when you union with a cube then that means your polyhedron is
somehow invalid.
On Sun, Jan 12, 2025 at 1:49 PM Thomas Richter via Discuss <
discuss@lists.openscad.org> wrote:
> Thank you for this insight. I misunderstood the manual and oriented the
> side faces counterclockwise instead of clockwise. After fixing this the
> purple is all gone, the problem persists with boolean operations, goes away
> without boolean operations.
>
> The render() was there because the misoriented side faces made the body
> appearing transparent. Unfortunately this didn't lead to any insight on my
> side :-(
>
> I checked with a script that all points - copied from output with echo -
> are unique.
>
> I have uploaded the version with the fixed faces:
>
>
> https://github.com/trses/screw-nut-knobs/blob/boolean-glitch/analytical-solution.scad
>
> I flushed the caches before every experiment and made the following
> observations when trying to render (not preview), see lines 167 - 179:
>
> - difference with the polyhedron and a hollow sphere: problem persists
> - union with the polyhedron and a cube someplace else: problem persists
> - commenting out the difference / union rendering just the polyhedron:
> problem goes away.
>
> What does this mean?
>
>
> > Am 12.01.2025 um 17:41 schrieb Adrian Mariano via Discuss <
> discuss@lists.openscad.org>:
> >
> > He did post (a link to) the full code.
> >
> > Actually I got fooled when I viewed the shape with "thrown together".
> He explicitly calls render() in his code, which bypasses the
> thrown-together process. I actually figured this out because the BOSL2
> polyhedron validator produced a long list of errors like this:
> >
> > ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at
> [[0.0319137, -16.3794, 18.4927], [-0.932485, -16.0686, 18.6187]] indices:
> [3217, 3216]"
> > ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[0.949081,
> -16.81, 18.2839], [0.0319137, -16.3794, 18.4927]] indices: [3218, 3217]"
> > ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[1.80419,
> -17.3535, 17.9945], [0.949081, -16.81, 18.2839]] indices: [3219, 3218]"
> > ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[2.1411,
> -17.6335, 17.8396], [1.80419, -17.3535, 17.9945]] indices: [3220, 3219]"
> > ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[2.4012,
> -17.281, 17.9945], [2.1411, -17.6335, 17.8396]] indices: [3221, 3220]"
> > ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[3.10139,
> -16.5486, 18.2839], [2.4012, -17.281, 17.9945]] indices: [3222, 3221]"
> >
> > I am not sure why that render() call is there. It doesn't seem to do
> anything other than preventing the user from using preview and hiding
> errors. With render() removed, and thrown together enabled, the face
> reversal is obvious as seen below. So the conclusion is: the polyhedron
> has reversed faces, hence it is invalid.
> >
> >
> > <image.png>
> >
> >
> >
> >
> >
> > On Sun, Jan 12, 2025 at 11:10 AM Raymond West via Discuss <
> discuss@lists.openscad.org> wrote:
> > It would help if you posted an image of what you're trying to create,
> > and possibly some code. I can't help if you are trying to use bos2l or
> > you refer to github/elsewhere.
> >
> > I find in f5 render, a lot of my stuff breaks up. However, in manifold
> > rendering f6, generally works. You can check, as Jordan hinted, by
> > including a cube when you f6, do it as the object is evolved. If you get
> > just a cube, then you know where you've screwed up.
> >
> > On 12/01/2025 08:08, Thomas Richter via Discuss wrote:
> > > I create concave polyhedra of several thousand faces. For details
> about the purpose see
> https://lists.openscad.org/empathy/thread/LY26O7U4CLHPW3BGQIDLSAE6FRVVHEUG
> > >
> > > My question is not about building the shape, that's solved, but about
> a strange error I experience with certain input values. An example causing
> the error can be found on Github:
> > >
> > >
> https://github.com/trses/screw-nut-knobs/blob/boolean-glitch/analytical-solution.scad
> > >
> > > When I render the shape I get this error:
> > >
> > > WARNING: PolySet -> Manifold conversion failed: NotManifold
> > > Trying to repair and reconstruct mesh..
> > > ERROR: [manifold] Input mesh is not closed!
> > > ERROR: [manifold] Surface_mesh -> Manifold conversion failed:
> NotManifold
> > >
> > > This happens in very rare situations (e. g.: ARMS = 13, 1.97 <=
> _armPitch <= 2.17, _q = 182, _q = 208 and ARMS = 17, 1.93 <= _armPitch <=
> 2.18, _q = 204). Since the values are similar I believe there is a
> geometrical reason but I have no idea how I could debug this and figure out
> the actual cause.
> > >
> > > If you comment out line 163 (subtract hollow sphere) it doesn't happen
> (though the shape will look strange then). The polyhedron itself is built
> correctly, I have checked it several times by hand.
> > >
> > > My platform is an Apple Silicon M3 CPU.
> > >
> > > I would like to know if others experience the same behavior (on other
> platforms) with the example provided and if so, what is the cause or at
> least what could I do to debug it. My impression is that it happens when
> the shape to subtract from is complex and very tiny faces are generated.
> Unfortunately, the error message is not very helpful.
> > >
> > > Is this an already known glitch?
> > >
> > > Second question related to this: In case this is a shortcoming of the
> rendering engine: Is there any chance to catch this error by means of the
> source code and handle it by, e. g., adjusting the _armPitch value?
> > >
> > > If this question is assumed to be spam, please let me know how I
> should have brought this problem up. I have already asked the question in
> one of the last messages of the other thread but it seems that it got lost
> there.
> > > _______________________________________________
> > > 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 to discuss-leave@lists.openscad.org
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
TR
Thomas Richter
Sun, Jan 12, 2025 9:56 PM
I give up. That's not a problem for my project since I don't need the boolean operation with the latest solution. I was just interested in the cause of the glitch.
There is absolutely no evidence that the polyhedron is invalid after fixing the face orientation issue you found. I have checked with meshlab, with a script I implemented by myself, as well as different slicers. Neither show any errors in the meshes that I can export from OpenSCAD nor in the object structures output with echo. The polyhedra are always created the same way in my code, no matter what model parameters I use. Thus it is very likely that the structure of the few polyhedra that cannot be rendered is also correct. Based on the tests with my own scripts it is.
I can create multiple polyhedra in the same scene. All points are unique by design but nonetheless, I have even checked that and found nothing.
The latest possibility I saw was in the (quite surprisingly unpredictable) way the polyhedron function handles faces with a large number of vertices that are not within one and the same plane. After replacing those with self-generated triangles, I have no further idea.
I never compare floating point values without considering possible precision issues.
The problem appears only for very few combinations of model parameters. My software engineering experience gives me a strong feeling towards floating point issues but I have no idea where they should come from.
Thank you all for your help.
Am 12.01.2025 um 20:29 schrieb Adrian Mariano via Discuss discuss@lists.openscad.org:
A polyhedron by itself never produces an error, even if it is invalid. If it fails when you union with a cube then that means your polyhedron is somehow invalid.
On Sun, Jan 12, 2025 at 1:49 PM Thomas Richter via Discuss discuss@lists.openscad.org wrote:
Thank you for this insight. I misunderstood the manual and oriented the side faces counterclockwise instead of clockwise. After fixing this the purple is all gone, the problem persists with boolean operations, goes away without boolean operations.
The render() was there because the misoriented side faces made the body appearing transparent. Unfortunately this didn't lead to any insight on my side :-(
I checked with a script that all points - copied from output with echo - are unique.
I have uploaded the version with the fixed faces:
https://github.com/trses/screw-nut-knobs/blob/boolean-glitch/analytical-solution.scad
I flushed the caches before every experiment and made the following observations when trying to render (not preview), see lines 167 - 179:
- difference with the polyhedron and a hollow sphere: problem persists
- union with the polyhedron and a cube someplace else: problem persists
- commenting out the difference / union rendering just the polyhedron: problem goes away.
What does this mean?
Am 12.01.2025 um 17:41 schrieb Adrian Mariano via Discuss discuss@lists.openscad.org:
He did post (a link to) the full code.
Actually I got fooled when I viewed the shape with "thrown together". He explicitly calls render() in his code, which bypasses the thrown-together process. I actually figured this out because the BOSL2 polyhedron validator produced a long list of errors like this:
ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[0.0319137, -16.3794, 18.4927], [-0.932485, -16.0686, 18.6187]] indices: [3217, 3216]"
ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[0.949081, -16.81, 18.2839], [0.0319137, -16.3794, 18.4927]] indices: [3218, 3217]"
ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[1.80419, -17.3535, 17.9945], [0.949081, -16.81, 18.2839]] indices: [3219, 3218]"
ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[2.1411, -17.6335, 17.8396], [1.80419, -17.3535, 17.9945]] indices: [3220, 3219]"
ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[2.4012, -17.281, 17.9945], [2.1411, -17.6335, 17.8396]] indices: [3221, 3220]"
ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[3.10139, -16.5486, 18.2839], [2.4012, -17.281, 17.9945]] indices: [3222, 3221]"
I am not sure why that render() call is there. It doesn't seem to do anything other than preventing the user from using preview and hiding errors. With render() removed, and thrown together enabled, the face reversal is obvious as seen below. So the conclusion is: the polyhedron has reversed faces, hence it is invalid.
<image.png>
On Sun, Jan 12, 2025 at 11:10 AM Raymond West via Discuss discuss@lists.openscad.org wrote:
It would help if you posted an image of what you're trying to create,
and possibly some code. I can't help if you are trying to use bos2l or
you refer to github/elsewhere.
I find in f5 render, a lot of my stuff breaks up. However, in manifold
rendering f6, generally works. You can check, as Jordan hinted, by
including a cube when you f6, do it as the object is evolved. If you get
just a cube, then you know where you've screwed up.
On 12/01/2025 08:08, Thomas Richter via Discuss wrote:
I create concave polyhedra of several thousand faces. For details about the purpose see https://lists.openscad.org/empathy/thread/LY26O7U4CLHPW3BGQIDLSAE6FRVVHEUG
My question is not about building the shape, that's solved, but about a strange error I experience with certain input values. An example causing the error can be found on Github:
https://github.com/trses/screw-nut-knobs/blob/boolean-glitch/analytical-solution.scad
When I render the shape I get this error:
WARNING: PolySet -> Manifold conversion failed: NotManifold
Trying to repair and reconstruct mesh..
ERROR: [manifold] Input mesh is not closed!
ERROR: [manifold] Surface_mesh -> Manifold conversion failed: NotManifold
This happens in very rare situations (e. g.: ARMS = 13, 1.97 <= _armPitch <= 2.17, _q = 182, _q = 208 and ARMS = 17, 1.93 <= _armPitch <= 2.18, _q = 204). Since the values are similar I believe there is a geometrical reason but I have no idea how I could debug this and figure out the actual cause.
If you comment out line 163 (subtract hollow sphere) it doesn't happen (though the shape will look strange then). The polyhedron itself is built correctly, I have checked it several times by hand.
My platform is an Apple Silicon M3 CPU.
I would like to know if others experience the same behavior (on other platforms) with the example provided and if so, what is the cause or at least what could I do to debug it. My impression is that it happens when the shape to subtract from is complex and very tiny faces are generated. Unfortunately, the error message is not very helpful.
Is this an already known glitch?
Second question related to this: In case this is a shortcoming of the rendering engine: Is there any chance to catch this error by means of the source code and handle it by, e. g., adjusting the _armPitch value?
If this question is assumed to be spam, please let me know how I should have brought this problem up. I have already asked the question in one of the last messages of the other thread but it seems that it got lost there.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
I give up. That's not a problem for my project since I don't need the boolean operation with the latest solution. I was just interested in the cause of the glitch.
There is absolutely no evidence that the polyhedron is invalid after fixing the face orientation issue you found. I have checked with meshlab, with a script I implemented by myself, as well as different slicers. Neither show any errors in the meshes that I can export from OpenSCAD nor in the object structures output with echo. The polyhedra are always created the same way in my code, no matter what model parameters I use. Thus it is very likely that the structure of the few polyhedra that cannot be rendered is also correct. Based on the tests with my own scripts it is.
I can create multiple polyhedra in the same scene. All points are unique by design but nonetheless, I have even checked that and found nothing.
The latest possibility I saw was in the (quite surprisingly unpredictable) way the polyhedron function handles faces with a large number of vertices that are not within one and the same plane. After replacing those with self-generated triangles, I have no further idea.
I never compare floating point values without considering possible precision issues.
The problem appears only for very few combinations of model parameters. My software engineering experience gives me a strong feeling towards floating point issues but I have no idea where they should come from.
Thank you all for your help.
> Am 12.01.2025 um 20:29 schrieb Adrian Mariano via Discuss <discuss@lists.openscad.org>:
>
> A polyhedron by itself never produces an error, even if it is invalid. If it fails when you union with a cube then that means your polyhedron is somehow invalid.
>
> On Sun, Jan 12, 2025 at 1:49 PM Thomas Richter via Discuss <discuss@lists.openscad.org> wrote:
> Thank you for this insight. I misunderstood the manual and oriented the side faces counterclockwise instead of clockwise. After fixing this the purple is all gone, the problem persists with boolean operations, goes away without boolean operations.
>
> The render() was there because the misoriented side faces made the body appearing transparent. Unfortunately this didn't lead to any insight on my side :-(
>
> I checked with a script that all points - copied from output with echo - are unique.
>
> I have uploaded the version with the fixed faces:
>
> https://github.com/trses/screw-nut-knobs/blob/boolean-glitch/analytical-solution.scad
>
> I flushed the caches before every experiment and made the following observations when trying to render (not preview), see lines 167 - 179:
>
> - difference with the polyhedron and a hollow sphere: problem persists
> - union with the polyhedron and a cube someplace else: problem persists
> - commenting out the difference / union rendering just the polyhedron: problem goes away.
>
> What does this mean?
>
>
> > Am 12.01.2025 um 17:41 schrieb Adrian Mariano via Discuss <discuss@lists.openscad.org>:
> >
> > He did post (a link to) the full code.
> >
> > Actually I got fooled when I viewed the shape with "thrown together". He explicitly calls render() in his code, which bypasses the thrown-together process. I actually figured this out because the BOSL2 polyhedron validator produced a long list of errors like this:
> >
> > ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[0.0319137, -16.3794, 18.4927], [-0.932485, -16.0686, 18.6187]] indices: [3217, 3216]"
> > ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[0.949081, -16.81, 18.2839], [0.0319137, -16.3794, 18.4927]] indices: [3218, 3217]"
> > ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[1.80419, -17.3535, 17.9945], [0.949081, -16.81, 18.2839]] indices: [3219, 3218]"
> > ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[2.1411, -17.6335, 17.8396], [1.80419, -17.3535, 17.9945]] indices: [3220, 3219]"
> > ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[2.4012, -17.281, 17.9945], [2.1411, -17.6335, 17.8396]] indices: [3221, 3220]"
> > ECHO: "ERROR REVERSAL (violet): Faces Reverse Across Edge at [[3.10139, -16.5486, 18.2839], [2.4012, -17.281, 17.9945]] indices: [3222, 3221]"
> >
> > I am not sure why that render() call is there. It doesn't seem to do anything other than preventing the user from using preview and hiding errors. With render() removed, and thrown together enabled, the face reversal is obvious as seen below. So the conclusion is: the polyhedron has reversed faces, hence it is invalid.
> >
> >
> > <image.png>
> >
> >
> >
> >
> >
> > On Sun, Jan 12, 2025 at 11:10 AM Raymond West via Discuss <discuss@lists.openscad.org> wrote:
> > It would help if you posted an image of what you're trying to create,
> > and possibly some code. I can't help if you are trying to use bos2l or
> > you refer to github/elsewhere.
> >
> > I find in f5 render, a lot of my stuff breaks up. However, in manifold
> > rendering f6, generally works. You can check, as Jordan hinted, by
> > including a cube when you f6, do it as the object is evolved. If you get
> > just a cube, then you know where you've screwed up.
> >
> > On 12/01/2025 08:08, Thomas Richter via Discuss wrote:
> > > I create concave polyhedra of several thousand faces. For details about the purpose see https://lists.openscad.org/empathy/thread/LY26O7U4CLHPW3BGQIDLSAE6FRVVHEUG
> > >
> > > My question is not about building the shape, that's solved, but about a strange error I experience with certain input values. An example causing the error can be found on Github:
> > >
> > > https://github.com/trses/screw-nut-knobs/blob/boolean-glitch/analytical-solution.scad
> > >
> > > When I render the shape I get this error:
> > >
> > > WARNING: PolySet -> Manifold conversion failed: NotManifold
> > > Trying to repair and reconstruct mesh..
> > > ERROR: [manifold] Input mesh is not closed!
> > > ERROR: [manifold] Surface_mesh -> Manifold conversion failed: NotManifold
> > >
> > > This happens in very rare situations (e. g.: ARMS = 13, 1.97 <= _armPitch <= 2.17, _q = 182, _q = 208 and ARMS = 17, 1.93 <= _armPitch <= 2.18, _q = 204). Since the values are similar I believe there is a geometrical reason but I have no idea how I could debug this and figure out the actual cause.
> > >
> > > If you comment out line 163 (subtract hollow sphere) it doesn't happen (though the shape will look strange then). The polyhedron itself is built correctly, I have checked it several times by hand.
> > >
> > > My platform is an Apple Silicon M3 CPU.
> > >
> > > I would like to know if others experience the same behavior (on other platforms) with the example provided and if so, what is the cause or at least what could I do to debug it. My impression is that it happens when the shape to subtract from is complex and very tiny faces are generated. Unfortunately, the error message is not very helpful.
> > >
> > > Is this an already known glitch?
> > >
> > > Second question related to this: In case this is a shortcoming of the rendering engine: Is there any chance to catch this error by means of the source code and handle it by, e. g., adjusting the _armPitch value?
> > >
> > > If this question is assumed to be spam, please let me know how I should have brought this problem up. I have already asked the question in one of the last messages of the other thread but it seems that it got lost there.
> > > _______________________________________________
> > > 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 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 to discuss-leave@lists.openscad.org
