How to use Openscad (3): iterations, extrusions and more modularity!

Part 3/5: iteration, extrusion and useful parametrized CSG techniques

Repeating shapes

There are still other ways to create the same design (eg. by intersections, and so).

I tend to prefer either rotation, or inverted axes (with the scale operator and -1 on some axes). A translation like we did previously is probably not the wisest choice because it does not change the "orientation" of the duplicated object itself, as you can see below with a shape that is no more a cylinder.

Translations will keep the same positive orientation for the four parts!

Rotation is often preferred as it also "fixes" the orientation of the duplicated part.

Scaling operators are also useful to invert axes (click to see the code).

Recursive designs, and conditionals

Only the latest version of Openscad made recursion possible. Previously, variables had the amazing property that they were ... constant! Advanced operators like "assign( )" helped circumvent some of the issues, but they made the source code even worse in my opinion.

What is recursion? Well, it happens when a module calls itself in order to build more versions of its own shape, smaller or in another place. To avoid looping indefinitely (and killing the computer memory and CPU), we must also introduce conditionals. A test will be made to stop calling ourselves after some condition is met, e.g. like when the part becomes too small.

Remember the mug-with-a-cup that we made in part two? Here is how we can write a recursive mug, that will add smaller-mugs-in-mugs till it get smaller than the constant wall width. It would not make any sense to go "deeper" in the recursion anyhow.

A recursive mug. Make sure you have a version of Openscad that allows this (an indicator is that the syntax is now colored: another long-waited feature!)

By the way, you see also the use of the "color" operator, that highlights each of the sub-mugs. The color components were chosen according to the size of the mug, so we get an automatic color gradient whatever the depth of the recursion.

Advanced concepts

The minkowski operator is quite cool. But it is so slow that we almost never use it. The effect is like when a shape is used to paint or "brush" a parent shape: e.g. a small sphere will "round" all the edges and surfaces of a given reference object.

Shown below is an example where we use only 2D shapes, that Openscad also supports (we then use square in place of cube, circle for spheres and so).

The minkowski operator, illustrated here on 2D Openscad shapes. It does works in 3D also but is so slow that the shape is usually better designed otherwise.

More importantly, there are also two kinds of extrusions, linear and circular, that makes 3D shapes out of 2D shapes.

They are very useful to create 3D shapes out of "industrial" 2D designs (often based on the Autocad DXF file format that Openscad knows how to import).

Here we will "raise" our former 2D shape vertically and make it a 3D shape, here is what we write:

  linear_extrude(height=30)
  {
    minkowski()
    {
      union()
      {
        square([20,20]);
        translate([20,10]) circle(r=6);
      }
      circle(r=4);
    }
  }

3D linear extrusion of the former 2D shape

Contrary to the linear extrusion, the rotate_extrude( ) operator can be used to create a "ring" out of a 2D profile. This is how we extrude a rough circle into a torus (note how the circle must be translated out of the origin to do so!).

Rotational extrusion of a basic 2D hexagon (a 6-segment circle)

 For the most curious readers, these extrusion operators have trickier optional properties (see the official documentation for more on this). If you cut the toroid by an orthogonal plane you will find the 6-segment primitive circle (hence the rough look).


One annoying thing with the "rotate_extrude( )" is that it does make partial rotation. It will always "close the loop".

So when you need only 1/4th of a turn (i.e. a partial 90° rotation), say, then the best way is to intersect the shape with a cube, like this:

Easy 90° slice of the torus, with an intersection of the former torus and a big cube that stands in the positive (X,Y,Z) spatial quadrant.

Now, for any angles smaller than 90°, we can create a "wedge" shape by means of a convex hull around two very thin slices (almost flat cuboids), where one of them is rotated by the expected angle (see, by the way how modules can be defined within modules).

A 45° "slice" of the initial torus, but it works only with for small wedges.

The "wedge_wall" thickness should be chosen below the 3D printer resolution, e.g. as low as 0.02 mm. But take care as too small a value and Openscad may just "skip" the shape!).

You may have seen the use of the weird expression (center==true ? -height/2 : 0). This is a compact form of a conditional, usually barely readable: "if center is true, then replace the expression by the value -height/2 else use the value 0". This is a short way to code a condition, which is used here to shift the part downwards by half the height in order to center it, like it is done with cylinders.

We did not use a more usual "if" test, as in the recursive mug. It would make life harder as "if" works with shapes, and not operators: the "if" condition cannot apply on the presence of the "translate" operation itself, but only on whole shapes. The "?" shorter version applies only on mathematical expressions, suitable here. All in all, in some case we will ask for a translation of (0,0,0), which works!


Anyhow. The above wedge design fails when the angle is larger than 90°, as the hull will flatten the two-wall wedge (see the animation below).

A convex hull between the first and last "wall" fails with any large angles! We will see Openscad animation later.

To create a pseudo-wedge that really can span 360°, we can use a succession of hulls no bigger than 45°, and that are progressively rotated around the Z axis.

So using a loop is very natural to generate the intermediate walls, spaced here at 45° of each other.
Still, we need to add the last wall "manually" as it may not fall on a multiple of 45° as below.

Angularly-spaced thin wall to help building the required concave wedge.

  module wedge(angle, extent=100, height=100, center=true)
  {
    module wedge_wall()
    {
      translate([0,0,(center==true ? -height/2 : 0)])
        cube([extent,0.1,height]);
    }
    
    for(r=[0:45:angle-1])
      rotate([0,0,r])
        wedge_wall();
    rotate([0,0,angle])
      wedge_wall();
  }

  wedge(angle=200);


Now, we want a shell somehow like a hull around this skeleton...

But a regular hull( ) around the thin walls would fail badly, as it would "fill" also straight from the first wall to the last wall. The required concavity made by the first and last walls would not be respected. Sure, as the operator builds a convex hull. A concave hull probably has no meaning anyway, we must build it by hand.

So what's the trick? The expected concave wedge shape can be made by unions of successive hulls!

Here is our first attempt at a potential "concave" wedge. It works but it makes a dirty source code (so far).

This is how we did it. We also introduces the min(v1,v2,v3..) and max() mathematical operators (weirdly, they do not take a vector as argument but a list of variables).

  module wedge(angle, extent=100, height=100, center=true)
  {
    module wedge_wall()
    {
      translate([0,0,(center==true ? -height/2 : 0)])
        cube([extent,0.1,height]);
    }
    
    for(r=[0:45:angle-45-1])
    {
        hull()
        {
          rotate([0,0,r]) wedge_wall();
          rotate([0,0,min(angle,r+45)]) wedge_wall();
        }
    }
    hull()
    {
      rotate([0,0,max(0,angle-45)]) wedge_wall();
      rotate([0,0,angle]) wedge_wall();
    }
  }

  wedge(angle=200);

The min and max are required to avoid overshooting the expected wedge angle.

Here are the result of the intersection of our wedge and the initial torus, that finally does it.

It works! The parametric wedge "sliced" the torus the way we wanted. Note the "missing" part? It is only a rendering issue, see below!

Here is why there is a "convexity" parameter in the rotate_extrude(), and a few other Openscad functions. It helps the renderer by telling to look deeper in the intersection of objects.

Well... OK, it works... but the source code got much polluted...

It can get cleaner with the beautiful and somehow forgotten / unusual concept of children in Openscad. And that will make yet another part in this introduction to Openscad (to come!)