Just in time to celebrate unix epoch time 1234567890, Buza and I have finished a new website to host E15:oGFx.

The site features our first public binary in the download section, E15:oGFx ALPHA 001, a small collection of examples and tutorials to get you started, and a gallery of advanced scripts in the featured section.

We also spent the last few minutes before unix epoch time 1234567890 posting a few improvised E15:oGFx scripts inspired by the occasion to E15:WEB.

This is a demonstration video we put together a couple of months ago:

• http://www.vimeo.com/ogfx
• http://www.vimeo.com/e15

It helps a lot to understand what these things are about when you look at them in motion.

Places like the MIT Media Lab tend to push towards figuring out new ways to make technology mediate between humans and their needs. There are many cases where this mediation might lead to an improvement of human life, but in many others the result is simply alienating. Writing instructions that make pictures instead of making pictures with my own hands is an interesting separation. Sharing the way these instructions change as I search for a different picture might illuminate about some aspects of computational art, but It could also be just another way to produce data where patterns could be found, just as it seems everybody everywhere is doing these days. We live, after all, in a statistical world.

The studio application is called MyStudio. The following image shows the first 110 pictures I published there:

However, when thinking about experience and interaction, overwhelming your subjects with too much input can become a problem, and it is especially hard to design experiences that can be interaction rich and at the same time make sense. The world and our perception are a perfectly balanced system where everything seems coherent and accessible to our senses, at least most of the times, but when it comes to manipulate tools with a specific goal in mind, narrowing interaction down to the minimum gives us the advantages of focus and control. When drawing for example, every single artist in history has used the single point touch of the charcoal, pencil, pen or brush over a flat surface, performing a slightly different gesture, but just as limited, than the one imposed by the mouse. When creating a drawing with the pencil or the mouse, the differences come from the reactions of the material (paper or similar for the pencil, and computer for the mouse), and not from the devices. A mouse can be given the shape of a pencil, and used over a pressure sensitive display, it responds to the drawing gesture just as a pencil would.

Because of this reason, and because the human drawing gesture is a perfect source for random input, we have introduced mouse input into oGFx. There are several different ways to draw in oGFx. The drawing gesture can be mapped from screen coordinates to 3D coordinates in the OpenGL context or 2D coordinates in the Quartz2D context. We started by making the raw screen coordinates available to the python interpreter, so the decision of what to do with them could be taken by the programmer of the drawing experience.

I wrote a few scripts that map the screen coordinates to Quartz2D coordinates, adding some behavior to the strokes, a simple implementation of the Bresenham line algorithm, and a low resolution canvas. I have been working with simple drawing tools for a while, and I found oGFx to be a refreshing platform to experiment with, specially because of the four following reasons: I can change the definitions in a script without having to stop the program (or even stop drawing), I can draw and navigate around a drawing in 3D at the same time, I can apply and remove CoreImage filters on the fly, and I can project the action of drawing over history. Even though all these reasons are some of the important features of oGFx that we have been using from the beginning, they were not combined with hand drawing until recently.

I recently finished the first iteration of glLight support for oGFx , and already experienced a lot of pleasure playing with it in some of the scripts we have made in the past. Following the advice from J. Popovic, teacher of the MIT Computer Graphics undergraduate class, I wrote some code to turn on and off graphical representations of some of the objects in the oGFx context, making it easier to debug otherwise hard to track things like light directions, light positions and surface normals.

Here is a very rough (and I mean it) video where you can see the influence of the light in motion over a scene where I was manipulating an interactive animation I made using quadratic Bezier curves from Apple’s Quartz2D, and here is another one, same degree of roughness, and a different use of the same curves.

More Blood. La sangre!