# Possible bug in minkowski() function?

7 messages
Open this post in threaded view
|

## Possible bug in minkowski() function?

 This post was updated on . 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-2*r-1+0.05, y_max+2, 2*z], 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-2*r_redondeo, y_max_boton, y_min_boton, y_max_boton-2*r_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 minkowski() 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-2*r_redondeo, y_max_boton, y_min_boton, y_max_boton-2*r_redondeo, z_boton, 2*r_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-2*r_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-2*r_redondeo, y_max_boton, y_min_boton, y_max_boton-2*r_redondeo, z_boton, 2*r_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-2*r_redondeo)/2, 0, -7]) minkowski()     {         // Coloring in red is just to highlight the rounding object         color([1, 0, 0, 1]) translate([-(x_min_boton-2*r_redondeo)/2, 0, z1_boton-9]) cylinder(\$fn = 1000, \$fa = 12, \$fs = 2, h=2*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-9]) Planta_Hueco_Boton(x_max_boton, x_min_boton, x_min_boton-2*r_redondeo, y_max_boton, y_min_boton, y_max_boton-2*r_redondeo, z_boton, 2*r_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
Open this post in threaded view
|

## Re: Possible bug in minkowski() function?

 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 : with the following code: Bloque_Boton.scadThe 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.
Open this post in threaded view
|

## Re: Possible bug in minkowski() function?

 Administrator 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 - email* me if you need anything, or if I've done something stupid... * click on my MichaelAtOz label, there is a link to email me. 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!
Open this post in threaded view
|

## Re: Possible bug in minkowski() function?

Open this post in threaded view
|

## Re: Possible bug in minkowski() function?

 In reply to this post by Ronaldo 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: 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.