Here’s my version of a design taken from the Jared Tarbell talk that I referenced earlier.
31 points, radius = (1., 1.8, 2.2, 3.1, 3.5, 3.7, 4)
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
but the short version is that I thought I could take a clever approach
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!
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.