Following on from my previous experiments with generative art and processing I decided to elaborate on my code and introduce more complex shape generation. I knew I wanted to introduce 3D and alpha blending, as well as refining the curves used to generate the lines.

A Beautiful Mistake

After getting my head around the 3D space and doing some rudimentary experiments I was ready to port my existing code into this new 3D world. I started playing some more with the brilliant OCD Library and had something I was kind of happy with.

At some point in tweaking and playing with the code I must have removed the line background(0); and (naturally) the screen was never cleared. What this produced when left to run for about 2000 frames was stunning.

The Result

So here they are, my beautiful mistakes generated by taking an image, getting a random pixel, positioning it randomly in 3d space then connecting an arbitrary amount of other random points to this point with bezier curves. The frame buffer is never cleared and the image are let to build up over thousands of frames.

Simply click on a thumbnail to view the enlarged version or you can view larger images on my flickr account or my HD gallery.

Now in Moving Picture™ format!

I’ve also got a couple of videos of the images being generated. The low-res previews which vimeo outputs don’t really do it justice, but at least you can view it in HD on vimeo (which you can’t with you tube.)

Now with a Z axis!

My next step is to try and generate these images in true 3D form, with camera control and give the whole thing a sense of depth. This is my first attempt.

I first discovered Processing in the summer of 2005. I downloaded the source code, had a play around with it and decided it wasn’t going to be worth me learning it. At the time I was very much design oriented in my endeavors and although I knew vaguely what the capabilities of Processing were, it’s lack of a substantial IDE or drawing tools made it no competitor to my main focus at the time: Flash.

Rediscovery & Inspiration

Fast forward 3 years and I’m now a developer, a code junkie, a command-line ninja. Although I sometimes miss the creativity that you get with design, I still love the art of writing code. I want the excitement of motion, interaction and form but also want the challenge of writing elegant software… I’d been thinking about re-visiting processing for a long time, hopefully it would satisfy these needs. I often kept an eye on the likes of Jonathan Harris & Flight 404 to see what they were up to, and was always inspired by the cool things these guys were doing with processing + generative art in general.

It was when a guy at work, David Standen started going on about processing, and his love for it that I thought “maybe i should look at this again”. I am after all now a programmer, and Processing is a DSL around Java, so why not learn it? I downloaded the latest version and started playing around…

Enter Pixel Path

I wanted something different, I ignored “good code” and went straight for the fun and creative, something non-interactive maybe. So what to do? I’ve always been really annoyed by the fact that I can’t really draw very well and I’ve never painted a picture in my life, so I decided to try and create some software that would create gorgeous looking “things”. Generative Art.

Inspired by this post I set about creating what would later become known as “Pixel Path”. The idea was simple, to analyze a given image, pixel by pixel and map every pixel to all other pixels of the same colour. Pixels would be identified by a dot and connected by lines, hopefully creating a sense of depth, texture and form.

Version 1 – Moss

The first version is based on a macro shot of a leaf, it maps every 100th pixel to up to another 100 pixels of identical colour. (Galleries each have 5 parts, use the thumbnails to scroll through them all.)

Total Pixels: 1,296,000 | Analyzed: 12,960 | Paths: 1,296,000

p1 – Moss

• 
• 
• 
• 
• 

view larger on flickr

Version 2 – Skin

In the second version I tweaked the algorithms to introduce more depth, points are rendered at 80% opacity and paths at 20%. The amount of pixels to be analyzed was also reduced to every 3500th, but the mapping limit increased to 1000 paths. The reference image was a macro shot of a group of feathers.

Total Pixels: 1,296,000 | Analyzed: 370 | Paths: 370,000

p2 – Skin

• 
• 
• 
• 
• 

view larger on flickr

Version 3 – Paprika

The third version used bezier curves to draw the paths with control points offset against the difference between the reference and target pixel. Every 850th pixel was analyzed up to 100 paths. The reference pixels in this version were distinguished with near 100% opacity. The image used was that of a red rose petal.

Total Pixels: 1,296,000 | Analyzed: 1,524 | Paths: 152,400

p3 – Paprika

• 
• 
• 
• 
• 

view larger on flickr

Version 4 – Rose

For version 4 I abandoned the dots for marking pixels, and instead relied on just the paths. The bezier curves were tweaked slightly to create smoother lines and only every 250th pixel was analyzed, up to 100 paths. The reference image was another rose petal, in pink.

Total Pixels: 1,296,000 | Analyzed: 5,184 | Paths: 518,400

p4 – Rose

• 
• 
• 
• 
• 

view larger on flickr

Version 5 – White

Version 5 was a slight departure from the norm, I inverted the canvas colour and this time decided to map the reference pixel to it’s first match, then all other matches to the next match (creating a flowing path) This version also draws two sets of paths for every match, one straight and one curved. Opacities were also massively reduced to only 5% and analyzed pixels increased to every 900th for up to 1000 paths. The first reference image was a different set of feathers and the second a forest scene.

Total Pixels: 1,296,000 | Analyzed: 1,440 | Paths: 1,440,000

p5 – White

• 
• 
• 
• 
• 

view larger on flickr

Version 5 – Forest

p5 – Forest

• 
• 
• 
• 
• 

view larger on flickr

Next Steps

• Introduce an element of randomness.
• Experiment with noise.
• Experiment with blending.
• Introduce the z-axis.
• Try using particles to generate “ink splats”.

it relies on the requested path to work out how to split the breadcrumbs, it alsoo requires that every component of your path is accessable, should be a good starting block though.

  def breadcrumbs(sep = "»", include_home = true)
    levels = request.path.split('?')[0].split('/')
    levels.delete_at(0)

    links = "You are here: "
    links += content_tag('a', "home", :href => "/") if include_home

    levels.each_with_index do |level, index|
      links += " #{sep} #{content_tag('a', level.downcase.gsub(/_/, ' '), :href => '/'+levels[0..index].join('/'))}"
    end

    content_tag("div", content_tag("p", links ), :id => "breadcrumb")
  end

The way these tools work by default they only allow you to deploy one instance of your application, which is fine, that’s all they’re are intended to do. But in the client facing world you’re probably going to want to have at least two versions of the same application at different stages of development running on the same server.

A live forward facing version (my-app.com) and a staging version (staging.my-app.com) for client approval / production testing (not code testing, that should stay on your development box) / progressive reviews etc.

So how do we achieve that? The idea is to determine what context you are deploying your application in, and use the fact the capistrano tasks can be chained together to set everything up ready for deploying a revision of your application to a targeted url, independent of other deployments.

Step 1

The first thing to do is to require the railsmachine recipes and setup some variables, as you will see later some of these variables are redundant, and the code has a fair bit of duplication, but this is a work in progress and I hope to clean it up when I have some more spare time.

require 'railsmachine/recipes'

set :application, "my-app"
set :deploy_to, "/var/www/apps/#{application}"
set :main_domain, "my-app.com"

set :user, "deploy"
set :repository, "svn+ssh://#{user}@my-svn-server.com/var/svn/#{main_domain}/trunk"
set :rails_env, "production"

role :scm, "my-svn-server.com"

You’ll notice that I’m keeping my my project on separate svn server, by default the railsmachine gem will create an svn repo for you as part of the project tree, this is really useful at first, but when you’re deploying multiple instances of the same application you’re going to want your svn repo independent.

Step 2

Now comes the clever bit, creating the tasks which will be called before our regular cap commands, like so $ cap -a staging deploy (which would deploy the current revision of your application to the staging server)

desc "Set staging instance variables"
task :staging do
    set :application, "my-app-staging"
    set :domain, "staging.my-app.com"
    set :apache_proxy_port, 8010
    set :database_yml, "database-staging.yml"
    set :deploy_to, "/var/www/apps/#{application}"

    role :web, domain
    role :app, domain
    role :db,  domain, :primary => true
end

desc "Set production instance variables"
task :production do
    set :application, "my-app-production"
    set :domain, "my-app.com"
    set :apache_proxy_port, 8000
    set :database_yml, "database-production.yml"
    set :deploy_to, "/var/www/apps/#{application}"

    role :web, domain
    role :app, domain
    role :db,  domain, :primary => true
end

What this does is set all of the variables which any command you’ll call after staging or production will need, it’s pretty ugly at the moment and I hope to clean it up and make it a lot smarter, but for the moment it works, and in it’s ugliness it does make it clear what it’s doing.

Step 3

Next we overwrite the railsmachine setup_scm task and one of the tasks it calls, we’re doing this because we are using a custom location for our repository and not the one which the railsmachine gem tries to create for us.

In my particular situation I have an external server used for svn, but the repository could just as easily be on the same server as your application just so long as the folder you create the repo in is in the deploy group. Also in my situation I am creating a new repo for each project I deploy, if you already have a repo that you deploy all projects to you could easily just remove the setup_svn_repo task call from the setup_scm task.

Enough talk, on with the code:

desc "Setup svn repository"
task :setup_svn_repo, :roles => :scm do
  dir = "/var/svn/#{main_domain}"
  run "mkdir -p #{dir}"
  run "chmod 770 #{dir}"
  run "svnadmin create #{dir}"
end

desc "Setup source control server."
task :setup_scm, :roles => :scm  do
  setup_svn_repo
  import_svn
end

Step 4

Because different instances of our application are going to need different databases we have to overwrite the method which read’s in the database configuration when setting up the database for the first time. The way it works at the moment we also need to remove the database.yml file from svn control, and recreate it from the correct file after every code update.

task :clean_db_yml do
  puts "removing database.yml from svn"
  system "svn remove config/database.yml"
  puts "ignoring database.yml"
  system "svn propset svn:ignore 'database.yml' config/"
  system "svn update config/"
  puts "committing changes"
  system "svn commit -m 'Removed and ignored database.yml file'"
end

def read_config
  db_config = YAML.load_file("config/#{database_yml}")
  set :db_user, db_config[rails_env]["username"]
  set :db_password, db_config[rails_env]["password"]
  set :db_name, db_config[rails_env]["database"]
end

task :after_update_code, :roles => :app do
   correct_db_yml
end

task :correct_db_yml do
  put(File.read("config/#{database_yml}"), "#{release_path}/config/database.yml", :mode => 0444)
end

Thats all there is to it, I run the following commands to set up an instance of my app:

cap -a staging setup
cap -a staging setup_scm
cap -a staging setup_servers
../[new directory]
cap -a staging clean_db_yml
cap -a staging cold_deploy
cap -a staging restart_web

cap -a staging deploy
cap -a staging deploy_with_migrations

The End

There you have it, it works, it’s not the most elegant solution and definitely something I want to work further on. The last section with database.yml stuff is by far the ugliest, but it is a work in progress, and I plan to make further amendments to it.