Submitted to OpenSCAD as issue
https://github.com/openscad/openscad/issues/5391
Errors apparently produced while exporting .stl · Issue #5391 · openscad/openscad
github.com
-Bob
On Oct 25, 2024, at 16:44, Bob Carlson via Discuss discuss@lists.openscad.org wrote:
I got really intrigued by the Hirth joint and have been working a library entry that would generate them. I have it fully working, apparently, because it renders perfectly as far as I can see. However when I load one of the parts (a concave part) into PrusaSlicer, it reports thousands of errors that it supposedly fixed. The visual rendering is fine, but when you look at the slice it is completely screwed up.
First some explanation. When I looked up hirth joints I only saw flat ones mentioned. The one I have actually encountered though is a conical one. There is a concave part and a convex part. They fit together perfectly. I had to invent some terminology since I did not find terms for some things I found to be important. The outer center line is the plane that passes through the midpoint of the teeth at the outer radius. In a flat hirth joint all the teeth radiate from the center of this circle, call it the origin. If the origin of the teeth is above the outer center line, then joint has a conical shape and the two parts are concave and convex.
Each tooth at every point has the same profile, the top of the tooth profile is either 60 or 90 degrees. The groove angle is the angle that the groove forms from the origin to the outer radius. It will pass below (for a convex part) the outer radius. It’s critical for making hirth joints because it forms the tool path. The ridge angle is the angle formed by the corresponding ridge.
If the joint is conical, then there is an inner center line that passes through the center of the teeth at the inner radius. The tooth height is the critical number to calculate. It is dependent on the number of teeth, the profile angle and the inner and out radii. Something that really complicates the mental gymnastics is that the tooth height is smaller at the inner radius. My code adds a “base” of extra material at the bottom of the convex part and the top of the concave part. What’s tricky is positioning the base of the concave part relative to the inner center line. The concave parts base is relatively easy to place because it depends on the outer radius and center line.
I generate the raw teeth using the groove and ridge angles and spherical coordinates to make two 2d tooth profiles. Then I complete a tooth using skin(). A for loop generates the full set of N teeth. Then intersection or difference is used the trim the teeth at the inner and outer radii. I discovered something at that point, but solved it pretty simply. When diffing a cylinder from the N teeth, each tooth took up a small portion of the cylinder being diffed out. I had to raise the $fn on the cylinder or tube being used so that I got enough points in each tooth that diff or intersection was accurate. I kept raising it until the results stopped improving. I ended up with the 16*360 you see in the code.
After I have the raw teeth, I generate a cone that is diffed away to produce the chamfer at the top of the teeth. Then I add in the base. The base also adds the “chamfer” at the bottom of the groove. It’s half the size of the top chamfer to leave a little gap when the parts are joined.
When I comment out the everything but the raw teeth and import the STL into PrusaSlicer, it reports errors fixed, but appears to slice correctly when supports are added.
When I add the intersection to trim the raw teeth, the number of reported errors goes way up.
When I add the diff to remove the chamfer, the number goes way up again.
When I add in the base, the number goes up again and it starts reporting many open edges.
Throughout, OpenSCAD reports no errors. Using $fn at 16360, manifold renders in 4+ seconds. At 32360, it’s 53+ seconds. I did check CSG and it did not help.
Maybe the biggest hint is that the convex part uses almost identical code, but produces no errors. Very weird.
So, is this an OpenSCAD problem? Or something in my code?
It’s also possible that my math is off somewhere. My formal trig training was 60 years ago. However I doubt a math error is responsible for the slicing problem and STL errors.
-Bob
include <BOSL2/std.scad>
include <BOSL2/structs.scad>
// Number of Teeth
_n = 36; // Number Of Teeth
// Inner Radius
_ir = 30;
// Outer Radius
_or = 50;
// Is the coupling conical?
_conic = 10;
// Tooth Profile Angle
_profile = 60; // [60, 90]
// Percentage of tooth height
_chamfer = 5; // Default 5%
_base = 1;
$fn = 180;
tiny = 1 / 1024;
hirth_concave();
_irRatio = _ir / _or;
_toothAngle = 360/_n;
_toothHeight = (sin(_toothAngle/2) * _or) / tan(_profile/2);
_chamferHeight = _chamfer * _toothHeight / 100;
_grooveAngle = atan(((_toothHeight/2) + _conic) / _or);
_ridgeAngle = -atan(((_toothHeight/2) - _conic) / _or);
_innerCenterLine = (1 - _irRatio) * _conic;
_stackHeight = _innerCenterLine + _toothHeight + 2*_base;
_tubeHeight = 2*_conic + 2*_base + 2*_toothHeight;
module hirth_concave() {
zrot(_toothAngle/2)
union() {
difference() {
intersection() {
union() {
for (i = [0 : 360/_n : 359])
zrot(i)
_profileF();
}
tube(ir = _ir, or = _or, anchor = CENTER, l = _tubeHeight, orient = UP, $fn = 16360);
}
_chamferF();
zcyl(r = _ir, h = _tubeHeight, $fn = 16360, anchor = CENTER);
}
_baseF();
}
} // hirth_concave
module _profileF() {
IR = _ir * .5;
OR = _or * 1.5;
tI = [spherical_to_xyz(IR, 0, _grooveAngle + 90),
spherical_to_xyz(IR, _toothAngle/2, _ridgeAngle + 90),
spherical_to_xyz(IR, -_toothAngle/2, _ridgeAngle + 90)];
tO = [spherical_to_xyz(OR, 0, _grooveAngle + 90),
spherical_to_xyz(OR, _toothAngle/2, _ridgeAngle + 90),
spherical_to_xyz(OR, -_toothAngle/2, _ridgeAngle + 90)];
up(_conic)
skin([tI, tO], slices = 0);
}
module _chamferF() {
A = -_toothHeight/2 - .1;
B = -_toothHeight/2 + _chamferHeight;
pts = [[0, _conic],
[_or+tiny, A],
[_or+tiny, B]];
rotate_extrude(angle = 360, $fn = 16*360)
polygon(pts);
}
module _baseF() {
A = _base + _irRatio*_toothHeight/2 + _innerCenterLine;
B = _irRatio * (_toothHeight/2 - _chamferHeight/2) + _innerCenterLine;
C = _toothHeight/2 - _chamferHeight/2;
pts = [
[_ir, A],
[_ir, B],
[_or, C],
[_or, A]
];
rotate_extrude(angle = 360, $fn = 360*16)
polygon(pts);
}
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
I notice that your _profileF() ends up generating an inside-out
polyhedron. When viewed with View/Thrown Together, it's purple. That
can cause problems for rendering. (I'm a little surprised that it
didn't cause fatal problems.) It looks like you can fix it by swapping
the second and third points in both tI and tO.
Another thing attracted my attention immediately.
Mostly, just don't use $fn except to create regular polygons. Use $fs
and $fa; they are much less likely to lead you into silly settings.
You have $fn=16*360 = 5760. Assuming that the units are millimeters,
the model is about 100mm in diameter, so its circumference is 314mm.
That means that each side is 0.05mm. Those tiny sides, and the even
tinier artifacts that they might cause, might well be a key part of your
geometry problems. My bet is that you could use fewer than 100 sides
and still be unable to see or feel the individual sides when you print
it. And if you can see them, bump it up to 300 or 500, and you've still
got 10x fewer sides than your version does.
Preview is (at least for me) horribly laggy when you try to move it, and
it has what look like convexity artifacts.
Removing all of the settings for $fn and adding in a single global
setting for $fa=1 and $fs=1, and it previews fast and fixes the
convexity artifacts.
Also, a tidbit: _chamferF() generates a conical figure that might as
well be a cone.
up(_conic + _chamferHeight) scale(1.5) zcyl(h = _toothHeight/2 + _conic, r1 = _or, r2 = 0, anchor=TOP);
Since it's anchored at the top, I didn't have to fiddle with making sure
that it was slightly larger than the thing it's cutting from and could
just scale it up a bit.
I think your technique is responsible for generating micro flaws at the
outside edges.
Note: I first tried this mod while I happened to be running an OpenSCAD
from January. With my changes, rendering failed with manifold errors.
When I switched to a recent build, it was OK again. So if you're having
manifold problems, upgrade.
Thanks! I hear about these point ordering problems. It seems a shame one has to deal with them. Why can’t they be fixed automatically?
-Bob
On Oct 26, 2024, at 16:21, Jordan Brown openscad@jordan.maileater.net wrote:
I notice that your _profileF() ends up generating an inside-out polyhedron. When viewed with View/Thrown Together, it's purple. That can cause problems for rendering. (I'm a little surprised that it didn't cause fatal problems.) It looks like you can fix it by swapping the second and third points in both tI and tO.
Another thing attracted my attention immediately.
Mostly, just don't use $fn except to create regular polygons. Use $fs and $fa; they are much less likely to lead you into silly settings.
You have $fn=16*360 = 5760. Assuming that the units are millimeters, the model is about 100mm in diameter, so its circumference is 314mm. That means that each side is 0.05mm. Those tiny sides, and the even tinier artifacts that they might cause, might well be a key part of your geometry problems. My bet is that you could use fewer than 100 sides and still be unable to see or feel the individual sides when you print it. And if you can see them, bump it up to 300 or 500, and you've still got 10x fewer sides than your version does.
Preview is (at least for me) horribly laggy when you try to move it, and it has what look like convexity artifacts.
Removing all of the settings for $fn and adding in a single global setting for $fa=1 and $fs=1, and it previews fast and fixes the convexity artifacts.
Also, a tidbit: _chamferF() generates a conical figure that might as well be a cone.
up(_conic + _chamferHeight) scale(1.5) zcyl(h = _toothHeight/2 + _conic, r1 = _or, r2 = 0, anchor=TOP);
Since it's anchored at the top, I didn't have to fiddle with making sure that it was slightly larger than the thing it's cutting from and could just scale it up a bit.
I think your technique is responsible for generating micro flaws at the outside edges.
<YWbsxKvQ36n0OH8f.png>
Note: I first tried this mod while I happened to be running an OpenSCAD from January. With my changes, rendering failed with manifold errors. When I switched to a recent build, it was OK again. So if you're having manifold problems, upgrade.
here is my version of this through python
On Sun, 27 Oct 2024 at 06:15, Bob Carlson via Discuss <
discuss@lists.openscad.org> wrote:
Thanks! I hear about these point ordering problems. It seems a shame one
has to deal with them. Why can’t they be fixed automatically?
-Bob
On Oct 26, 2024, at 16:21, Jordan Brown openscad@jordan.maileater.net
wrote:
I notice that your _profileF() ends up generating an inside-out
polyhedron. When viewed with View/Thrown Together, it's purple. That can
cause problems for rendering. (I'm a little surprised that it didn't cause
fatal problems.) It looks like you can fix it by swapping the second and
third points in both tI and tO.
Another thing attracted my attention immediately.
Mostly, just don't use $fn except to create regular polygons. Use $fs
and $fa; they are much less likely to lead you into silly settings.
You have $fn=16*360 = 5760. Assuming that the units are millimeters,
the model is about 100mm in diameter, so its circumference is 314mm. That
means that each side is 0.05mm. Those tiny sides, and the even tinier
artifacts that they might cause, might well be a key part of your geometry
problems. My bet is that you could use fewer than 100 sides and still be
unable to see or feel the individual sides when you print it. And if you
can see them, bump it up to 300 or 500, and you've still got 10x fewer
sides than your version does.
Preview is (at least for me) horribly laggy when you try to move it, and
it has what look like convexity artifacts.
Removing all of the settings for $fn and adding in a single global
setting for $fa=1 and $fs=1, and it previews fast and fixes the convexity
artifacts.
Also, a tidbit: _chamferF() generates a conical figure that might as
well be a cone.
up(_conic + _chamferHeight) scale(1.5) zcyl(h = _toothHeight/2 +
_conic, r1 = _or, r2 = 0, anchor=TOP);
Since it's anchored at the top, I didn't have to fiddle with making sure
that it was slightly larger than the thing it's cutting from and could just
scale it up a bit.
I think your technique is responsible for generating micro flaws at the
outside edges.
<YWbsxKvQ36n0OH8f.png>
Note: I first tried this mod while I happened to be running an OpenSCAD
from January. With my changes, rendering failed with manifold errors.
When I switched to a recent build, it was OK again. So if you're having
manifold problems, upgrade.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
On 10/26/2024 5:44 PM, Bob Carlson wrote:
Thanks! I hear about these point ordering problems. It seems a shame one has to deal with them. Why can’t they be fixed automatically?
I don't know for sure.
There are two levels to the question here: first BOSL2 builds a
polyhedron, and then second OpenSCAD processes the polyhedron.
BOSL2 could generate the polyhedron "correctly". I don't know how hard
that would be, but that's essentially what swapping the points does: it
causes BOSL2 to build the polyhedron the other way 'round. I don't know
enough about "skin" to know how easy it would be to detect being backwards.
And then when OpenSCAD receives the "inside-out" polyhedron, it could
perhaps fix it. I think that if it's completely inside out then
detecting that and fixing it isn't hard. (But right now I'm not sure
how to tell which way is "inside".) If it's partially inside-out (like
one face is backwards) then I think I know how to detect that, and I
guess that if you can detect it then you can flip faces until they are
all consistent, and then you might be inside-out but you've reduced it
to the case above. So my not-a-geometry-wizard sense is that it's
doable. (OCD note: you need to watch out for Klein bottles, lest you
flip faces infinitely.)
Is anybody interested in spending the effort? Obviously not so far.
(And I think we can all agree that we'd rather have the geometry wizards
work on Manifold and its huge performance improvement.)
When I'm building a polyhedron, mostly I just turn on Thrown Together
and fix backward faces as required. That's less of an imposition on DIY
polyhedra than it is when your polyhedron is coming out of a library.
Thank you, Jordan, I missed the email with the little spear points at the
bottom of the tooth profile, and the original pictures it was not clear
what the problem was. This helps me look at what is going on... The last
time I had something like this, I made a parametric profile and then
extruded it, and it worked around the issue. Maybe a trick like that might
work to clean it up. That said, your zoomed-in example might give folks a
go-to geometrical unit-test to track it down. Not sure if there are
takers, but this should be archived as a potential debugging test.
Bob, I hear you. If this is fit for your purpose, then it is "good
enough". There comes a point where spending time fixing some things is a
diminishing returns game. I still think this should be formally submitted
in a bug report, and see if it can be reduced to 2 teeth profiles as the
whole of the part. This would be small enough to be debuggable, and large
enough to expose the bug.
EBo --
On Sat, Oct 26, 2024 at 10:51 PM Sanjeev Prabhakar via Discuss <
discuss@lists.openscad.org> wrote:
here is my version of this through python
On Sun, 27 Oct 2024 at 06:15, Bob Carlson via Discuss <
discuss@lists.openscad.org> wrote:
Thanks! I hear about these point ordering problems. It seems a shame one
has to deal with them. Why can’t they be fixed automatically?
-Bob
On Oct 26, 2024, at 16:21, Jordan Brown openscad@jordan.maileater.net
wrote:
I notice that your _profileF() ends up generating an inside-out
polyhedron. When viewed with View/Thrown Together, it's purple. That can
cause problems for rendering. (I'm a little surprised that it didn't cause
fatal problems.) It looks like you can fix it by swapping the second and
third points in both tI and tO.
Another thing attracted my attention immediately.
Mostly, just don't use $fn except to create regular polygons. Use $fs
and $fa; they are much less likely to lead you into silly settings.
You have $fn=16*360 = 5760. Assuming that the units are millimeters,
the model is about 100mm in diameter, so its circumference is 314mm. That
means that each side is 0.05mm. Those tiny sides, and the even tinier
artifacts that they might cause, might well be a key part of your geometry
problems. My bet is that you could use fewer than 100 sides and still be
unable to see or feel the individual sides when you print it. And if you
can see them, bump it up to 300 or 500, and you've still got 10x fewer
sides than your version does.
Preview is (at least for me) horribly laggy when you try to move it,
and it has what look like convexity artifacts.
Removing all of the settings for $fn and adding in a single global
setting for $fa=1 and $fs=1, and it previews fast and fixes the convexity
artifacts.
Also, a tidbit: _chamferF() generates a conical figure that might as
well be a cone.
up(_conic + _chamferHeight) scale(1.5) zcyl(h = _toothHeight/2 +
_conic, r1 = _or, r2 = 0, anchor=TOP);
Since it's anchored at the top, I didn't have to fiddle with making
sure that it was slightly larger than the thing it's cutting from and could
just scale it up a bit.
I think your technique is responsible for generating micro flaws at the
outside edges.
<YWbsxKvQ36n0OH8f.png>
Note: I first tried this mod while I happened to be running an
OpenSCAD from January. With my changes, rendering failed with manifold
errors. When I switched to a recent build, it was OK again. So if you're
having manifold problems, upgrade.
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
One way to do this might be pairs of hull plates. use two narrow
diameter cylinders as rays, they don't have to meet. That (once a hull)
becomes a plate. Create another using the bottom (or top) and with a
matching side. Has to be separate hull entities. Rotate as needed.
Diameter of cylinder determines rounding of the tooth.
This gives you a crinkled surface. To do a gear tooth, use three
cylinders, overlapping at the vertical extents (likely top).
Doesn't solve your problem, but it's an alternate way of doing things.
Harvey
On 10/27/2024 12:35 AM, John David via Discuss wrote:
Thank you, Jordan, I missed the email with the little spear points at
the bottom of the tooth profile, and the original pictures it was not
clear what the problem was. This helps me look at what is going
on... The last time I had something like this, I made a parametric
profile and then extruded it, and it worked around the issue. Maybe a
trick like that might work to clean it up. That said, your zoomed-in
example might give folks a go-to geometrical unit-test to track it
down. Not sure if there are takers, but this should be archived as a
potential debugging test.
Bob, I hear you. If this is fit for your purpose, then it is "good
enough". There comes a point where spending time fixing some things
is a diminishing returns game. I still think this should be formally
submitted in a bug report, and see if it can be reduced to 2 teeth
profiles as the whole of the part. This would be small enough to be
debuggable, and large enough to expose the bug.
EBo --
On Sat, Oct 26, 2024 at 10:51 PM Sanjeev Prabhakar via Discuss
discuss@lists.openscad.org wrote:
here is my version of this through python
https://youtu.be/Wp8q71eMqrE
On Sun, 27 Oct 2024 at 06:15, Bob Carlson via Discuss
<discuss@lists.openscad.org> wrote:
Thanks! I hear about these point ordering problems. It seems a
shame one has to deal with them. Why can’t they be fixed
automatically?
-Bob
On Oct 26, 2024, at 16:21, Jordan Brown
<openscad@jordan.maileater.net> wrote:
I notice that your _profileF() ends up generating an
inside-out polyhedron. When viewed with View/Thrown Together,
it's purple. That can cause problems for rendering. (I'm a
little surprised that it didn't cause fatal problems.) It
looks like you can fix it by swapping the second and third
points in both tI and tO.
Another thing attracted my attention immediately.
Mostly, just don't use $fn except to create regular
polygons. Use $fs and $fa; they are much less likely to lead
you into silly settings.
You have $fn=16*360 = 5760. Assuming that the units are
millimeters, the model is about 100mm in diameter, so its
circumference is 314mm. That means that each side is 0.05mm.
Those tiny sides, and the even tinier artifacts that they
might cause, might well be a key part of your geometry
problems. My bet is that you could use fewer than 100 sides
and still be unable to see or feel the individual sides when
you print it. And if you can see them, bump it up to 300 or
500, and you've still got 10x fewer sides than your version does.
Preview is (at least for me) horribly laggy when you try to
move it, and it has what look like convexity artifacts.
Removing all of the settings for $fn and adding in a single
global setting for $fa=1 and $fs=1, and it previews fast and
fixes the convexity artifacts.
Also, a tidbit: _chamferF() generates a conical figure that
might as well be a cone.
up(_conic + _chamferHeight) scale(1.5) zcyl(h =
_toothHeight/2 + _conic, r1 = _or, r2 = 0, anchor=TOP);
Since it's anchored at the top, I didn't have to fiddle with
making sure that it was slightly larger than the thing it's
cutting from and could just scale it up a bit.
I think your technique is responsible for generating micro
flaws at the outside edges.
<YWbsxKvQ36n0OH8f.png>
Note: I first tried this mod while I happened to be running
an OpenSCAD from January. With my changes, rendering failed
with manifold errors. When I switched to a recent build, it
was OK again. So if you're having manifold problems, upgrade.
_______________________________________________
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
An early iteration of the tooth building did about that, hulled 3 cylinders. However I never considered the idea that the “top” cylinder could form the chamfer. I should have thought of that. I got rid of hull and went to skin because the cylinders were fuzzy edges and that bothered me. Skinning 2 2D triangles gave me a precise shape and I am guessing it is extremely efficient. I’g guessing the result has only 8 faces per tooth.
-Bob
On Oct 27, 2024, at 07:15, Harvey white via Discuss discuss@lists.openscad.org wrote:
One way to do this might be pairs of hull plates. use two narrow diameter cylinders as rays, they don't have to meet. That (once a hull) becomes a plate. Create another using the bottom (or top) and with a matching side. Has to be separate hull entities. Rotate as needed. Diameter of cylinder determines rounding of the tooth.
This gives you a crinkled surface. To do a gear tooth, use three cylinders, overlapping at the vertical extents (likely top).
Doesn't solve your problem, but it's an alternate way of doing things.
Harvey
On 10/27/2024 12:35 AM, John David via Discuss wrote:
Thank you, Jordan, I missed the email with the little spear points at the bottom of the tooth profile, and the original pictures it was not clear what the problem was. This helps me look at what is going on... The last time I had something like this, I made a parametric profile and then extruded it, and it worked around the issue. Maybe a trick like that might work to clean it up. That said, your zoomed-in example might give folks a go-to geometrical unit-test to track it down. Not sure if there are takers, but this should be archived as a potential debugging test.
Bob, I hear you. If this is fit for your purpose, then it is "good enough". There comes a point where spending time fixing some things is a diminishing returns game. I still think this should be formally submitted in a bug report, and see if it can be reduced to 2 teeth profiles as the whole of the part. This would be small enough to be debuggable, and large enough to expose the bug.
EBo --
On Sat, Oct 26, 2024 at 10:51 PM Sanjeev Prabhakar via Discuss discuss@lists.openscad.org wrote:
here is my version of this through python
https://youtu.be/Wp8q71eMqrE
On Sun, 27 Oct 2024 at 06:15, Bob Carlson via Discuss
<discuss@lists.openscad.org> wrote:
Thanks! I hear about these point ordering problems. It seems a
shame one has to deal with them. Why can’t they be fixed
automatically?
-Bob
On Oct 26, 2024, at 16:21, Jordan Brown
<openscad@jordan.maileater.net> wrote:
I notice that your _profileF() ends up generating an
inside-out polyhedron. When viewed with View/Thrown Together,
it's purple. That can cause problems for rendering. (I'm a
little surprised that it didn't cause fatal problems.) It
looks like you can fix it by swapping the second and third
points in both tI and tO.
Another thing attracted my attention immediately.
Mostly, just don't use $fn except to create regular
polygons. Use $fs and $fa; they are much less likely to lead
you into silly settings.
You have $fn=16*360 = 5760. Assuming that the units are
millimeters, the model is about 100mm in diameter, so its
circumference is 314mm. That means that each side is 0.05mm.
Those tiny sides, and the even tinier artifacts that they
might cause, might well be a key part of your geometry
problems. My bet is that you could use fewer than 100 sides
and still be unable to see or feel the individual sides when
you print it. And if you can see them, bump it up to 300 or
500, and you've still got 10x fewer sides than your version does.
Preview is (at least for me) horribly laggy when you try to
move it, and it has what look like convexity artifacts.
Removing all of the settings for $fn and adding in a single
global setting for $fa=1 and $fs=1, and it previews fast and
fixes the convexity artifacts.
Also, a tidbit: _chamferF() generates a conical figure that
might as well be a cone.
up(_conic + _chamferHeight) scale(1.5) zcyl(h =
_toothHeight/2 + _conic, r1 = _or, r2 = 0, anchor=TOP);
Since it's anchored at the top, I didn't have to fiddle with
making sure that it was slightly larger than the thing it's
cutting from and could just scale it up a bit.
I think your technique is responsible for generating micro
flaws at the outside edges.
<YWbsxKvQ36n0OH8f.png>
Note: I first tried this mod while I happened to be running
an OpenSCAD from January. With my changes, rendering failed
with manifold errors. When I switched to a recent build, it
was OK again. So if you're having manifold problems, upgrade.
_______________________________________________
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
Thanks for the response.
On Oct 26, 2024, at 21:31, Jordan Brown openscad@jordan.maileater.net wrote:
And then when OpenSCAD receives the "inside-out" polyhedron, it could perhaps fix it. I think that if it's completely inside out then detecting that and fixing it isn't hard. (But right now I'm not sure how to tell which way is "inside".) If it's partially inside-out (like one face is backwards) then I think I know how to detect that, and I guess that if you can detect it then you can flip faces until they are all consistent, and then you might be inside-out but you've reduced it to the case above. So my not-a-geometry-wizard sense is that it's doable. (OCD note: you need to watch out for Klein bottles, lest you flip faces infinitely.)
Being somewhat of a geek I read occasional math news in Quanta. This sounds suspiciously like a conjecture that someone will prove or disprove 16 years from now.
-Bob
On Oct 26, 2024, at 16:21, Jordan Brown openscad@jordan.maileater.net wrote:
I notice that your _profileF() ends up generating an inside-out polyhedron. When viewed with View/Thrown Together, it's purple. That can cause problems for rendering. (I'm a little surprised that it didn't cause fatal problems.) It looks like you can fix it by swapping the second and third points in both tI and tO.
Excellent! Thanks! That fixed the problem! I still consider it a bug that OpenSCAD does not detect the problem. I’ll note that in the issue.
I’ll experiment with $fa and $fs. I tend to learn things when I have need for them. This just hadn’t come up before. And it’s why I’m on this email list.
-Bob