Here's my version of a design taken from the Jared Tarbell talk that I referenced earlier.

The recipe is simple:

* Fully connect points that are equispaced around the circumference of a circle

* Repeat for circles of various radii

This exercise posed an interesting challenge. Full details in my repository here, but the short version is that I thought I could take a clever approach using Processing's `scale`

transform and—well—it didn't pan out.

So it was pretty obvious from the symmetry of the pattern that I would want to do my math in polar coordinates and then convert to cartesian at the last moment. And rather than recalculating the points around the edge of the circle whenever I change the radius of the circle, I can leave the points' *r* and *theta* (and their equivalent *x* and *y*) untouched and use Processing's `scale()`

transform to change the underlying basis vectors and hence the points' position on the screen. Neat! No recalculations!

Unfortunately, `scale()`

scales *everything*. It's not just that all the basis vectors are scaled, the actual screen representation of a pixel is scaled too. So if I call `scale(8)`

all of a sudden any line (say) that used to be one pixel wide is now 8 pixels wide. And although I can downscale the resulting line widths, I cannot do so below the new representation of 1 pixel. For example, the minimum value that I can pass to `strokeWeight()`

is 1. This is 1 *transformed* pixel, not 1 actual pixel. So when I use a large value in `scale()`

, my lines suddenly start to get thick *and they stay thick*. Here's a detail from an early iteration of the design:

The solution is **not** to use `scale()`

: instead simply recalculate the points