Strategies to accelerate rendering?

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

Strategies to accelerate rendering?

amundsen
Hello,

Is there some tutorial to optimize code? The rendering stalls at 999/1000
for a long time as soon as my models are not strictly basic.

Thank you.



--
Sent from: http://forum.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: Strategies to accelerate rendering?

nophead
Hard to say without seeing your model but I guess there are a lot of objects that need to be unioned at the end.

Sometimes it can be done in 2D. For example if you make a grill in a panel by subtracting hundreds of cylinders it will be very slow but if you subtract circles from a square and then linear_extrude it to make a 3D panel it will be instantaneous.

On Sat, 13 Jun 2020 at 11:05, amundsen <[hidden email]> wrote:
Hello,

Is there some tutorial to optimize code? The rendering stalls at 999/1000
for a long time as soon as my models are not strictly basic.

Thank you.



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

Re: Strategies to accelerate rendering?

MichaelAtOz
Administrator
In reply to this post by amundsen
I suspect you may be using high $fn values? Try 32 first, then selectively
increase in specific sections as needed, and/or use low values for
development and higher ones for final production.



-----
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.

--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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.
Reply | Threaded
Open this post in threaded view
|

Re: Strategies to accelerate rendering?

Troberg
In reply to this post by amundsen
In addition to the other advice given, I've found that adding a render()
after creating a complex object that'll be re-used a lot will sometimes help
a lot. For example, if you do logical operations with text objects, a
render() can make a huge difference, as it simplifies the object by removing
stuff that is no longer needed.



--
Sent from: http://forum.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: Strategies to accelerate rendering?

amundsen
In reply to this post by amundsen
The difference operation seems to require a lot of computations sometimes so
I've created both parts involved as two different .stl files and made the
difference in a separate program.

However here is a typical code which takes ages to be rendered. If you see
any possible improvement let me know. The shape to be rendered is displayed
below.


global_thickness = 20;
nombre_vagues = 6;
degres = 360;
base_thickness = 2;
wall_thickness = 4;
precision = 360;
union() {
        for ( i = [0:1/3:degres * 9]) {
                a = [sin(i/3) * (enclosure_radius-global_thickness), cos(i/3) *
(enclosure_radius-global_thickness)];
                d = [sin((i+1)/3) * (enclosure_radius-global_thickness), cos((i+1)/3) *
(enclosure_radius-global_thickness)];
                f = [sin(i/3) * enclosure_radius, cos(i/3) * enclosure_radius];
                g = [sin((i+1)/3) * enclosure_radius, cos((i+1)/3) * enclosure_radius];
                reference = [0,0];
                translate([0,0,base_thickness]) {
                        translate([0,0,0]) {
                                linear_extrude(height = (sin(i/3 * nombre_vagues) * 10)+10, center =
false, convexity = 10, twist = 0, slices = 20, scale = 1.0, $fn = 16) {
                                        polygon(points = [a,f,g,d], convexity = 100);
                                        }    
                                }
                }

        }
        difference() {
                union() {
                        cylinder(h = base_thickness, r = enclosure_radius + wall_thickness, $fn =
precision);
                        cylinder(h = 64, r = enclosure_radius -20, $fn = precision);
                        translate([0,0,1]) {
                                 cube([wall_thickness * 2 + 4, enclosure_radius * 2 + 2 * wall_thickness
+ 40, 2], center = true);
                        }
                        translate([5, enclosure_radius+14, 3]) {
                                cube([2,20,2], center = true);
                        }
                        translate([-5, enclosure_radius+14, 3]) {
                                cube([2,20,2], center = true);
                        }
                        translate([5, -enclosure_radius-14, 3]) {
                                cube([2,20,2], center = true);
                        }
                        translate([-5, -enclosure_radius-14, 3]) {
                                cube([2,20,2], center = true);
                        }
                }
                cylinder(h = 64, r = enclosure_radius - 24, $fn = precision);
        }
}

<http://forum.openscad.org/file/t2715/caption.jpg>







--
Sent from: http://forum.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: Strategies to accelerate rendering?

nophead
Use 2D as much as possible to avoid 3D difference(). E.g. don't subtract cylinders, linear extrude a difference of two circles.

Similarly for the two channels, linear extrude the difference of two squares.

Don't set $fn if you are 3D printing. Set $fa and $fs. I use $fa = 6 and $fs = 0.25. Sometimes I lower $fa to 1 to when milling. 

On Mon, 15 Jun 2020 at 12:10, amundsen <[hidden email]> wrote:
The difference operation seems to require a lot of computations sometimes so
I've created both parts involved as two different .stl files and made the
difference in a separate program.

However here is a typical code which takes ages to be rendered. If you see
any possible improvement let me know. The shape to be rendered is displayed
below.


global_thickness = 20;
nombre_vagues = 6;
degres = 360;
base_thickness = 2;
wall_thickness = 4;
precision = 360;
union() {
        for ( i = [0:1/3:degres * 9]) {
                a = [sin(i/3) * (enclosure_radius-global_thickness), cos(i/3) *
(enclosure_radius-global_thickness)];
                d = [sin((i+1)/3) * (enclosure_radius-global_thickness), cos((i+1)/3) *
(enclosure_radius-global_thickness)];
                f = [sin(i/3) * enclosure_radius, cos(i/3) * enclosure_radius];
                g = [sin((i+1)/3) * enclosure_radius, cos((i+1)/3) * enclosure_radius];
                reference = [0,0];
                translate([0,0,base_thickness]) {
                        translate([0,0,0]) {
                                linear_extrude(height = (sin(i/3 * nombre_vagues) * 10)+10, center =
false, convexity = 10, twist = 0, slices = 20, scale = 1.0, $fn = 16) {
                                        polygon(points = [a,f,g,d], convexity = 100);
                                        }     
                                }                                               
                }

        }
        difference() {
                union() {
                        cylinder(h = base_thickness, r = enclosure_radius + wall_thickness, $fn =
precision);
                        cylinder(h = 64, r = enclosure_radius -20, $fn = precision);
                        translate([0,0,1]) {
                                 cube([wall_thickness * 2 + 4, enclosure_radius * 2 + 2 * wall_thickness
+ 40, 2], center = true);
                        }
                        translate([5, enclosure_radius+14, 3]) {
                                cube([2,20,2], center = true);
                        }
                        translate([-5, enclosure_radius+14, 3]) {
                                cube([2,20,2], center = true);
                        }
                        translate([5, -enclosure_radius-14, 3]) {
                                cube([2,20,2], center = true);
                        }               
                        translate([-5, -enclosure_radius-14, 3]) {
                                cube([2,20,2], center = true);
                        }
                }
                cylinder(h = 64, r = enclosure_radius - 24, $fn = precision);
        }
}

<http://forum.openscad.org/file/t2715/caption.jpg>







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

Re: Strategies to accelerate rendering?

amundsen
I'll give a try to set $fa and $fs instead of $fn. Thank you.



--
Sent from: http://forum.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: Strategies to accelerate rendering?

JordanBrown
In reply to this post by amundsen
Setting $fn to 360 is an obvious culprit, but it's not the real problem.

There's another segment that seems to be doing too much work. (And is also harder to understand than it needs to be.)

On 6/15/2020 4:09 AM, amundsen wrote:
degres = 360;
[...]
	for ( i = [0:1/3:degres * 9]) {	
		a = [sin(i/3) * (enclosure_radius-global_thickness), cos(i/3) *
(enclosure_radius-global_thickness)];
		d = [sin((i+1)/3) * (enclosure_radius-global_thickness), cos((i+1)/3) *
(enclosure_radius-global_thickness)];

This steps around the circle three times.  The second and third times are identical to the first and can be eliminated.

It would then be stepping from 0 to 3*360 by 1/3.  The multiply-by-3 is cancelled by the divide-by-3s in the body, making the whole thing unnecessarily complex.  The effect is to step around the circle by 1/9 degree increments; it could do that directly, eliminating all of the divides.

Net, this is building 9720 linear-extruded blocks 2/3 of which are redundant.

After eliminating the redundant blocks, you'll still have 3240 of them.  That's a lot.

I'd have to figure out how big the stair steps involved really are to know if you need that much resolution.  But assuming for the moment that you do, you still probably don't need it *all the time*.  You could do much of your work at much lower resolution, and only render at full resolution when you're ready to print.

Something like:
step = 1/9;
[...]
    for ( i = [0:step:degres]) {
        a = [sin(i) * (enclosure_radius-global_thickness), cos(i) * (enclosure_radius-global_thickness)];
        d = [sin(i+step) * (enclosure_radius-global_thickness), cos(i+step) * (enclosure_radius-global_thickness)];
        f = [sin(i) * enclosure_radius, cos(i) * enclosure_radius];
        g = [sin(i+step) * enclosure_radius, cos(i+step) * enclosure_radius];
        reference = [0,0];
        translate([0,0,base_thickness]) {
            translate([0,0,0]) {
                linear_extrude(height = (sin(i * nombre_vagues) * 10)+10, center = false, convexity = 10) {
                    polygon(points = [a,f,g,d], convexity = 100);
                    }     
                }						
            }
        }

and then set "step" to different values depending on what you're doing.

Note:  Your blocks were 1/3 degree wide and stepped in 1/9 degree intervals; mine are "step" wide, with "step" intervals.



A more advanced answer might be to stop using linear_extruded blocks - which have flat tops - and instead use polyhedra.  With a polyhedron you could have a top that slopes, which will more naturally fit the sine wave that you're trying to generate.  You could probably get away with *many* fewer steps that way.  It looks like 1-degree or 2-degree steps might well be fine

Here's a variation that renders in ~90 seconds for me, versus >10 minutes for even a simplified version of the original.  And the fidelity is pretty good, maybe even better than the original.  I had to guess at a value for enclosure_radius; the original didn't provide one.  Dropping precision to 60 takes it down to 42.  Setting step to 5 and precision to 60 makes it render in 25 seconds.  The fidelity there is probably not good enough for production, but is probably good enough for pre-production work.

Somebody should check my polyhedra.  My 3D geometry isn't quite good enough for me to be sure that the "top" isn't really a quadrilateral, that it really does need to be split into two triangles.
enclosure_radius=50;
global_thickness = 20;
nombre_vagues = 6;
degres = 360;
base_thickness = 2;
wall_thickness = 4;
precision = 360;
step = 2;
union() {
    for ( i = [0:step:degres]) {
        abot = [sin(i) * (enclosure_radius-global_thickness), cos(i) *
(enclosure_radius-global_thickness), 0];
        dbot = [sin(i+step) * (enclosure_radius-global_thickness), cos(i+step) *
(enclosure_radius-global_thickness), 0];

        fbot = [sin(i) * enclosure_radius, cos(i) * enclosure_radius, 0];
        gbot = [sin(i+step) * enclosure_radius, cos(i+step) * enclosure_radius, 0];
        
        h1 = (sin(i * nombre_vagues) * 10)+10;
        h2 = (sin((i+step) * nombre_vagues) * 10)+10;
        
        atop = abot + [0,0,h1];
        dtop = dbot + [0,0,h2];
        ftop = fbot + [0,0,h1];
        gtop = gbot + [0,0,h2];
        
        reference = [0,0];
	translate([0,0,base_thickness]) {
            polyhedron(points=[abot, dbot, fbot, gbot, atop, dtop, ftop, gtop], faces=[
                [0,1,3,2],
                [4,5,1,0],
                [0,2,6,4],
                [5,7,3,1],
                [2,3,7,6],
                [7,5,4],
                [4,6,7]
            ], convexity=10);
            }
    }
    difference() {
        union() {
            cylinder(h = base_thickness, r = enclosure_radius + wall_thickness, $fn =
precision);
            cylinder(h = 64, r = enclosure_radius -20, $fn = precision);
            translate([0,0,1]) {
                cube([wall_thickness * 2 + 4, enclosure_radius * 2 + 2 * wall_thickness
+ 40, 2], center = true);
                }
            translate([5, enclosure_radius+14, 3]) {
                cube([2,20,2], center = true);
                }
            translate([-5, enclosure_radius+14, 3]) {
                cube([2,20,2], center = true);
                }
            translate([5, -enclosure_radius-14, 3]) {
                cube([2,20,2], center = true);
                }		
            translate([-5, -enclosure_radius-14, 3]) {
                cube([2,20,2], center = true);
                }
            }
            cylinder(h = 64, r = enclosure_radius - 24, $fn = precision);
	}
    }





A still more advanced answer would construct the entire outer ring as a single polyhedron, but that exceeds what I want to do today.  (But it would probably be faster still.)



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

Re: Strategies to accelerate rendering?

amundsen
Thanks a lot @JordanBrown!

The first version without polyhedron is still quite slow but it might be in
part because I have an integrated GPU only.

The second version is indeed much faster. I need to analyze the code!





--
Sent from: http://forum.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: Strategies to accelerate rendering?

Kevig
hello,

I am not sure if this has anything to do with the topic but i see you all
look at the programming code for optimizing.
I wonder if there is something in openscad/cgal eating up rendering time.
Rendering the code for my project takes a staggering 5mins 50 secs but the
CPU load stay's at 9% and the GPU load stay's at 5%.
so the computer is almost doing nothing!
(AMD Ryzen 7 3700X 8core 3.59 and GTX 1650S)
it is as if the computer power is not important at all and there is some
other reason why the calculations are so slow.
I did expect a higer GPU/CPU load when the calculations increase

rgrds
Henk



--
Sent from: http://forum.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: Strategies to accelerate rendering?

nophead
OpenSCAD only uses one core so it won't go above 12.5%. It does use enormous amounts of RAM so if it causes swapping you will get less than one core fully used.

The reason it is so slow is that CGAL uses infinite precision rationals to represent numbers instead of floating point. As soon as you have curves or rotation most coordinates become irrational, so the numbers explode, eating up CPU and memory.

On Tue, 16 Jun 2020 at 14:57, Kevig <[hidden email]> wrote:
hello,

I am not sure if this has anything to do with the topic but i see you all
look at the programming code for optimizing.
I wonder if there is something in openscad/cgal eating up rendering time.
Rendering the code for my project takes a staggering 5mins 50 secs but the
CPU load stay's at 9% and the GPU load stay's at 5%.
so the computer is almost doing nothing!
(AMD Ryzen 7 3700X 8core 3.59 and GTX 1650S)
it is as if the computer power is not important at all and there is some
other reason why the calculations are so slow.
I did expect a higer GPU/CPU load when the calculations increase

rgrds
Henk



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

Re: Strategies to accelerate rendering?

JordanBrown
In reply to this post by amundsen
On 6/15/2020 11:53 PM, amundsen wrote:
The first version without polyhedron is still quite slow but it might be in
part because I have an integrated GPU only.

I didn't time that one.  But excess objects never helps.

Preview uses your GPU.  Render does not.

The second version is indeed much faster. I need to analyze the code!

It's basically the same as yours, except that where you have a linear-extruded block with a flat top, it has a polyhedron with a slanted top.  (Actually, it seems that the top isn't flat, that it needs to be split into two triangles.  I'm not good enough at visualizing 3D geometry to confirm that it has to be that way.)  The "bot" values are your original a,d,f,g coordinates, the bottom of each block; the "top" values are the same XY coordinates but Z is the top of the block.

Because yours uses flat tops and so must stair-step, you need a lot of tiny blocks to get a reasonably smooth top surface.  Since this scheme uses slanted tops it can get a smooth top surface with many fewer blocks.


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

Re: Strategies to accelerate rendering?

JordanBrown
In reply to this post by nophead
On 6/16/2020 7:12 AM, nop head wrote:
OpenSCAD only uses one core so it won't go above 12.5%.

Nit:  the fraction will depend on what kind of processor you have.

I've never understood the relationship between "sockets", "cores" and "virtual processors", but I have 1/2/4 and at the moment OpenSCAD is topping out at ~30% for me.  I assume that it's not reaching 50% because of competition from other processes.

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

Re: Strategies to accelerate rendering?

Alan Cox-2
On Tue, 16 Jun 2020 15:21:27 +0000
Jordan Brown <[hidden email]> wrote:

> On 6/16/2020 7:12 AM, nop head wrote:
> > OpenSCAD only uses one core so it won't go above 12.5%.  
>
> Nit:  the fraction will depend on what kind of processor you have.
>
> I've never understood the relationship between "sockets", "cores" and
> "virtual processors", but I have 1/2/4 and at the moment OpenSCAD is
> topping out at ~30% for me.  I assume that it's not reaching 50% because
> of competition from other processes.

So an x86 processor is a heirarchy

At the bottom you have hyperthreads which are individual threads of code
execution. They share the same silicon directly. The idea is that a
processor has a bunch of things it can be doing at once and the front end
of the processor is responsible for keeping as many of those units busy
at a time as it can. Having two threads of execution helps to ensure that
if one of them stalls say waiting for a value not in cache the other can
fill the gaps, or if one is floating point heavy and the other is integer
and so on...

Cores are instances of the above. They usually share the larger caches.

Sockets are physically separate things plugged into the motherboard and
don't share caches but also don't share heatsinks and thus some thermal
limits.

(there is also another layer in there for some things which are managed
by groups of processors like power, but that's not important here).

In the AMD case however (and a tiny number of Intel ones) the socket layer
is a bit more confused because for the threadripper/epyc they are
essentially built as multiple sockets but all one on thing you stick on
the motherboard.

The ARM world is similar except that I don't believe any ARM does
hyperthreading (and there are good architectural reasons why what makes
sense in one kind of CPU design does not in others)

ARM (and one upcoming x86) also sometimes has big/little where some of
the processors are big and fast and eat power and some are slow and don't.

"Virtual processors" is a windows-ism. What it means depends on what
Windows wants it to mean. On a desktop it probably matches hyperthreads
but that depends on what Windows feels like doing, and if you are running
under a hypervisor (which you may or may not magically be depending how
Windows installed and your configuration).

For a current bottom end x86 desktop you'll have 1 socket, 2 cores and
4 hyperthreads. OpenSCAD can use 1 hyperthread of one core, which if the
other thread is idle is typically around 60-70% of the core's total
performance. So your 30% sounds about right.

A perfectly parallelising OpenSCAD would thus be about 3 times faster on
that box than the current one. A realistic number would probably be
nearer twice. In comparison judging by the performance of some other
toolkits I can easily believe that you'd get a thousand fold performance
improvement by using better algorithms. It's just that the availability
of those in open source is limited and writing them is seriously hard
stuff.

Alan

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

Re: Strategies to accelerate rendering?

JordanBrown
In reply to this post by JordanBrown
Caution:  depending on the exact parameters, I'm sometimes getting
UI-WARNING: Object may not be a valid 2-manifold and may need repair!

I assume that what's happening is that the inside edges of the individual blocks are interacting badly with the cylinder and sometimes causing the two to share an edge.  For geometrical/computational reasons that IMO don't make much sense in reality, that's a big no-no.  But it often happens when you position things using math.


The best solution is probably to move the inside of the blocks inward just a little, so that they cleanly overlap with the cylinder no matter exactly how many sides the cylinder has.


That is, something like

nudge = 1;
abot = [sin(i) * (enclosure_radius-global_thickness-nudge),
    cos(i) * (enclosure_radius-global_thickness-nudge), 0];

My math says that for a 60-sided cylinder the radius to the center of an edge is 99.86% of the radius to the vertices.  In theory, a correction of 0.2% of the radius should be enough to make them overlap.  However, since the cylinder is 20 units thick, we don't need precision - adjusting it inward 1 unit is fine.


Here's the math, if anybody is interested.


Note:  this drawing is a bit poor in that I used 45 degree angles and so it happens that ACM and CAM are both 45 degrees and AM = CM.  In the general case they won't be equal like that.


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

Re: Strategies to accelerate rendering?

amundsen
Thanks a lot @JordanBrown for the explanation on how to deal with the
"non-manifold" issue. I've never had such a warning in Openscad but it
happened in my slicer and now I understand where it came from!

Good to know the GPU doesn't play a role when rendering too!





--
Sent from: http://forum.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: Strategies to accelerate rendering?

JordanBrown
On 6/17/2020 12:43 PM, amundsen wrote:
Thanks a lot @JordanBrown for the explanation on how to deal with the
"non-manifold" issue. I've never had such a warning in Openscad but it
happened in my slicer and now I understand where it came from!

The simplest example is two cubes positioned corner to corner:
cube(1);
translate([1,1,0]) cube(1);

but you can encounter it in any number of circumstances.  In this particular case, I believe the vertical edges of the central cylinder (which is really an extruded polygon) were periodically lining up with the vertical edges of the inner sides of the blocks that form the sine wave.

That's not really a surprise, because:

  • The cylinder probably has a number of sides that is an exact multiple of one degree, and
  • The outer blocks are spaced exact multiples of one degree, and
  • The inner edges of the blocks are positioned exactly at the radius of the cylinder and so exactly at the radius of the cylinder's vertical edges.

    


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org