Processing: Creative Coding and Computational Art

PROCESSING: CREATIVE CODING AND COMPUTATIONAL ART
662
If you haven’t figured it out by now, here’s how you mutate between the four forms:
1. Press the P key to convert from a cube to a pyramid.
2. Press and hold the up arrow key to convert from a pyramid to a cone.
3. Press the P key again to convert from a cone to a cylinder.
I was surprised by how easy it was to convert between these four forms. Prior to developing
this sketch, I had considered them (without really thinking much about it) as fundamental,
irreducible primitives, like the primary colors. I even managed to earn two art
degrees never realizing that a pyramid was just a cube with one of its faces collapsed to a
point.
The sketch should be fairly self-explanatory. However, there is one subtle point worth discussing.
When I first generated this sketch, it had an annoying bug. As the point count
changed, sometimes the geometry would get screwed up. I found a clever but overly complicated
hack to solve the problem. However, when I was cleaning up the code, I realized
that the problem was actually very simple to fix, and my complicated hack was a major
waste of time (sort of a pattern in my life). The problem related to the line
angle+=360/pts;
which I resolved by changing it to
angle+=360.0/pts;
You have to look closely to even notice the difference between these two lines. Adding the
.0 after the 360 solved the problem. Can you tell why? Originally, I thought the problem
related to needing the point count to be a factor of 360, which does solve the problem.
However, that was more of a symptom, not really the cause. The real problem was that I
was using two int values in the 360/pts calculation, which not surprisingly produced an
int; however, I needed a float value. By adding the .0 after the 360, the value was treated
as type float. Operations involving an int and a float will return a float. Thus, my angle
calculations, requiring float values, were getting rounded to int values, and I was slowly
losing accuracy, which screwed up the geometry. This may seem like an obscure point, but
it is a pretty common error in programming and can be a nasty bug to track down.
Sometimes rounding errors don’t show up for many iterations, as long as the error is small
enough. I recommend blaming the computer for these kinds of problems.
Toroids
Building upon the last few examples, it’s possible to put some of these ideas together to
build slightly more complex forms, such as toroids and related forms (shown in Figures 13-22
through 13-26). Toroids are ring forms (think inner tubes, bagels, or doughnuts). Toroids
also have an interesting relationship to spheres and helixes, which you’ll see in the following
example.
The algorithm for a regular toroid, where the cross-section shape is a circle and the toroid
radius is constant, might be as follows: