Possible bug in minkowski() function?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Possible bug in minkowski() function?

jcbaraza
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

Reply | Threaded
Open this post in threaded view
|

Re: Possible bug in minkowski() function?

Ronaldo
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.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.
Reply | Threaded
Open this post in threaded view
|

Re: Possible bug in minkowski() function?

MichaelAtOz
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!
Reply | Threaded
Open this post in threaded view
|

Re: Possible bug in minkowski() function?

Ronaldo
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 <[hidden email]>:
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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Possible bug in minkowski() function?

jcbaraza
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.
Reply | Threaded
Open this post in threaded view
|

Re: Possible bug in minkowski() function?

Neon22
one forum you can use is thingiverse. It is still popular despte makerbot. There are others but Thingiverse is probably still the most 'popular'
Reply | Threaded
Open this post in threaded view
|

Re: Possible bug in minkowski() function?

MichaelAtOz
Administrator
In reply to this post by jcbaraza
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 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), rather than 'art works', is legal. This is a good start to the legal issues.
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 - 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!