Hello,
I'm trying to build a cage that will be later subtracted from a rounded box, but the cage is so heavy to OpenScad (version 2019/05) that I'm not being able to do anything further. Is this a bug? Any other way of building the cage to be lighter? Marcos use <./MCAD/boxes.scad>; $fa=1; $fs=1; //---------------------- cage(); //---------------------- cubW = 100; cubL = 100; cubH = 80; wall = 2.5; //-------------------------------------------------------------------------- module cage() { difference() { curv = 26; difference() { roundedBox( [cubH, cubL, cubW], curv, true ); roundedBox( [cubH-2.0*wall,cubL-2.0*wall, cubW-2.0*wall], curv-2, true); } dl = -1.0; dx = cubW/3+2; dy = cubL/3+2; dz = cubH/3+2; for ( sdx = [ -1, 0, +1 ] ) { for ( sdy = [ -1, 0, +1] ) { for ( sdz = [ -1, 0, +1] ) { translate([sdx*dx, sdy*dy, sdz*dz]) roundedBox([cubW/3-dl,cubL/3-dl,cubH/3-dl],3, false); } } } } } //-------------------------------------------------------------------------- //-------------------------------------------------------------------------- -- Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
I'd guess it's because you've set $fa to be 1. On Sun, Nov 10, 2019, 1:07 PM MVAckel via Discuss <[hidden email]> wrote: Hello, _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
You can try using a higher value of $fa or using different values in different calls to roundedBox so you only use the high precision where you need it most. Your use case may vary. On Sun, Nov 10, 2019, 1:43 PM Max Bond <[hidden email]> wrote:
_______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
MCAD's roundedBox is not particularly efficient.
Try this version (copied from example006.scad) module rounded_cube(size,r,center=false) { s = is_list(size) ? size : [size,size,size]; translate(center ? -s/2 : [0,0,0]) hull() { translate([ r, r, r]) sphere(r=r); translate([ r, r,s.z-r]) sphere(r=r); translate([ r,s.y-r, r]) sphere(r=r); translate([ r,s.y-r,s.z-r]) sphere(r=r); translate([s.x-r, r, r]) sphere(r=r); translate([s.x-r, r,s.z-r]) sphere(r=r); translate([s.x-r,s.y-r, r]) sphere(r=r); translate([s.x-r,s.y-r,s.z-r]) sphere(r=r); } } It doesn't have "sides only" version, but it should be easier to compute, just replace the main loop body with your cage holes to call that instead: //roundedBox([cubW/3-dl,cubL/3-dl,cubH/3-dl],3, false); rounded_cube([cubW/3-dl,cubL/3-dl,cubH/3-dl],3, true); Also you can save a bit more computation if you ignore the center column of "holes" like this: if (!(sdx == 0 && sdy == 0)) translate([sdx*dx, sdy*dy, sdz*dz]) Hans On Sun, Nov 10, 2019 at 2:45 PM Max Bond <[hidden email]> wrote: > > You can try using a higher value of $fa or using different values in different calls to roundedBox so you only use the high precision where you need it most. > > Your use case may vary. > > On Sun, Nov 10, 2019, 1:43 PM Max Bond <[hidden email]> wrote: >> >> I'd guess it's because you've set $fa to be 1. >> >> On Sun, Nov 10, 2019, 1:07 PM MVAckel via Discuss <[hidden email]> wrote: >>> >>> Hello, >>> >>> I'm trying to build a cage that will be later subtracted from a rounded box, >>> but the cage is so heavy to OpenScad (version 2019/05) that I'm not being >>> able to do anything further. >>> >>> Is this a bug? Any other way of building the cage to be lighter? >>> >>> Marcos >>> >>> >>> >>> use <./MCAD/boxes.scad>; >>> >>> $fa=1; >>> $fs=1; >>> >>> >>> //---------------------- >>> cage(); >>> //---------------------- >>> >>> cubW = 100; >>> cubL = 100; >>> cubH = 80; >>> wall = 2.5; >>> //-------------------------------------------------------------------------- >>> >>> module cage() >>> { >>> >>> difference() { >>> curv = 26; >>> >>> difference() { >>> roundedBox( [cubH, cubL, cubW], curv, true ); >>> roundedBox( [cubH-2.0*wall,cubL-2.0*wall, cubW-2.0*wall], curv-2, true); >>> } >>> >>> >>> dl = -1.0; >>> >>> dx = cubW/3+2; >>> dy = cubL/3+2; >>> dz = cubH/3+2; >>> for ( sdx = [ -1, 0, +1 ] ) { >>> for ( sdy = [ -1, 0, +1] ) { >>> for ( sdz = [ -1, 0, +1] ) { >>> translate([sdx*dx, sdy*dy, sdz*dz]) >>> roundedBox([cubW/3-dl,cubL/3-dl,cubH/3-dl],3, false); >>> } >>> } >>> } >>> } >>> } >>> //-------------------------------------------------------------------------- >>> //-------------------------------------------------------------------------- >>> >>> >>> >>> >>> >>> -- >>> Sent from: http://forum.openscad.org/ >>> >>> _______________________________________________ >>> 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 _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
I played around a bit with this and I have to say, the output from MCAD's
roundedBox is horrible. People have complained when I criticize MCAD, but I'm sorry, this is just ridiculous: <http://forum.openscad.org/file/t2477/mcad_box.png> This "rounded" box has a bunch of extra polygons because of whatever craziness is going on with the "rounding". A new user should not encounter a result like this in the "standard" library. If you want to make it work anyway then you can do it by putting "render()" in front of your difference command. But if you use the rounded box posted above it runs in 4s on my machine, without any trouble (except that the result is wrong because it always rounds all the edges). Note also that you don't need two differences, since the inner one subtracts one thing and then the outer one just subtracts more. If you want a library that actually works and is supported, I suggest trying BOSL or BOSL2. https://github.com/revarbat/BOSL2/wiki The following code based on BOSL2 runs in 0s for me and actually produces the same thing as the original code: include<BOSL2/std.scad> $fa=1; $fs=1; cage(); cubW = 100; cubL = 100; cubH = 80; wall = 2.5; module cage() { curv = 26; dl = -1.0; dx = cubW/3+2; dy = cubL/3+2; dz = cubH/3+2; difference(){ cuboid( [cubH, cubL, cubW], rounding=curv, edges=edges("Z")); // Edges in the Z direction are rounded cuboid( [cubH-2.0*wall,cubL-2.0*wall, cubW-2.0*wall], rounding=curv-2, edges=edges("Z")); grid3d(n=[3,3,3],spacing=[dx,dy,dz]) cuboid([cubW/3-dl,cubL/3-dl,cubH/3-dl],rounding=3); } } -- Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
On 11/10/2019 2:32 PM, adrianv wrote:
<http://forum.openscad.org/file/t2477/mcad_box.png> [ MCAD's ] "rounded" box has a bunch of extra polygons because of whatever craziness is going on with the "rounding". That looks really familiar. I have a rounded-end-cylinder polygon module that I use in a number of places, that I happen to be using today, and it has some of the same issues. Or did, until I got obsessive and fixed several of them. Without looking at the sources, it looks like it isn't so much doing anything stupid as it is using naïve techniques, building the edges out of cylinders and the corners out of spheres. Unless you're really careful, the faces on low-poly corners like that won't line up. It also looks like it's got the faces of the round things aligning with the sides of the box, without accounting for the fact that OpenSCAD's polygon-cylinders have a diameter measured vertex-to-vertex, not face-to-face. It needs which will give you the diameter (or radius) to use to get a diameter of "d" measured face-to-face.function adj(d, sides) = d/cos(360/sides/2); _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
To get it simpler just the hull of 8 spheres. A domingo, 10/11/2019, 22:37, Jordan Brown <[hidden email]> escreveu:
_______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
In reply to this post by JordanBrown
On 11/10/2019 2:37 PM, Jordan Brown
wrote:
function adj(d, sides) = d/cos(360/sides/2); BTW, trig/computer tidbit of the day: Alexa gets acos( ) and asin( ) completely wrong. For instance, she says that asin(0.5) is 0.0087, and that acos(0.5) is 1.5621. (Correct are 0.52 and 1.05.) Actually, it appears that all asin( ) results are about zero, and all acos( ) results are about 1.57. Also, for sin(x) and cos(x), x is in degrees, but for asin( ) and acos( ) the answer appears to be in radians. I guess Alexa was distracted during her high school trig class. I tentatively suspect that they did acos(degrees_to_radians(x)) instead of radians_to_degrees(acos(x)). I filed a bug report. _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
I've submitted a pull request to MCAD (
https://github.com/openscad/MCAD/pull/66 ), to improve roundedBox. It should work fine as a drop-in replacement for boxes.scad. Due to potential issues with backwards compatibility, I've left it open for discussion if the approach I used is the best option. In order to be more consistent with native OpenSCAD modules, i gave the new module a slightly different interface, and a different name: "roundedCube". Calling "roundedBox" module will still work, and use the new hull-based implementation, but will echo deprecation warnings. In the meantime if you don't want to wait for that to be officially merged, you can directly download the updated file here: https://raw.githubusercontent.com/openscad/MCAD/e08302349e0e1bf77f6e13a3948386e2ec134def/boxes.scad Hans On Sun, Nov 10, 2019 at 4:54 PM Jordan Brown <[hidden email]> wrote: > > On 11/10/2019 2:37 PM, Jordan Brown wrote: > > function adj(d, sides) = d/cos(360/sides/2); > > > BTW, trig/computer tidbit of the day: Alexa gets acos( ) and asin( ) completely wrong. > > For instance, she says that asin(0.5) is 0.0087, and that acos(0.5) is 1.5621. (Correct are 0.52 and 1.05.) Actually, it appears that all asin( ) results are about zero, and all acos( ) results are about 1.57. Also, for sin(x) and cos(x), x is in degrees, but for asin( ) and acos( ) the answer appears to be in radians. > > I guess Alexa was distracted during her high school trig class. > > I tentatively suspect that they did acos(degrees_to_radians(x)) instead of radians_to_degrees(acos(x)). > > I filed a bug report. > > _______________________________________________ > 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 |
Thank you guys. The new implementation is really lightning fast compared to the old one. Solved the problem nicely. -- Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
If you hull spheres to make anything with accurate dimensions you want a sphere() that has vertices on it poles and equator. See
https://github.com/nophead/NopSCADlib#Sphere On Mon, 11 Nov 2019 at 02:14, MVAckel via Discuss <[hidden email]> wrote:
_______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
Free forum by Nabble | Edit this page |