Rounding the edges
Even easier and faster, if you only want vertical edges rounded:
include <BOSL2/std.scad>
linear_extrude(height=10)
hexagon(r=10, rounding=1.5, $fn=36);
-Revar
On Jan 20, 2022, at 5:53 PM, Adrian Mariano avm4@cornell.edu wrote:
There's nothing wrong with the hull of 12 sphere originally proposed,
though I think it might be slow if you don't use lazy union. But if
you want to branch out into totally different territory, here are two
ways to do this with BOSL2:
This example uses continuous curvature rounding, so the curves are not circular:
include<BOSL2/std.scad>
include<BOSL2/rounding.scad>
rounded_prism(circle(r=10,$fn=6), h=10, joint_top=1.5, joint_bot=1.5,
joint_sides=1.5);
or alternatively you can use offset_sweep which can do things like
teardrop rounding at the bottom for 3d printability, or you can
substitute os_circle for the bottom and get circles all around.
include<BOSL2/std.scad>
include<BOSL2/rounding.scad>
offset_sweep(hexagon(r=10,rounding=1,$fn=48), h=10,
top=os_circle(r=1), bottom=os_teardrop(r=1));
On Thu, Jan 20, 2022 at 8:40 PM FF Systems joeh@rollanet.org wrote:
Of course, you'd definitely want to use named constants and perform the calculations so that the model was maintainable. You can also fix the height of the rounding cylinder to add some symmetry to the code:
sw=1;
radius = 20;
height = 10;
scham_rad = 1; // the rounded edge radius
if(sw==1){
minkowski(){
cylinder(h=height-(scham_rad), r=radius-(1*scham_rad), $fn=6);
cylinder(h= scham_rad, r=scham_rad , $fn=32);
}
}
if(sw==2){
cylinder(h=height,r=radius, $fn=6);
}
Note that there is a slight difference in the size of the resulting shape (you can see it by setting sw to 1 or 2 and recompiling). This is the price of using minkowski and a low-order ($fn < 16) kernel shape. The radius of the rounding shape adds differently across the x-axis points than it does across the y-axis flats.
If you need the shape to be exactly as it was originally, my only other option would be to difference() the corners with a cube and fill the removed shape with precisely located cylinders. Tricky and painstaking.
If someone has a better solution than the above, I am also open to hearing about it as I am always rounding or chamfering edges.
On Thu, Jan 20, 2022 at 7:16 PM FF Systems joeh@rollanet.org wrote:
I've used "minkowski()" for that. It requires a bit of care as it will "grow" the final object by the sum of the child objects, so one needs to adjust dimensions and verify the result.
Assume your height was to be 5 and radius 20. This gives rounded corners:
minkowski(){
cylinder(h=2.5,r=18, $fn=6);
cylinder(h=2.5,r=1, $fn=32);
}
If you want all edges rounded:
minkowski(){
cylinder(h=3,r=18, $fn=6);
sphere(r=1, $fn=32);
}
Note how the dimensions add differently depending on the type of rounding shape used.
Hope that helps.
On Thu, Jan 20, 2022 at 7:05 PM david vanhorn kc6ete@gmail.com wrote:
I have a hex with all sharp edges:
cylinder(h=GuardEdgeThickness,r=GuardRadius, $fn=6);
How can I round the edges a bit. Maybe 1 or 2 mm radius is all I need.
I think I may be forced to create two hexagonal arrays of spheres and hull them.
Is there an easier way?
--
K1FZY (WA4TPW) SK 9/29/37-4/13/15
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
Obviously I've missed some things, what is the std.scad file?
On Fri, Jan 21, 2022 at 5:34 AM Revar Desmera revarbat@gmail.com wrote:
Even easier and faster, if you only want vertical edges rounded:
include <BOSL2/std.scad>
linear_extrude(height=10)
hexagon(r=10, rounding=1.5, $fn=36);
-Revar
On Jan 20, 2022, at 5:53 PM, Adrian Mariano avm4@cornell.edu wrote:
There's nothing wrong with the hull of 12 sphere originally proposed,
though I think it might be slow if you don't use lazy union. But if
you want to branch out into totally different territory, here are two
ways to do this with BOSL2:
This example uses continuous curvature rounding, so the curves are not
circular:
include<BOSL2/std.scad>
include<BOSL2/rounding.scad>
rounded_prism(circle(r=10,$fn=6), h=10, joint_top=1.5, joint_bot=1.5,
joint_sides=1.5);
or alternatively you can use offset_sweep which can do things like
teardrop rounding at the bottom for 3d printability, or you can
substitute os_circle for the bottom and get circles all around.
include<BOSL2/std.scad>
include<BOSL2/rounding.scad>
offset_sweep(hexagon(r=10,rounding=1,$fn=48), h=10,
top=os_circle(r=1), bottom=os_teardrop(r=1));
On Thu, Jan 20, 2022 at 8:40 PM FF Systems joeh@rollanet.org wrote:
Of course, you'd definitely want to use named constants and perform the
calculations so that the model was maintainable. You can also fix the
height of the rounding cylinder to add some symmetry to the code:
sw=1;
radius = 20;
height = 10;
scham_rad = 1; // the rounded edge radius
if(sw==1){
minkowski(){
cylinder(h=height-(scham_rad), r=radius-(1*scham_rad), $fn=6);
cylinder(h= scham_rad, r=scham_rad , $fn=32);
}
}
if(sw==2){
cylinder(h=height,r=radius, $fn=6);
}
Note that there is a slight difference in the size of the resulting shape
(you can see it by setting sw to 1 or 2 and recompiling). This is the
price of using minkowski and a low-order ($fn < 16) kernel shape. The
radius of the rounding shape adds differently across the x-axis points than
it does across the y-axis flats.
If you need the shape to be exactly as it was originally, my only other
option would be to difference() the corners with a cube and fill the
removed shape with precisely located cylinders. Tricky and painstaking.
If someone has a better solution than the above, I am also open to hearing
about it as I am always rounding or chamfering edges.
On Thu, Jan 20, 2022 at 7:16 PM FF Systems joeh@rollanet.org wrote:
I've used "minkowski()" for that. It requires a bit of care as it will
"grow" the final object by the sum of the child objects, so one needs to
adjust dimensions and verify the result.
Assume your height was to be 5 and radius 20. This gives rounded corners:
minkowski(){
cylinder(h=2.5,r=18, $fn=6);
cylinder(h=2.5,r=1, $fn=32);
}
If you want all edges rounded:
minkowski(){
cylinder(h=3,r=18, $fn=6);
sphere(r=1, $fn=32);
}
Note how the dimensions add differently depending on the type of rounding
shape used.
Hope that helps.
On Thu, Jan 20, 2022 at 7:05 PM david vanhorn kc6ete@gmail.com wrote:
I have a hex with all sharp edges:
cylinder(h=GuardEdgeThickness,r=GuardRadius, $fn=6);
How can I round the edges a bit. Maybe 1 or 2 mm radius is all I need.
I think I may be forced to create two hexagonal arrays of spheres and hull
them.
Is there an easier way?
--
K1FZY (WA4TPW) SK 9/29/37-4/13/15
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
--
K1FZY (WA4TPW) SK 9/29/37-4/13/15
On 1/21/2022 5:23 AM, david vanhorn wrote:
Obviously I've missed some things, what is the std.scad file?
Part of the BOSL2 library.
https://github.com/revarbat/BOSL2
On Fri, Jan 21, 2022 at 5:34 AM Revar Desmera revarbat@gmail.com wrote:
Even easier and faster, if you only want vertical edges rounded:
include <BOSL2/std.scad>
linear_extrude(height=10)
hexagon(r=10, rounding=1.5, $fn=36);
-Revar
On 1/21/2022 1:35 AM, david vanhorn wrote:
Hex = (360/6);// Despite what I was told all through school, reducing
the fraction is not always necessary. :)
Absolutely. Keep the values in forms that are the most obvious to you,
and let the computer do the arithmetic.
// I could wrap these up in a for loop, but didn't want to fool with
that yet. I haven't actually used a for loop in OpenSCAD yet.
They behave pretty obviously, until you realize the full implications of
"nothing ever escapes from its scope". Values set in a loop do not
persist to the next iteration of the loop, nor do they persist past the
end of the loop.
x = 1;
for (i=[1:3]) {
x = x + 1;
echo(x);
}
echo(x);
yields
ECHO: 2
ECHO: 2
ECHO: 2
ECHO: 1
Note: some will tell you that you can't say "x=x+1". That's not
entirely accurate https://www.youtube.com/watch?v=SEbwZfkeIt8. You
can't change the value of a "variable". But in a new scope you can
define a new variable with the same name as a variable from an outer
scope - and that new definition can use the outer-scope value.
What happens here is that in the top scope x gets a value of 1. Then
during the first iteration of the loop it takes that top-scope value of
1, adds 1 to it, and creates a new x for the scope of that iteration,
with a value of 2. On the second iteration it again takes the top-scope
value of 1, et cetera. When the loop completes, the iteration scopes
are gone and the top-scope value is once again visible.
(Some will claim that C-style for loops let you change values. I claim
that they form tail-recursive scopes.)
My $0.02 worth (and maybe not even worth that much)... I claim that the
problem with scopes and variables is semantics.
C uses variables, but SCAD actually uses constants. Constants can't be
changed, variables can. Thus, the two paradigms can't be compared even
though there are many other instances where it is perfectly OK to draw
comparisons between the two. So, my solution would be to stop using the
term "variables" in SCAD and use the term "constants" or "named
constants". Not that I expect this to happen, of course.
On the subject of minkowski()... I don't have enough experience with it to
confirm or deny any potential overhead issues except that my use of the
BOSL thread libs and another non-BOSL thread lib is that these constructs
represented a very noticeable overhead to the view and render engines. I
haven't gotten that impression from using minkowski() (yet) but again,
limited experience.
From a coding perspective, the simplicity of minkowski() vs. some of the
other examples is HUGE, IMO. The main burden with minkowski() from a
purely design-oriented perspective is that it takes care and experience to
"adjust" the child dimensions to get the aggregate shape to be EXACTLY the
size you want. In some cases, this is not too difficult. In the case of
the OPs example, it required a trip to the whiteboard and several minutes
of trig and geometry to figure out the exact transform values (I got within
a few percent of the solution just using visual tweaks, but then had to
answer WHY??) - this would be required for any non circular, non-square
shape that one might choose as a child of minkowski(). It is this aspect
of minkowski() that leaves the most to be desired, IMO - but knowing the
limits makes it manageable (also, IMO).
This opinion lacks the benefit of many of the BOSL lib tools, as I have
only recently discovered their existence. Perhaps there are coding
structures that are as simple, or nearly so, WRT minkowski(). Time shall
tell, I suppose. My point is that there are times when coding simplicity
carries more weight than some of the other considerations.
On Fri, Jan 21, 2022 at 10:32 AM Jordan Brown openscad@jordan.maileater.net
wrote:
On 1/21/2022 1:35 AM, david vanhorn wrote:
Hex = (360/6);// Despite what I was told all through school, reducing the
fraction is not always necessary. :)
Absolutely. Keep the values in forms that are the most obvious to you,
and let the computer do the arithmetic.
// I could wrap these up in a for loop, but didn't want to fool with that
yet. I haven't actually used a for loop in OpenSCAD yet.
They behave pretty obviously, until you realize the full implications of
"nothing ever escapes from its scope". Values set in a loop do not
persist to the next iteration of the loop, nor do they persist past the end
of the loop.
x = 1;
for (i=[1:3]) {
x = x + 1;
echo(x);
}
echo(x);
yields
ECHO: 2
ECHO: 2
ECHO: 2
ECHO: 1
Note: some will tell you that you can't say "x=x+1". That's not entirely
accurate https://www.youtube.com/watch?v=SEbwZfkeIt8. You can't change
the value of a "variable". But in a new scope you can define a new
variable with the same name as a variable from an outer scope - and that
new definition can use the outer-scope value.
What happens here is that in the top scope x gets a value of 1. Then
during the first iteration of the loop it takes that top-scope value of 1,
adds 1 to it, and creates a new x for the scope of that iteration, with a
value of 2. On the second iteration it again takes the top-scope value of
1, et cetera. When the loop completes, the iteration scopes are gone and
the top-scope value is once again visible.
(Some will claim that C-style for loops let you change values. I claim
that they form tail-recursive scopes.)
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
I think it's silly to say regarding constants vs. variables that "the
two paradigms can't be compared". Of course they can be compared.
And they should be, or people won't understand what's going on when
they see x=x+1 in an OpenSCAD program. Precisely because they are
different, we need to compare them.
Minkowski is a nice tool in principle, but it starts to get less
simple to code if you want variable rounding, or if your part is
complex. I'm perhaps biased here, but I think that the BOSL2 rounding
methods are more direct, since you can just describe the object you
want and how you want it rounded instead of fussing with making
epsilon thick objects and then applying minkowski, as I have done in
the past. The rounded_prism() module, for example, lets you round
every side edge with a different rounding value and the top and bottom
edges also with different values, so there's a flexibility that is
very difficult to obtain using Minkowski (though perhaps achievable
with hull). But the real problem with minkowski is performance.
Simple polyhedra, such as the example in this thread, run fast with
Minkowski. But it doesn't take much for minkowski to become
ridiculously, unusably slow. My first real model takes over 20
minutes to preview due to the use of minkowski. (And one person
complained that it took an hour on their system.) There is a way to
write a generic rounding module that calls minkowski 3 times and when
I ran it on an example featuring a cylinder intersecting a cube at an
arbitrary angle it ran for an hour or two and then crashed OpenSCAD.
This performance situation basically relegates minkowski() to toy
status in my opinion. You can use it for a few simple cases, but for
real models, it has real problems. Note that if you do want to do
comparisons of performance, make sure it's apples-to-apples, namely
that you are using the same number of segments on both models so that
the comparison is fair.
On Fri, Jan 21, 2022 at 12:51 PM FF Systems joeh@rollanet.org wrote:
My $0.02 worth (and maybe not even worth that much)... I claim that the problem with scopes and variables is semantics.
C uses variables, but SCAD actually uses constants. Constants can't be changed, variables can. Thus, the two paradigms can't be compared even though there are many other instances where it is perfectly OK to draw comparisons between the two. So, my solution would be to stop using the term "variables" in SCAD and use the term "constants" or "named constants". Not that I expect this to happen, of course.
On the subject of minkowski()... I don't have enough experience with it to confirm or deny any potential overhead issues except that my use of the BOSL thread libs and another non-BOSL thread lib is that these constructs represented a very noticeable overhead to the view and render engines. I haven't gotten that impression from using minkowski() (yet) but again, limited experience.
From a coding perspective, the simplicity of minkowski() vs. some of the other examples is HUGE, IMO. The main burden with minkowski() from a purely design-oriented perspective is that it takes care and experience to "adjust" the child dimensions to get the aggregate shape to be EXACTLY the size you want. In some cases, this is not too difficult. In the case of the OPs example, it required a trip to the whiteboard and several minutes of trig and geometry to figure out the exact transform values (I got within a few percent of the solution just using visual tweaks, but then had to answer WHY??) - this would be required for any non circular, non-square shape that one might choose as a child of minkowski(). It is this aspect of minkowski() that leaves the most to be desired, IMO - but knowing the limits makes it manageable (also, IMO).
This opinion lacks the benefit of many of the BOSL lib tools, as I have only recently discovered their existence. Perhaps there are coding structures that are as simple, or nearly so, WRT minkowski(). Time shall tell, I suppose. My point is that there are times when coding simplicity carries more weight than some of the other considerations.
On Fri, Jan 21, 2022 at 10:32 AM Jordan Brown openscad@jordan.maileater.net wrote:
On 1/21/2022 1:35 AM, david vanhorn wrote:
Hex = (360/6);// Despite what I was told all through school, reducing the fraction is not always necessary. :)
Absolutely. Keep the values in forms that are the most obvious to you, and let the computer do the arithmetic.
// I could wrap these up in a for loop, but didn't want to fool with that yet. I haven't actually used a for loop in OpenSCAD yet.
They behave pretty obviously, until you realize the full implications of "nothing ever escapes from its scope". Values set in a loop do not persist to the next iteration of the loop, nor do they persist past the end of the loop.
x = 1;
for (i=[1:3]) {
x = x + 1;
echo(x);
}
echo(x);yields
ECHO: 2
ECHO: 2
ECHO: 2
ECHO: 1Note: some will tell you that you can't say "x=x+1". That's not entirely accurate. You can't change the value of a "variable". But in a new scope you can define a new variable with the same name as a variable from an outer scope - and that new definition can use the outer-scope value.
What happens here is that in the top scope x gets a value of 1. Then during the first iteration of the loop it takes that top-scope value of 1, adds 1 to it, and creates a new x for the scope of that iteration, with a value of 2. On the second iteration it again takes the top-scope value of 1, et cetera. When the loop completes, the iteration scopes are gone and the top-scope value is once again visible.
(Some will claim that C-style for loops let you change values. I claim that they form tail-recursive scopes.)
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