Recently, I dusted off my copy of “The Computational Beauty of Nature” and started rediscovering this still wonderful book. The chapter about IFS fractals inspired me to do some experimenting with animated fractal shapes. An opportune moment to learn more about Processing! After playing with it for a few hours, I have to say, this is a wonderful programming environment for this kind of visual experiments. Virtually no boilerplate code, cumbersome project setup, etc. Just start hacking away on your ideas. Based on Java, it is not a toy language either, so all the usual data structures and OOP constructs are readily available.

An additional treat: With processing.js, it is quite easy to run a processing application in a browser. See the IFS animation demo in the new demo section on the left (hope to add more to that category soon 🙂 ). Support is not complete, though: I had to rewrite my demo to some extent, because processing.js doesn´t support the PShape class very well yet, which is quite essential to get good performance in a particle system demo… so I reduced the visuals a bit. Still, much easier than having to go through and translate everything to JavaScript myself!

Bouncing Ball Physics

To revive my Blender skills, I’ve been tinkering with setting up a simple bouncing ball animation. How do you keyframe this properly, without running a physics simulation? There are tons of tutorials on the web on basic bouncing ball demos, but few go into details about what a physically plausible bouncing ball trajectory would look like. As it turns out, with an ideal bouncing ball, there are only a few basic ingredients:

  • The path is obviously a series of parabolas
  • With each bounce, a roughly constant fraction of the energy is lost. The exact value depends on the material of the ball – the magic term is “coefficent of restitution” (COR). The height of each parabolic arc is f * previous_height, where f is in the range (0,1).
  • Assuming no slowdown in the horizontal direction, the distance between touch down positions (resp. duration of a bounce) shortens with the square root of f.

So far, so good, but is this model realistic? I did a few experiments tracing bouncing ball trajectories from video.

First, a tennis ball (at 50 fps):

Doing rough calculations based on the pixel positions of the ball’s center, the behavior is close enough to the model, with a COR of roundabout 0.55. Great.

Second, a very squishy rubber ball:

Surprise: The same calculations show that this ball keeps bouncing a bit higher than expected every time! The COR raises from 0.34 to 0.55 over four bounces. I even repeated the experiment, with similar results. Apparently, a non-constant COR is not unusual at slow speeds, as mentioned e.g. in the Wikipedia article on the subject.

Qt and OpenGL programming in Python

Qt is a well-established framework for developing GUI applications in C++, and it has good support for OpenGL. It is relatively cumbersome, though, to set up a project for just a simple, experimental application. Moreover, even though Qt and OpenGL are portable, carrying over your project from, say, your Linux box to a Windows PC is not completely seamless, due to different compiler configurations, etc.

Being a Friend of Python, I was looking for a way to make life simpler in that respect. Can you use Qt and OpenGL in Python? You can!

There are three packages you want to have a look at:

The Windows binary installer for PyQt4 already contains a copy of the Qt libraries (4.6, currently). so you don’t have to install Qt separately.

Once all this is set up, writing the application itself becomes fairly easy. Here’s an example to get you started, the famous spinning color cube — complete with application menu and status text:

import sys
from PyQt4 import QtCore
from PyQt4 import QtGui
from PyQt4 import QtOpenGL
from OpenGL import GLU
from OpenGL.GL import *
from numpy import array

class GLWidget(QtOpenGL.QGLWidget):
def __init__(self, parent=None):
self.parent = parent
QtOpenGL.QGLWidget.__init__(self, parent)
self.yRotDeg = 0.0

def initializeGL(self):
self.qglClearColor(QtGui.QColor(0, 0, 150))


def resizeGL(self, width, height):
if height == 0: height = 1

glViewport(0, 0, width, height)
aspect = width / float(height)

GLU.gluPerspective(45.0, aspect, 1.0, 100.0)

def paintGL(self):

glTranslate(0.0, 0.0, -50.0)
glScale(20.0, 20.0, 20.0)
glRotate(self.yRotDeg, 0.2, 1.0, 0.3)
glTranslate(-0.5, -0.5, -0.5)

glDrawElementsui(GL_QUADS, self.cubeIdxArray)

def initGeometry(self):
self.cubeVtxArray = array(
[[0.0, 0.0, 0.0],
[1.0, 0.0, 0.0],
[1.0, 1.0, 0.0],
[0.0, 1.0, 0.0],
[0.0, 0.0, 1.0],
[1.0, 0.0, 1.0],
[1.0, 1.0, 1.0],
[0.0, 1.0, 1.0]])
self.cubeIdxArray = [
0, 1, 2, 3,
3, 2, 6, 7,
1, 0, 4, 5,
2, 1, 5, 6,
0, 3, 7, 4,
7, 6, 5, 4 ]
self.cubeClrArray = [
[0.0, 0.0, 0.0],
[1.0, 0.0, 0.0],
[1.0, 1.0, 0.0],
[0.0, 1.0, 0.0],
[0.0, 0.0, 1.0],
[1.0, 0.0, 1.0],
[1.0, 1.0, 1.0],
[0.0, 1.0, 1.0 ]]

def spin(self):
self.yRotDeg = (self.yRotDeg + 1) % 360.0
self.parent.statusBar().showMessage('rotation %f' % self.yRotDeg)

class MainWindow(QtGui.QMainWindow):

def __init__(self):

self.resize(300, 300)
self.setWindowTitle('GL Cube Test')


glWidget = GLWidget(self)

timer = QtCore.QTimer(self)
QtCore.QObject.connect(timer, QtCore.SIGNAL('timeout()'), glWidget.spin)

def initActions(self):
self.exitAction = QtGui.QAction('Quit', self)
self.exitAction.setStatusTip('Exit application')
self.connect(self.exitAction, QtCore.SIGNAL('triggered()'), self.close)

def initMenus(self):
menuBar = self.menuBar()
fileMenu = menuBar.addMenu('&File')

def close(self):

app = QtGui.QApplication(sys.argv)

win = MainWindow()


Ok, so it’s still 120 lines for a spinning cube, but the overhead is considerably smaller. And you can run this program as is on any platform. To me, it doubles the fun 🙂