Possible bug in minkowski() function?
/Hi everyone,
I'm new and 3D design and I'm designing simple objects. Now I'm trying to
round top and side "faces" of a figure, while leaving bottom side plain.
From the OpenSCAD cheat sheet I've seen that minkowski() function can do so,
by using as rounding pattern the union of a sphere and a cylinder. The
corresponding code is below. Note that the minkowski() function is commented
because I get a memory overflow error. By the way, I'm running OpenSCAD
version 2015.03-2 under Windows 7 on a PC with 12GB of RAM.
/
x_max_boton=80;
x_min_boton=45.5;
y_max_boton=14.6;
y_min_boton=12.6;
z1_boton=15;
z2_boton=16.2;
z3_boton=16;
r_boton=1;
borde_separacion_ext=2;
r_redondeo=0.25;
r_redondeo_top=50;
module Base_Boton(x, y, z)
{
resize([x, y, z]) cylinder($fn = 1000, $fa = 12, $fs = 2, h=z, r=x/2);
}
module Planta_Boton(x_max, x_min, y_max, y_min, z, r)
{
hull()
{
translate([-(x_min/2-r), y_min/2-r, 0]) cylinder($fn = 1000, $fa =
12, $fs = 2, h=z, r=r);
translate([-(x_min/2-r), -(y_min/2-r), 0]) cylinder($fn = 1000, $fa
= 12, $fs = 2, h=z, r=r);
translate([(x_min/2-r), y_min/2-r, 0]) cylinder($fn = 1000, $fa =
12, $fs = 2, h=z, r=r);
translate([(x_min/2-r), -(y_min/2-r), 0]) cylinder($fn = 1000, $fa =
12, $fs = 2, h=z, r=r);
intersection()
{
Base_Boton(x_max, y_max, z);
translate([0, 0, z/2]) cube([x_min-2r-1+0.05, y_max+2, 2z],
true);
}
}
}
module Planta_Hueco_Boton(x_max, x_min, x_new, y_max, y_min, y_new, z,
z_new, r_boton)
{
resize([x_new, y_new, z_new]) Planta_Boton(x_max, x_min, y_max, y_min,
z, r_boton);
}
module Bloque_Boton(x_max_boton, x_min_boton, y_max_boton, y_min_boton,
z1_boton, z2_boton, z3_boton, r_boton, borde_separacion_ext, r_redondeo)
{
z_boton=1;
// minkowski()
// {
// Coloring in red is just to highlight the rounding object
color([1, 0, 0, 1]) union()
{
translate([-(x_min_boton-2*r_redondeo)/2, 0,
z1_boton+r_redondeo]) sphere($fn = 1000, $fa = 12, $fs = 2, r=r_redondeo);
translate([-(x_min_boton-2*r_redondeo)/2, 0, z1_boton])
cylinder($fn = 1000, $fa = 12, $fs = 2, h=r_redondeo, r=r_redondeo);
}
intersection()
{
translate([0-(x_min_boton+4)/2, y_max_boton/6,
-(r_redondeo_top-z2_boton)]) rotate([0, 90, 0]) cylinder($fn = 1000, $fa =
12, $fs = 2, h=x_min_boton+4, r=r_redondeo_top);
translate([0, 0, z1_boton]) Planta_Hueco_Boton(x_max_boton,
x_min_boton, x_min_boton-2r_redondeo, y_max_boton, y_min_boton,
y_max_boton-2r_redondeo, z_boton, 2*z_boton, r_boton);
}
// }
}
Bloque_Boton(x_max_boton, x_min_boton, y_max_boton, y_min_boton, z1_boton,
z2_boton, z3_boton, r_boton, borde_separacion_ext, r_redondeo);
/Surprised, I've tried simplifying the original figure (note the "/* */"
comments). However, I've got a memory overflow again, and thus I've
commented (with "//") the minlowski() function())./
module Bloque_Boton2(x_max_boton, x_min_boton, y_max_boton, y_min_boton,
z1_boton, z2_boton, z3_boton, r_boton, borde_separacion_ext, r_redondeo)
{
z_boton=1;
// minkowski()
// {
// Coloring in red is just to highlight the rounding object
color([1, 0, 0, 1]) union()
{
translate([-(x_min_boton-2*r_redondeo)/2, 0,
z1_boton+r_redondeo-3]) sphere($fn = 1000, $fa = 12, $fs = 2, r=r_redondeo);
translate([-(x_min_boton-2*r_redondeo)/2, 0, z1_boton-3])
cylinder($fn = 1000, $fa = 12, $fs = 2, h=r_redondeo, r=r_redondeo);
}
/* intersection()
{
translate([0-(x_min_boton+4)/2, y_max_boton/6,
-(r_redondeo_top-z2_boton)]) rotate([0, 90, 0]) cylinder($fn = 1000, $fa =
12, $fs = 2, h=x_min_boton+4, r=r_redondeo_top);/
translate([0, 0, z1_boton-3]) Planta_Hueco_Boton(x_max_boton,
x_min_boton, x_min_boton-2r_redondeo, y_max_boton, y_min_boton,
y_max_boton-2r_redondeo, z_boton, 2r_redondeo, r_boton);
/* }*/
// }
}
Bloque_Boton2(x_max_boton, x_min_boton, y_max_boton, y_min_boton, z1_boton,
z2_boton, z3_boton, r_boton, borde_separacion_ext, r_redondeo);
/Well, I think that the original object is quite simple, so I've tried to
round it using only the sphere and the cylinder separately. This is the
version for the sphere. The result: memory overflow again (and the
minkowski() function commented)./
module Bloque_Boton3(x_max_boton, x_min_boton, y_max_boton, y_min_boton,
z1_boton, z2_boton, z3_boton, r_boton, borde_separacion_ext, r_redondeo)
{
z_boton=1;
// minkowski()
// {
// Coloring in red is just to highlight the rounding object
color([1, 0, 0, 1]) translate([-(x_min_boton-2r_redondeo)/2, 0,
z1_boton+r_redondeo-6]) sphere($fn = 1000, $fa = 12, $fs = 2, r=r_redondeo);
/ intersection()
{
translate([0-(x_min_boton+4)/2, y_max_boton/6,
-(r_redondeo_top-z2_boton)]) rotate([0, 90, 0]) cylinder($fn = 1000, $fa =
12, $fs = 2, h=x_min_boton+4, r=r_redondeo_top);/
translate([0, 0, z1_boton-6]) Planta_Hueco_Boton(x_max_boton,
x_min_boton, x_min_boton-2r_redondeo, y_max_boton, y_min_boton,
y_max_boton-2r_redondeo, z_boton, 2r_redondeo, r_boton);
/* }*/
// }
}
Bloque_Boton3(x_max_boton, x_min_boton, y_max_boton, y_min_boton, z1_boton,
z2_boton, z3_boton, r_boton, borde_separacion_ext, r_redondeo);
/Finally, using only the cylinder I got the figure rounded. This is the
corresponding code. Note that I've translated the rounded figure to put it
down the other versions if running all the versions together./
module Bloque_Boton4(x_max_boton, x_min_boton, y_max_boton, y_min_boton,
z1_boton, z2_boton, z3_boton, r_boton, borde_separacion_ext, r_redondeo)
{
z_boton=1;
// The green color is just to distinguish the succesfully rounded figure
from the original figures and rounding shapes
color([0, 1, 0, 1]) translate([(x_min_boton-2r_redondeo)/2, 0, -7])
minkowski()
{
// Coloring in red is just to highlight the rounding object
color([1, 0, 0, 1]) translate([-(x_min_boton-2r_redondeo)/2, 0,
z1_boton-9]) cylinder($fn = 1000, $fa = 12, $fs = 2, h=2r_redondeo,
r=r_redondeo);
/ intersection()
{
translate([0-(x_min_boton+4)/2, y_max_boton/6,
-(r_redondeo_top-z2_boton)]) rotate([0, 90, 0]) cylinder($fn = 1000, $fa =
12, $fs = 2, h=x_min_boton+4, r=r_redondeo_top);/
translate([0, 0, z1_boton-9]) Planta_Hueco_Boton(x_max_boton,
x_min_boton, x_min_boton-2r_redondeo, y_max_boton, y_min_boton,
y_max_boton-2r_redondeo, z_boton, 2r_redondeo, r_boton);
/* }*/
}
}
Bloque_Boton4(x_max_boton, x_min_boton, y_max_boton, y_min_boton, z1_boton,
z2_boton, z3_boton, r_boton, borde_separacion_ext, r_redondeo);
/Can anyone tell me if it is actually a bug, or a problem in my design?
Thanks a lot in advance, and sorry for the length of the post.
jcbaraza/
--
View this message in context: http://forum.openscad.org/Possible-bug-in-minkowski-function-tp18296.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
I did not find any bug. It is not surprising that you got lack of memory
because you specified $fn=1000 in that many cylinders and spheres. You
should be moderate with the number of cylinders and spheres facets if you
intend to minkovski them. Minkovski is very CPU and memory intensive and
things get a lot worst with so many facets.
I got this :
http://forum.openscad.org/file/n18297/Redondeo.png
with the following code:
Bloque_Boton.scad http://forum.openscad.org/file/n18297/Bloque_Boton.scad
The only changes, besides uncommenting the minkovski operation, was:
a) eliminated all $fn = 1000, $fa = 12, $fs = 2 from all cylinders and
spheres, adding a global $fn= 24;
b) after getting a preview, I looked where it was the code of the top face
cylinder and added there $fn=480;
c) finally I raised the global $fn to 120.
The preview took less than 3 min.
You don't need to prescribe all $f values. Just one is taken (see the
manual).
You don't need to prescribe $fn values in all primitives if they are all
equal (see the manual).
You should start with low values of $fn while designing. When it is
finished, rise $fn to a reasonable value.
--
View this message in context: http://forum.openscad.org/Possible-bug-in-minkowski-function-tp18296p18297.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
What he said...
I added the following to the manual
The higher the number of fragments, the more memory and CPU consumed,
large values, will bring many systems to their knees. Depending on the
design, $fn values, and the corresponding results of $fa & $fs, should be
kept small, at least until the design is finalised when it can be
increased for the final result. '''A $fn over 100 is not recommended''' or
only for specific circumstances, and below 50 would be advisable for
performance.
Anyone object to 100/50?
Admin - PM me if you need anything, or if I've done something stupid...
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
View this message in context: http://forum.openscad.org/Possible-bug-in-minkowski-function-tp18296p18298.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Well, it is hard to fix such a limit. In the jcbaraza model, for instance,
its top is a very small fraction of a lied down cylinder surface. With
$fn=100, it appears too faceted. I raised it to $fn=480 to get a rounded
appearance. However, as general recommendation for beginners, I agree.
2016-09-01 23:15 GMT-03:00 MichaelAtOz oz.at.michael@gmail.com:
What he said...
I added the following to the manual
The higher the number of fragments, the more memory and CPU consumed,
large values, will bring many systems to their knees. Depending on the
design, $fn values, and the corresponding results of $fa & $fs, should
be
kept small, at least until the design is finalised when it can be
increased for the final result. '''A $fn over 100 is not recommended'''
or
only for specific circumstances, and below 50 would be advisable for
performance.
Anyone object to 100/50?
Admin - PM me if you need anything, or if I've done something stupid...
Unless specifically shown otherwise above, my contribution is in the
Public Domain; to the extent possible under law, I have waived all
copyright and related or neighbouring rights to this work. Obviously
inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it!
http://www.ourfairdeal.org/ time is running out!
View this message in context: http://forum.openscad.org/
Possible-bug-in-minkowski-function-tp18296p18298.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Thank you for your answer. I absolutely agree, of course. When I first
started representing spheres and cylinders, I used to draw "big" figures
(with radii in the order of tenths of millimeters), so I adjusted $fn to
1000 and (wrongly) assumed that such value would be good for all figures,
regardless their radii.
Evidently, as $fn is inversely related to both $fa and $fs, and also
dependent on the radius of the arcs involved, a value of $fn=1000 is good
(almost necessary) for a sphere or cylinder of radius r=100mm, but if r<5mm,
it is clearly excessive.
As you suggest, I'll use in the future different values for $fn according to
the radius of every curve, defining a global value based on the most
frequently used.
So far, I've finished the design I was trying. It's a button for a trolley
suitcase. It looks like this:
http://forum.openscad.org/file/n18323/Button.png
By the way, exist there a place in the forum where I could offer a design?
I'm designing some keyboard legs to replace those that break in computer
labs, and I'd like to offer to the community in case they could be of some
interest. Well, I actually don't know if doing this is legal, as legs are
parts of a commercial keyboard and I ignore if these parts are licensed. As
I haven't found any repository where such parts are offered, I've designed
them on my own by measuring their different elements with a caliber.
Thanks again.
--
View this message in context: http://forum.openscad.org/Possible-bug-in-minkowski-function-tp18296p18323.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
one forum you can use is thingiverse. It is still popular despte makerbot.
There are others but Thingiverse is probably still the most 'popular'
--
View this message in context: http://forum.openscad.org/Possible-bug-in-minkowski-function-tp18296p18325.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
jcbaraza wrote
I used to draw "big" figures (with radii in the order of tenths of
millimeters), so I adjusted $fn to 1000 and (wrongly) assumed that such
value would be good for all figures, regardless their radii.
Evidently, as $fn is inversely related to both $fa and $fs, and also
dependent on the radius of the arcs involved, a value of $fn=1000 is good
(almost necessary) for a sphere or cylinder of radius r=100mm, but if
r<5mm, it is clearly excessive.
Unless you have a very precise printer, the curve fragments don't need to be
that small, as the physics of molten plastic and machine error quickly
become the major factor.
Note that ATM OpenSCAD can have issues with very small sizes. If you find
strange things at small scale try factoring your design by, say, 100 or
1000, ie make your measurement variables magnitude bigger, then scale() the
final result back down. I can't remember which operations were affected ATM.
It's a button for a trolley suitcase. It looks like this:
Very nicely detailed. Much better than my early attempts.
By the way, exist there a place in the forum where I could offer a design?
I'm designing some keyboard legs to replace those that break in computer
labs, and I'd like to offer to the community in case they could be of some
interest.
As neon said Thingiverse http://www.thingiverse.com/search?q=openscad&sa=
has a lot of OpenSCAD designs (and libraries).
Well, I actually don't know if doing this is legal, as legs are parts of a
commercial keyboard and I ignore if these parts are licensed.
While it may depend on country specific laws, in Commonwealth and US based
law it appears that making replacement parts (legal term useful articles
http://www.copyright.gov/register/va-useful.html ), rather than 'art
works', is legal. This is a good start to the legal issues
http://james.grimmelmann.net/files/articles/indistinguishable-from-magic.pdf
.
As I haven't found any repository where such parts are offered, I've
designed them on my own by measuring their different elements with a
caliber.
Thanks again.
Admin - PM me if you need anything, or if I've done something stupid...
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
View this message in context: http://forum.openscad.org/Possible-bug-in-minkowski-function-tp18296p18327.html
Sent from the OpenSCAD mailing list archive at Nabble.com.