3.11

## Monash University

Skip to 0 minutes and 5 secondsIn the following exercises we're going to abstract a physical process to devise a Processing sketch. We'll start with the motion of a spinning top as it moves across the a page. We can imagine the path that it traces as it goes. Of course the obvious ' and probably uninteresting ' approach would be to simulate all the physics of the top. Not only would this be technically complex, it would probably be creatively unrewarding. So instead, as a starting point we'll use the sine and cosine functions we've been discussing to mimic the path of the top.

Skip to 0 minutes and 38 secondsAn important step in developing a coding sketch is to make some real sketches, because its usually easier to quickly explore visual ideas using a pen and paper than a computer. After a little play and exploration we came up with the idea to mimic the spinning motion of the top by drawing a line that is constantly revolving around the centre of the path. We'll then take this basic system and turn it into a series of rules and then a sketch. The sketch won't simulate a spinning top, it's just developing the kinetic aesthetics of the top's behaviour as a starting point. From this starting point there are a number of ideas that can be explored.

Skip to 1 minute and 17 secondsYou'll have the opportunity to further develop the sketch to let it do things that the spinning top couldn't do.

# Spinning top

Watch Jon McCormack outline another basic approach to developing rule-based sketches: start with a simple physical process and derive a set of rules that capture what is interesting to you about that process.

For this example, we used a spinning top moving over a surface. The top traces out a curved pattern as it moves across the paper.

Open and run the w3_04 sketch. This sketch simulates the drawing motion of the top using sin() and cos() functions. Let’s look at some important parts of the code.

The position of the top is stored in two float variables, x and y. At each frame the position of the top is incremented by a small amount (dx and dy – representing the instantaneous velocity of the top). The top always starts in the middle of the screen, moving in a randomly chosen direction.

If the top gets close to the edge of the window the direction is reversed and the velocity is changed. Here’s the code section that checks in x:

if (x > width-100 || x < 100) {
dx = dx > 0 ? -random(min, max) : random(min, max);
}


You should already be familiar with this if statement, it’s saying that if the x location of the top is closer than 100 pixels to the edge of the window then change the value of dx.

The statement inside the if is an operator we haven’t encountered before: the conditional operator, ?. This is a really a shortcut way of writing an if statement. It is a ternary operator because it takes three arguments. The general form is:

result = test ? expression1 : expression2;


This is a shorthand way of saying:

if (test) {
result = expression1;
} else {
result = expression2
}


As you can see it saves a lot of space.

The movement of the top is linear (in a straight line). To see this you can modify the code to draw the position of the top (x, y) using point() or ellipse(). To get the smooth motion of the top, we rotate a point about (x,y) fixed at 100 units:

float bx = x + 100 * sin(rad);
float by = y + 100 * cos(rad);


The code goes on to calculate the position of a rotating ‘hand’ that is spinning around this position. For a little more interest we made the distance from the length of the ‘hand’ oscillate slowly:

float radius = 100 * sin(rad*0.1);


This combination of two different oscillations is enough to give the path a kinetic sense of “spinning-top-ness” without having to simulate all the physics of a real spinning top.

Can you devise a set of rules (in plain English) that describes what this sketch is doing? Post your answer in the comments. Please take time to read though some of the posts and try to comment on at least one.

One final thing of note. What is this code doing?

blendMode(BLEND);
fill(0, 5);
rect(0, 0, width, height);


Here’s a hint: there is no call to background() in draw() – this code is doing a special kind of erasing of the screen. Experiment with the alpha value passed to fill() to get a better idea of what’s going on.