During my exploration of particle systems in Processing, I found that at some point of time I would like to print the result. Outputting an image file containing the current frame is very easy in Processing with the saveFrame() function. However, this is exactly the width/height of what you render on-screen – which will be limited at some point. If I would like to print the output, say on A2, 640 by 480 px isn’t going to cut it – and 1920×1080 (max screen size) isn’t sufficient either.

I needed a way to draw off-screen and into an image file – preferably with a preview rendered on-screen.

Of course I started searching the Processing forums – as well as Google. Albeit searching for “Processing off-screen” isn’t that unique.. (Note to programming language designers: Name the baby something unique for easier searching..). As it turned out – I didn’t find as much as I hoped to.. Not until I found the chapter list from the book “Processing: A Programming Handbook for Visual Designers and Artists” – which had a separate chapter on high-res output – perfect! Heading to the university library database – and as magic – the library had one copy of the book! So, eventually the physical information container won..

It turned out that high-res output is really easy. You initialize a separate PGraphics object which you draw to – and omit drawing to the standard drawing object (which I guess is also an instance of PGraphics). For instance:

PGraphics big;
void setup() {
  big = createGraphics(5000, 5000, JAVA2D); // Create a new PGraphics object 5000x5000px
  big.beginDraw(); // Start drawing to the PGraphics object
}
void draw() {
  big.fill(255,0,0);//we fill following with red
  big.ellipse(random(big.width),random(big.height),10,10);//randomly placed circle
}

/**
* We save on any key
* this could be done in void close() but safer to have it here.
*/
void keyPressed() {
  big.endDraw(); // finish drawing
  big.save("highRes.tif"); //save to file - use .tif as format for high-res
  println("saved"); // nice with some feedback
}

The above code will not produce anything on screen. So your more or less blindly choosing saving images. The following code draws the image to the screen in a scaled version every now and then in order to preview the image.

PGraphics big;
void setup() {
  big = createGraphics(5000, 5000, JAVA2D); // Create a new PGraphics object 5000x5000px
  big.beginDraw(); // Start drawing to the PGraphics object
  size(500, 500, P2D); //size of the on-screen display
}

int counter; // counter
void draw() {
  counter++; // add 1 to counter
  if(counter%10 == 0) { // every 10th frame we snap a preview and draws it
    PImage img = big.get(0, 0, big.width, big.height); //snap an image from the off-screen graphics
    img.resize(width,height); // resize to fit the on-screen display
    image(img,0,0); // display the resized image on screen
  }

  big.fill(255,0,0);//we fill following with red
  big.ellipse(random(big.width),random(big.height),10,10);//randomly placed circle
}

/**
* We save on any key
* this could be done in void close() but safer to have it here.
*/
void keyPressed() {
  big.endDraw(); // finish drawing
  big.save("highRes.tif"); //save to file - use .tif as format for high-res
  println("saved"); // nice with some feedback
}

My fascination for particle systems is endless – and no, not the fancy complex things producing “real” images – the simplest one :)

In my exploration of both Processing and particle systems I created a Processing sketch which augments a user controlled particle system on top of a world map. Below is a sample image of one potential output as well as the code and application.

Well, so what’s the point? I have no idea – but I’m still fascinated of the results for this. Inevitably I’ll have to find something useful application of this? Or maybe it the artistic contribution is enough?

Particle system augmented on a world map

Source and application

Instructions:

// MouseLeft: Add attractor (almost not visible circles)
// MouseRight: Start particlesystem
//
// Space: Reset
//
// s: save the positions in "positions_xx.txt" (OBS! Gets very large - very fast!)
// Enter: Save frame to frame-xxxx.png

The prototype for map interface for bus routes experienced some downtime and halt in further development. This spring the project received further enthusiasm from the bus company in Trondheim and Professor Amble at NTNU. They found the prototype interesting and wanted further exploration of different map integrations for bus route systems.

Mats Taraldsvik, a student at Geomatics NTNU volunteered to program several demo systems for different ideas.  This resulted in some excellent prototypes. Essentially the ideas developed differed a bit from the main idea of map interface. On this project the core idea was to integrate maps rather than use a map as the primary interface.

1. First test of communicating the bus route in a map.

The goal was to have the user provide the “to and from” address/bus stop then query the route answer engine (BussTUC) as well as display a map containing the bus route. The result can be found here:

http://geomatikk.eksplisitt.net/taraldsv/

2. Walking directions from arbitrary address to the nearest bus stop

Using Google Maps walking directions combined with the local database over bus stops the system is able to display the shortest walking path to and from the bus stop. Demo here: http://geomatikk.eksplisitt.net/taraldsv-gangkart/

3. Combining and refining bus route display

The bus route calculations done in 1. was to inaccurate using Google Maps driving directions, in addition it didn’t include the walking directions very well. This demo illustrates the possibilities of including an accurate bus route as well as (simple) walking directions. Demo here: http://geomatikk.eksplisitt.net/taraldsv-bussrute/

All of the above prototypes are intended as prototypes only – and all have large potential for improvement and further integration. However, I find the idea of integrating maps in this way very handy, especially for non bus-spotters (i.e. tourists, non-frequent bus’ers etc) which probably is (or should be) the target group for a bus route query system.

Of course I still think the idea of using  a map as the primary interface is a good idea which should be further explored. Mainly the problem relies on the data holders/owners of the bus route and stops. If this data is made freely available the step from prototype to “beta” could be made. (hint hint data owners…)

For more ideas and thoughts on the map/bus integration take a look at this wiki page: http://folk.ntnu.no/alexanno/projects/index.php/BussMap

For the sake of data sharing you can find a dump of the current bus stops and their coordinates on: http://geomatikk.eksplisitt.net/bussMap/data/ The data is formatted in CSV with the first line being header text. Coordinates are in WKT and EPSG:4326 (WGS84:lat/lon) accuracy or availability is never guaranteed.