Tue Dec 31, 2013
This is a semi-automated backup of my old Tumblr account.
Obfuscating
12/23/2013
Live coding
12/12/2013
I don’t have the source code for this program. Actually, the source code never existed as such. I live coded it. I wrote size(875, 875) and the window got resized. I wrote background(0) and it turned black. I never pressed any Run / Stop buttons.
It’s an interesting approach, as stuff happens while I think about what to do next. If I think too much the result can be ruined, so I keep an eye on what’s happening while I decide what to write next. I must consider what I type, and also when I type it. The exact moment you press return actually matters.
This was my first Scala program ever. I wrote it using sp5repl (Scala Processing REPL). A REPL allows you to evaluate (run) single lines of code, the compiled code gets injected into your running program, and the result is immediately visible on your canvas.
Scala and Processing both output Java bytecode, and both can use the great Processing libraries. Scala is much less verbose, which I really like. I want a Scala based PDE! :)
Nodebox
12/07/2013
My first animgif programmed in Nodebox. I still prefer code, but I see the advantages of Nodebox:
- Pause, play and rewind your animation.
- Go to the previous and next frames.
- Tweak values and modify your program *while it runs*. No need to stop and restart your program. This is great for experimentation.
- Export a range of frames.
- Export an mp4 movie or a vector PDF file.
- You can write your own modules in Python and Clojure.
What I don’t like:
- No animgif nor gif export.
- Each time I export I must set the range and file format.
- Frame rate not so high.
- No access to the great collection of Processing libraries (midi, webcam, graphic tablet, OSC, etc).
It’s great for people learning to code, and for those who don’t like typing code. It may also be great for sketching concepts, tweaking values and experimenting, to later port the idea to an environment that performs faster.
Our creations are influenced by the tools we use. I suspect the kinds of creations we produce by typing code (Processing, Open Frameworks, SuperCollider) and by connecting nodes with wires (Nodebox, PD) can differ, the same way the kinds of results we get when using different programming languages can also be different. For instance, some languages make it easier to write recursive programs. Other languages make it easy to work with big data sets, or with strings. I wonder… what is Nodebox best at?
Current currents
12/06/2013
Miso star soup
12/06/2013
Unendliche
12/04/2013
When I look from a distance without observing the details, the animation looks quite organic to me. Something like flocking birds or snow flakes spinning in the wind.
When I pay more attention, I discover something disturbing. The motion is unnatural. All points move in perfect circular orbits, and each point has the same exact separation from previous and next points in its orbit.
It looks organic but it’s a machine.
Now that I think about it, this represents the world. It’s all made of electrons spinning around protons in perfect orbits, and yet it looks like trees, faces and ice cream.
Science Journal cover
12/03/2013
A 300 dpi version (3000 x 3000) of this for the cover of VerbundJournal (a science journal). It involved writing my own simple dither algorithm to avoid bands of flat color in gradients.
12/03/2013
Accelerating and deccelerating rotation
I was asked by a follower how I programmed this animation in which objects have non-constant rotation speeds.
Think of a comet flying around the sun. It comes from far away, it rotates around the sun (close to it), and then it flies far away again. If you would see this from above and draw a line between the sun and the comet, the inclination of this line would not change much when the comet is far away, but it would change quickly when the comet is near the sun. Even if the speed of the comet was constant.
The atan2() function gives you the inclination of this line.
If you trace a line from the sun to a planet, and the planet is rotating around the sun always at the same distance, you get a constant angular speed.
If you trace a line from the sun to a planet that is rotating around the sun, but the rotation center does not match the position of the sun (the center of rotation is displaced, so the sun is closer to one of the borders of the circle described by the planet), you get an angular speed that speeds up and slows down.
This happens because sometimes the planet is closer to the sun and sometimes is farther away.
I use atan2() to calculate this angle. The arguments for the function are the y distance and the x distance between a fixed point (the sun) and an orbiting point (the planet). I calculate the moving point using the circular-motion formula, using sin() and cos().
The closer the inner point is to the orbit, the more extreme the speed variation.
I use the calculated angle again inside the circular motion formula to place objects on the screen. This angle no longer increases at a constant speed.
To make different objects speed up and down out of sync, I either place the “sun” on a different location for each orbit, or I add an offset to the rotation of each planet (kind of setting one planet on winter and the other on summer). In the end, one planet is closer to the sun when another planet is farther away, so they speed up and slow down at different times.
The source code is linked in the original post.