Am 12.01.2025 um 22:56 schrieb Thomas Richter tomselektropost@googlemail.com:

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.

I had another idea and finally found it. It was indeed a problem with the
polyhedron, a very rare edge case where two vertices of the same layer are
very close and the number of vertices decreases in the next layer and the
next vertex in the same layer is quite far away from the two other ones. I
could only find it by analysing the generated faces with another script.

Thanks again for your help.

tomselektropost@googlemail.com>:

boolean operation with the latest solution. I was just interested in the
cause of the glitch.

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.

by design but nonetheless, I have even checked that and found nothing.

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.

precision issues.

My software engineering experience gives me a strong feeling towards
floating point issues but I have no idea where they should come from.

discuss@lists.openscad.org>:

If it fails when you union with a cube then that means your polyhedron is
somehow invalid.

discuss@lists.openscad.org> wrote:

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.

appearing transparent. Unfortunately this didn't lead to any insight on my
side :-(

• are unique.

https://github.com/trses/screw-nut-knobs/blob/boolean-glitch/analytical-solution.scad

observations when trying to render (not preview), see lines 167 - 179:

problem goes away.

discuss@lists.openscad.org>:

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:

[[0.0319137, -16.3794, 18.4927], [-0.932485, -16.0686, 18.6187]] indices:
[3217, 3216]"

[[0.949081, -16.81, 18.2839], [0.0319137, -16.3794, 18.4927]] indices:
[3218, 3217]"

[[1.80419, -17.3535, 17.9945], [0.949081, -16.81, 18.2839]] indices: [3219,
3218]"

-17.6335, 17.8396], [1.80419, -17.3535, 17.9945]] indices: [3220, 3219]"

-17.281, 17.9945], [2.1411, -17.6335, 17.8396]] indices: [3221, 3220]"

[[3.10139, -16.5486, 18.2839], [2.4012, -17.281, 17.9945]] indices: [3222,
3221]"

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.

discuss@lists.openscad.org> wrote:

get

about the purpose see
https://lists.openscad.org/empathy/thread/LY26O7U4CLHPW3BGQIDLSAE6FRVVHEUG

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

NotManifold

_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.

happen (though the shape will look strange then). The polyhedron itself is
built correctly, I have checked it several times by hand.

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.

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?

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 13.01.2025 um 00:44 schrieb Adrian Mariano via Discuss discuss@lists.openscad.org:

I was going to say I kicked off another run of vnf_validate() to check your polyhedron and got messages like this below (so edges that don't have a mate).  This validation runs in OpenSCAD, though it's slow.  It took 28 minutes on your polyhedron.  But it sounds like you have solved the problem, which is great.

ECHO: "ERROR HOLE_EDGE (red): Edge bounds Hole at [[2.19157, -18.0656, 7.62068], [2.19371, -18.0668, 7.61989]] indices: [2824, 2825]"
ECHO: "ERROR HOLE_EDGE (red): Edge bounds Hole at [[2.19371, -18.0668, 7.61989], [2.19549, -18.0651, 7.62068]] indices: [2825, 2826]"
ECHO: "ERROR HOLE_EDGE (red): Edge bounds Hole at [[2.19371, -18.0668, 7.61989], [2.63126, -17.4745, 7.88479]] indices: [2825, 2827]"
ECHO: "ERROR HOLE_EDGE (red): Edge bounds Hole at [[2.19549, -18.0651, 7.62068], [2.63126, -17.4745, 7.88479]] indices: [2826, 2827]"
ECHO: "ERROR HOLE_EDGE (red): Edge bounds Hole at [[9.61822, -14.8247, 7.88479], [10.336, -14.9778, 7.62068]] indices: [2835, 2836]"
ECHO: "ERROR HOLE_EDGE (red): Edge bounds Hole at [[9.61822, -14.8247, 7.88479], [10.3385, -14.9779, 7.61989]] indices: [2835, 2837]"
ECHO: "ERROR HOLE_EDGE (red): Edge bounds Hole at [[10.336, -14.9778, 7.62068], [10.3385, -14.9779, 7.61989]] indices: [2836, 2837]"
ECHO: "ERROR HOLE_EDGE (red): Edge bounds Hole at [[10.3385, -14.9779, 7.61989], [10.3393, -14.9755, 7.62068]] indices: [2837, 2838]"
ECHO: "ERROR HOLE_EDGE (red): Edge bounds Hole at [[10.3385, -14.9779, 7.61989], [10.4507, -14.2501, 7.88479]] indices: [2837, 2839]"
ECHO: "ERROR HOLE_EDGE (red): Edge bounds Hole at [[10.3393, -14.9755, 7.62068], [10.4507, -14.2501, 7.88479]] indices: [2838, 2839]"
ECHO: "ERROR HOLE_EDGE (red): Edge bounds Hole at [[15.4059, -8.65681, 7.88479], [16.1126, -8.45879, 7.62068]] indices: [2847, 2848]"
ECHO: "ERROR HOLE_EDGE (red): Edge bounds Hole at [[15.4059, -8.65681, 7.88479], [16.1149, -8.45775, 7.61989]] indices: [2847, 2849]"
ECHO: "ERROR HOLE_EDGE (red): Edge bounds Hole at [[16.1126, -8.45879, 7.62068], [16.1149, -8.45775, 7.61989]] indices: [2848, 2849]"
ECHO: "ERROR HOLE_EDGE (red): Edge bounds Hole at [[16.1149, -8.45775, 7.61989], [16.1145, -8.45529, 7.62068]] indices: [2849, 2850]"
ECHO: "ERROR HOLE_EDGE (red): Edge bounds Hole at [[16.1149, -8.45775, 7.61989], [15.876, -7.76117, 7.88479]] indices: [2849, 2851]"
ECHO: "ERROR HOLE_EDGE (red): Edge bounds Hole at [[16.1145, -8.45529, 7.62068], [15.876, -7.76117, 7.88479]] indices: [2850, 2851]"

On Sun, Jan 12, 2025 at 6:38 PM Thomas Richter via Discuss discuss@lists.openscad.org wrote:
I had another idea and finally found it. It was indeed a problem with the polyhedron, a very rare edge case where two vertices of the same layer are very close and the number of vertices decreases in the next layer and the next vertex in the same layer is quite far away from the two other ones. I could only find it by analysing the generated faces with another script.

Thanks again for your help.

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

I will have a look at vnf_validate to learn more about my options in cases
like this one.

discuss@lists.openscad.org>:

your polyhedron and got messages like this below (so edges that don't have
a mate).  This validation runs in OpenSCAD, though it's slow.  It took 28
minutes on your polyhedron.  But it sounds like you have solved the
problem, which is great.

7.62068], [2.19371, -18.0668, 7.61989]] indices: [2824, 2825]"

7.61989], [2.19549, -18.0651, 7.62068]] indices: [2825, 2826]"

7.61989], [2.63126, -17.4745, 7.88479]] indices: [2825, 2827]"

7.62068], [2.63126, -17.4745, 7.88479]] indices: [2826, 2827]"

7.88479], [10.336, -14.9778, 7.62068]] indices: [2835, 2836]"

7.88479], [10.3385, -14.9779, 7.61989]] indices: [2835, 2837]"

7.62068], [10.3385, -14.9779, 7.61989]] indices: [2836, 2837]"

7.61989], [10.3393, -14.9755, 7.62068]] indices: [2837, 2838]"

7.61989], [10.4507, -14.2501, 7.88479]] indices: [2837, 2839]"

7.62068], [10.4507, -14.2501, 7.88479]] indices: [2838, 2839]"

7.88479], [16.1126, -8.45879, 7.62068]] indices: [2847, 2848]"

7.88479], [16.1149, -8.45775, 7.61989]] indices: [2847, 2849]"

7.62068], [16.1149, -8.45775, 7.61989]] indices: [2848, 2849]"

7.61989], [16.1145, -8.45529, 7.62068]] indices: [2849, 2850]"

7.61989], [15.876, -7.76117, 7.88479]] indices: [2849, 2851]"

7.62068], [15.876, -7.76117, 7.88479]] indices: [2850, 2851]"

discuss@lists.openscad.org> wrote:

the polyhedron, a very rare edge case where two vertices of the same layer
are very close and the number of vertices decreases in the next layer and
the next vertex in the same layer is quite far away from the two other
ones. I could only find it by analysing the generated faces with another
script.

tomselektropost@googlemail.com>:

boolean operation with the latest solution. I was just interested in the
cause of the glitch.

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.

unique by design but nonetheless, I have even checked that and found
nothing.

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.

precision issues.

parameters. My software engineering experience gives me a strong feeling
towards floating point issues but I have no idea where they should come
from.

discuss@lists.openscad.org>:

invalid.  If it fails when you union with a cube then that means your
polyhedron is somehow invalid.

discuss@lists.openscad.org> wrote:

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.

body appearing transparent. Unfortunately this didn't lead to any insight
on my side :-(

echo - are unique.

https://github.com/trses/screw-nut-knobs/blob/boolean-glitch/analytical-solution.scad

observations when trying to render (not preview), see lines 167 - 179:

persists

polyhedron: problem goes away.

discuss@lists.openscad.org>:

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:

[[0.0319137, -16.3794, 18.4927], [-0.932485, -16.0686, 18.6187]] indices:
[3217, 3216]"

[[0.949081, -16.81, 18.2839], [0.0319137, -16.3794, 18.4927]] indices:
[3218, 3217]"

[[1.80419, -17.3535, 17.9945], [0.949081, -16.81, 18.2839]] indices: [3219,
3218]"

[[2.1411, -17.6335, 17.8396], [1.80419, -17.3535, 17.9945]] indices: [3220,
3219]"

[[2.4012, -17.281, 17.9945], [2.1411, -17.6335, 17.8396]] indices: [3221,
3220]"

[[3.10139, -16.5486, 18.2839], [2.4012, -17.281, 17.9945]] indices: [3222,
3221]"

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.

discuss@lists.openscad.org> wrote:

create,

or

manifold

get

about the purpose see
https://lists.openscad.org/empathy/thread/LY26O7U4CLHPW3BGQIDLSAE6FRVVHEUG

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

NotManifold

_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.

happen (though the shape will look strange then). The polyhedron itself is
built correctly, I have checked it several times by hand.

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.

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?

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 13.01.2025 um 01:10 schrieb Adrian Mariano via Discuss discuss@lists.openscad.org:

You said that it's "not a problem...since [you] don't need the boolean operation".  I should maybe point out also that just because you don't get an error when you have the polyhedron alone doesn't mean that things are OK.  Your polyhedron is still invalid.  It's just that OpenSCAD doesn't notice and it blithely writes out that invalid polyhedron as an STL file.  So if you do this you have to hope that whatever is downstream in your processing chain is willing and able to take the invalid input and fix it or handle it the way you want.  Personally I prefer to avoid generating invalid output.

The vnf_validate module is documented here:
https://github.com/BelfrySCAD/BOSL2/wiki/vnf.scad#module-vnf_validate

On Sun, Jan 12, 2025 at 6:58 PM Thomas Richter via Discuss discuss@lists.openscad.org wrote:
I will have a look at vnf_validate to learn more about my options in cases like this one.

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