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

On Oct 25, 2024, at 17:20, David Phillip Oster via Discuss discuss@lists.openscad.org wrote:


I may be misunderstanding your post, but I pasted the source code you posted into OpenSCAD  2024.03.01 (git e96dd26d5) on macOS, and had no trouble viewing, rendering it, saving it as an .obj file, and slicing the result, without any indication of error in OpenSCAD or PrusaSlicer 2.8.1.

OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org

On Oct 25, 2024, at 17:19, David Phillip Oster via Discuss discuss@lists.openscad.org wrote:

I may be misunderstanding your post, but I pasted the source code you posted into OpenSCAD  2024.03.01 (git e96dd26d5) on macOS, and had no trouble viewing, rendering it, saving it as an .obj file, and slicing the result, without any indication of error in OpenSCAD or PrusaSlicer 2.8.1.

OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org

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

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.

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?

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

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.

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.

The minimum settings that produced no micro flaws that I could see was
$fa = 1; $fs = 0.1;

On 10/27/2024 5:36 PM, Bob Carlson wrote:

What you can see on the screen is very different from what you can see in plastic.  Try some test prints.

Of course, I still like it to look nice and performance isn’t an issue.

Indeed, with Manifold performance is less of an issue than it once was.
But remember that spheres have a complexity that is the square of the
number of sides, so it can get unreasonable pretty fast.

I took my own advice, and did some test prints.  I'd done some in the
past, but not very systematically.

I made three cylinders, each with several vertical sections with different
numbers of sides.  One disk is 100mm in diameter, one 50mm, and one 25mm.
The two smaller ones have 25, 50, 100, and 150 sides; the larger one has
50, 100, 150, and 300 sides.  (I've enclosed the program below, for those
who might want to duplicate the experiment.)

Sides
Angle
Side length
25mm
50mm
100mm
25
14.4°
3.1mm
6.3mm

50
7.2°
1.6mm
3.1mm
6.3mm
100
3.6°
0.8mm
1.6mm
3.1mm
150
2.4°
0.5mm
1mm
2.1mm
300
1.2°

1mm

I've color-coded them red for obvious artifacts, yellow for subtle
artifacts, and green for no visible or feel-able artifacts.  Of course,
that's subjective, but it might give you an idea.

(For those who for whatever reason can't see the colors:  for the 25mm
cylinder the 25 is red and the rest are green. For the 50mm cylinder the 25
is red, 50 is yellow, and larger are green.  For the 100mm cylinder, 50 is
red and the others are green.)

I should probably do additional samples for larger and smaller cylinders,
but this is still interesting.

I was interested to see that the 50-gon was OK at a smaller size, but
increasingly bad as the size increased.  My intuition was that past some
size more sides doesn't help, because the angle between the sides is what
you'd perceive, but I don't seem to have found that size yet.

100mm isn't the largest circle I can print, and of course I can print arcs
that are arbitrarily large diameter, but this suggests that $fa=3 or so is
good enough for most things, and that $fs doesn't need to be less than
about 1.  $fa might need to be smaller for still-larger circles, and $fs
might need to be smaller for smaller circles.

Here's what the test cylinders look like:

Here's the test program:

include <BOSL2/std.scad>

// For the text
$fa = 2;
$fs = 1;

sides = [ 150, 100, 50, 25 ];
layerT = 6;        // Thickness of each layer
d = 50;            // Diameter
textT = 0.4;        // Thickness of text on the side
topTextT = 0.6;    // Thickness of text on the top
topTextSize = 6;    // Size of text on the top

// Draw a label wrapped around the cylinder
module clabel(text) {
path = up(layerT/2, path3d(reverse(circle(d=d))));
path_text(path, text, size=layerT0.8, textmetrics=true, valign="center", h=textT2+2, offset=-1, center=true);
}

for (i=[0:len(sides)-1]) translate([0,0,ilayerT]) {
fn = sides[i];
zcyl(d=d, h=layerT, anchor=BOTTOM, $fn=fn);
rotate(0) clabel(str(fn));
rotate(120) clabel(str(round(360/fn10)/10, "°"));
rotate(-120) clabel(str(round(PId/fn10)/10, "mm"));
}
up(len(sides)*layerT) text3d(str(d, "mm"), atype="ycenter", anchor=BOTTOM, h=topTextT, size=topTextSize);

OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org

On 10/27/2024 5:36 PM, Bob Carlson wrote:

What you can see on the screen is very different from what you can see in plastic.  Try some test prints.

Of course, I still like it to look nice and performance isn’t an issue.

Indeed, with Manifold performance is less of an issue than it once was.
But remember that spheres have a complexity that is the square of the
number of sides, so it can get unreasonable pretty fast.

I took my own advice, and did some test prints.  I'd done some in the
past, but not very systematically.

I made three cylinders, each with several vertical sections with different
numbers of sides.  One disk is 100mm in diameter, one 50mm, and one 25mm.
The two smaller ones have 25, 50, 100, and 150 sides; the larger one has
50, 100, 150, and 300 sides.  (I've enclosed the program below, for those
who might want to duplicate the experiment.)

Sides
Angle
Side length
25mm
50mm
100mm
25
14.4°
3.1mm
6.3mm

50
7.2°
1.6mm
3.1mm
6.3mm
100
3.6°
0.8mm
1.6mm
3.1mm
150
2.4°
0.5mm
1mm
2.1mm
300
1.2°

1mm

I've color-coded them red for obvious artifacts, yellow for subtle
artifacts, and green for no visible or feel-able artifacts.  Of course,
that's subjective, but it might give you an idea.

(For those who for whatever reason can't see the colors:  for the 25mm
cylinder the 25 is red and the rest are green. For the 50mm cylinder the 25
is red, 50 is yellow, and larger are green.  For the 100mm cylinder, 50 is
red and the others are green.)

I should probably do additional samples for larger and smaller cylinders,
but this is still interesting.

I was interested to see that the 50-gon was OK at a smaller size, but
increasingly bad as the size increased.  My intuition was that past some
size more sides doesn't help, because the angle between the sides is what
you'd perceive, but I don't seem to have found that size yet.

100mm isn't the largest circle I can print, and of course I can print arcs
that are arbitrarily large diameter, but this suggests that $fa=3 or so is
good enough for most things, and that $fs doesn't need to be less than
about 1.  $fa might need to be smaller for still-larger circles, and $fs
might need to be smaller for smaller circles.

Here's what the test cylinders look like:

Here's the test program:

include <BOSL2/std.scad>

// For the text
$fa = 2;
$fs = 1;

sides = [ 150, 100, 50, 25 ];
layerT = 6;        // Thickness of each layer
d = 50;            // Diameter
textT = 0.4;        // Thickness of text on the side
topTextT = 0.6;    // Thickness of text on the top
topTextSize = 6;    // Size of text on the top

// Draw a label wrapped around the cylinder
module clabel(text) {
path = up(layerT/2, path3d(reverse(circle(d=d))));
path_text(path, text, size=layerT0.8, textmetrics=true, valign="center", h=textT2+2, offset=-1, center=true);
}

for (i=[0:len(sides)-1]) translate([0,0,ilayerT]) {
fn = sides[i];
zcyl(d=d, h=layerT, anchor=BOTTOM, $fn=fn);
rotate(0) clabel(str(fn));
rotate(120) clabel(str(round(360/fn10)/10, "°"));
rotate(-120) clabel(str(round(PId/fn10)/10, "mm"));
}
up(len(sides)*layerT) text3d(str(d, "mm"), atype="ycenter", anchor=BOTTOM, h=topTextT, size=topTextSize);

OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org

PrusaSlicer has an Arc Fitting option that is default on in recent
versions.  It's not clear to me if it actually smooths the arcs (and
influences your results) or if the G2/G3 commands are just shorthand
for a large number of G1 commands. 

On 10/28/2024 3:31 AM, Dan Perry via Discuss wrote:

PrusaSlicer has an Arc Fitting option that is default on in recent
versions.  It's not clear to me if it actually smooths the arcs (and
influences your results) or if the G2/G3 commands are just shorthand for a
large number of G1 commands.

Hmm.  I did look for that, but for me it generated G1s.  I found the
option; it's disabled for me.

If it's generating a single G2/G3 for an arc, that's interpreted at the
printer and so can't be a shorthand for the original segments.  (Where
would the information about the segments be?)  The printer interprets it as
it chooses, probably close to its native resolution.

OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org

How well the filament interpolates the curve depends on its viscosity
and the extrusion width. For example ABS smooths curves better than PLA.

How noticeable the facets are depends on how shiny the filament is as
you tend to notice the discontinuities in specular highlights more
than a subtle change in angle when looking from the edge.

I set $fs to half my extrusion width as it isn't really possible to
print details shorter than that and $fa to 6 for most things. I reduce
$fa if I am milling or printing things that have some aesthetic merit
rather than just functional.

Sounds like it would break polyholes which is what I use to get holes
the correct size.

BOSL2 could generate the polyhedron "correctly".  I don't know how hard

what swapping the points does:  it causes BOSL2 to build the polyhedron

enough about "skin" to know how easy it would be to detect being

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.

OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org

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

The second is that I think your code measures tooth angle relative to the
vertical instead of relative to the tooth ridge.  This is not the normal
way that tooth angle would be measured, e.g. on a gear.  It means that
actual angle is never what you specify.

A third observation is that you should be chamfering the valleys just like
the peaks.  Internal corners are stress concentration points on an object
and will weaken it.  So my version can apply varying chamfers in both
places.

On Oct 26, 2024, at 16:21, Jordan Brown openscad@jordan.maileater.net wrote:

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.

On Oct 28, 2024, at 21:35, Adrian Mariano avm4@cornell.edu wrote:

So Bob, you have said you don't care about speed, which is your choice, obviously.  But for me this code is intolerably slow.  Preview is useless even after I remove the chamfering and intersection to make it have cylindrical edges.  And render takes 20s with manifold.  Because the original code was unpreviewable I couldn't easily assess how well my rewrite matched, but it previews instantly and renders in 0.1s.  (Note: a reason I care about preview is that I can color things that I overlay to see for example if two things match.)

Another few things.  In BOSL2, global variables that start with underscore are reserved for BOSL2 internal use, so you shouldn't be using those.  You could clobber an internal definition.  (Not sure why anyone would use variables that start with underscore as a choice---I find them very annoying.)

The second is that I think your code measures tooth angle relative to the vertical instead of relative to the tooth ridge.  This is not the normal way that tooth angle would be measured, e.g. on a gear.  It means that actual angle is never what you specify.

A third observation is that you should be chamfering the valleys just like the peaks.  Internal corners are stress concentration points on an object and will weaken it.  So my version can apply varying chamfers in both places.

I personally find the rewritten code simpler than the original, as well as much faster, and there's probably room to clean it up more.  (Could probably compute inner shape from outer with a scale() computation for example.)  It does produce a polygonal result and could be intersected with a tube like the original to fix that if you think it's necessary.  I imagine that one intersection wouldn't be a major drag on the speed.  I agree that trying to compute the profile on a circular arc would be a pain.

include <BOSL2/std.scad>

// Number of Teeth
_n = 36;          // Number Of Teeth

// Inner Radius
_ir = 30;
// Outer Radius
_or = 50;
// Is the coupling conical?
_conic = 15;
// Tooth Profile Angle
_profile = 90; // [60, 90]
// Percentage of tooth height
_chamfer = 5; // Default 5%
_base = 1;

function basic_profile(angle,chamfer_top, chamfer_bot) =
let(
width = tan(angle/2),
pts = [
[0,(-1+chamfer_bot)width,chamfer_bot],
[0,-chamfer_topwidth,1-chamfer_top]
],
)
concat(pts, reverse(yflip(pts)));

profwidth = tan(_profile/2);
outside = _ortan(180/_n);
inside = _irtan(180/_n);

prof_out = right(_or,scale(outside/profwidth,basic_profile(_profile, _chamfer/100, _chamfer/200)));
prof_in = right(_ir,scale(inside/profwidth,basic_profile(_profile, _chamfer/100, _chamfer/200)));

offset = (_or-_ir) * tan(_conic);

outfull = up(offset,[for(i=lerpn(0,360,_n,endpoint=false))
each zrot(i,prof_out)]);
infull = [for(i=lerpn(0,360,_n,endpoint=false))
each zrot(i,prof_in)];

inbot = [for(val=infull) [val.x,val.y,-_base]];
outbot = [for(val=outfull) [val.x,val.y,-_base]];

vnf_polyhedron(vnf_vertex_array([outfull, infull, inbot, outbot], reverse=true, col_wrap=true, row_wrap=true));

<image.png>

An anticone needs rotate_extrude?

On 10/30/2024 10:32 PM, Caddiy via Discuss wrote:

An anticone needs rotate_extrude?

I wouldn't call either of those shapes cones; I would call the first a
cylinder from which a point-down cone has been subtracted, and the second a
point-up cone from which a cylinder has been subtracted.

You could build either of them with rotate_extrude(), as you have, or you
could build them as the differences above.  Which is "best" probably
depends on whether what you have convenient is the coordinates of the inner
edge, or the coordinates of the point of the cone.

I'd give you difference-between-cone-and-cylinder examples, but I don't
have the coordinates of the point of the cone handy.  I'd have to
extrapolate from the upper side of the triangles.  That's not hard, but
it's midnight and I don't wanna :-)

OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org

This discussion on the cone is interesting.  I had to look it up:

  "The meaning of CONE is a solid generated by rotating a right
triangle about one of its legs —called also right circular cone."
        -- Merriam-Webster  Dictionary

But in the smithy we used to use both solid and hollow "cones" and not
all of them went to a full point. Then I remembered that a truncated
cone is called a 'frustum'...

All that said, I can see defining a primitive which creates both solid
and hollow cones and frustums, and the code snippet above shows how
simple that code can be.  Maybe it would even be fast ;-)

  EBo --

I think cylinder already does that. If you specify two radii you get a
frustum. I can't remember if zero is allowed for a cone.

To cut a long story short, a polygon can give you the filler-cone plus
a bit more in one piece, which a primitive cone can’t.

A conical face spline joint will need two different cones as fillers
to get a flat face at the back of each piece. One piece, with luck or
by design, may already have a flat face, or it may even be conical,
requiring a negative/hollow cone, that I’m calling an anticone, to get
a flat face. But neither a primitive cone nor a BOSL2 cone can handle
a negative “h”.

On Oct 31, 2024, at 12:36, Caddiy via Discuss discuss@lists.openscad.org wrote:

Jordan Brown wrote:

To cut a long story short, a polygon can give you the filler-cone plus a bit more in one piece, which a primitive cone can’t.

Sort of.  It depends on what your requirements are for the "plus a bit more".

If your cone is anchored at the top, scaling it up will expand it at the base without changing the shape of the top.

This is easy to demonstrate with BOSL2, because you can natively anchor at the top:

include <BOSL2/std.scad>

s = 1;
scale(s) zcyl(r1=10, r2=0, h=10, anchor=TOP);
as you change s, observe that the top portion of the cone stays the same.

It's a tiny bit more complex in base OpenSCAD because base OpenSCAD cylinders are anchored at their bottoms or centers.

s = 1;
h = 10;
scale(s) translate([0,0,-h]) cylinder(r1=10, r2=0, h=h);
(Though you can demonstrate it with an upside-down cone without needing a translate().)

It even retains the same number of sides as it grows, because cylinder() decides on the number of sides when it creates the object, and scale() doesn't affect that choice.

In the particular case that this came from, the user was already using BOSL2, and it happened that the top of the cone was easy to know, and that since it was cutting away past the bottom of the object the shape of the "extra" didn't matter.  Net, that negative object could be a straightforward cone anchored at its top.

A conical face spline joint will need two different cones as fillers to get a flat face at the back of each piece. One piece, with luck or by design, may already have a flat face, or it may even be conical, requiring a negative/hollow cone, that I’m calling an anticone, to get a flat face. But neither a primitive cone nor a BOSL2 cone can handle a negative “h”.

A polygon can. (The polygon is then rotate-extruded to form the desired anticone.)

I wonder, though, how many Hirth joints are conical and why. A conical joint seems like an unnecessary complication, as a plain joint already self-centres very precisely.

OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org mailto:discuss-leave@lists.openscad.org

I have encountered exactly one hirth spline IRL and it was conical. I made
some attachments for my golf cart (carries just my bag). The spot where
options are attached has a hirth spline to prevent rotation of the things
attached. It is conical, 60 teeth and 35 mm in D. I made a matching part
without understanding anything about the hirth spline or knowing the name.

It seems obvious that the cone shape makes it easier to center the parts
by hand as you put new attachments on.

• Bob

On Oct 31, 2024, at 12:36, Caddiy via Discuss discuss@lists.openscad.org
wrote:

Jordan Brown wrote:

To cut a long story short, a polygon can give you the filler-cone plus a
bit more in one piece, which a primitive cone can’t.

Sort of.  It depends on what your requirements are for the "plus a bit
more".

If your cone is anchored at the top, scaling it up will expand it at the
base without changing the shape of the top.

This is easy to demonstrate with BOSL2, because you can natively anchor at
the top:

include <BOSL2/std.scad>

s = 1;
scale(s) zcyl(r1=10, r2=0, h=10, anchor=TOP);

as you change s, observe that the top portion of the cone stays the same.

It's a tiny bit more complex in base OpenSCAD because base OpenSCAD
cylinders are anchored at their bottoms or centers.

s = 1;
h = 10;
scale(s) translate([0,0,-h]) cylinder(r1=10, r2=0, h=h);

(Though you can demonstrate it with an upside-down cone without needing a
translate().)

It even retains the same number of sides as it grows, because cylinder()
decides on the number of sides when it creates the object, and scale()
doesn't affect that choice.

In the particular case that this came from, the user was already using
BOSL2, and it happened that the top of the cone was easy to know, and that
since it was cutting away past the bottom of the object the shape of the
"extra" didn't matter.  Net, that negative object could be a
straightforward cone anchored at its top.

A conical face spline joint will need two different cones as fillers to
get a flat face at the back of each piece. One piece, with luck or by
design, may already have a flat face, or it may even be conical, requiring
a negative/hollow cone, that I’m calling an anticone, to get a flat face.
But neither a primitive cone nor a BOSL2 cone can handle a negative “h”.

A polygon can. (The polygon is then rotate-extruded to form the desired
anticone.)

I wonder, though, how many Hirth joints are conical and why. A conical
joint seems like an unnecessary complication, as a plain joint already
self-centres very precisely.

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