Another MRes Processing assignment, and on this occasion – something cellular automata related.
In an effort to again try out some Processing ideas that I hadn’t used before, the application created for this is 3D.
The application itself is based on Conway’s Game of Life, the basic idea of which is “to start with a simple configuration of counters (organisms), one to a cell, then observe how it changes as you apply Conway’s ‘genetic laws’ for births, deaths, and survivals”.
The initially defined rules are:
- Survivals. Every counter with two or three neighbouring counters survives for the next generation.
- Deaths. Each counter with four or more neighbours dies (is removed) from overpopulation. Every counter with one neighbour or none dies from isolation.
- Births. Each empty cell adjacent to exactly three neighbours–no more, no fewer–is a birth cell. A counter is placed on it at the next move.
For this version of it a cell’s neighbours are the 2 cells either side of it in each of the 3 planes. The rules used are:
- Survivals – cells with 2 live neighbours will continue as they are
- Deaths – cells with 0 or more than 4 live neighbours
- Births – cells with 1, 3 or 4 live neighbours
In the application the dead cells are coloured green, live cells start off pink and get brighter turning yellow and then white depending on how long they’ve been alive.
As the neighbour cells being used to determine the future of each call do not wrap this can lead to the edges of the cube becoming permanently white. The two examples below show how this can, but doesn’t always, happen.
In these versions the dead cells are not drawn.
The most recent MRes Processing assignment was to show the flow of journeys from a day of London bike hire usage. My previous Processing visualisations have all been quite dynamic, the kind that run through data on their own. For this one I decided to take a different approach. It’s an interactive visualisation where the user can click on any of the bike hire stand locations to see where the journeys went to from that stand.
The when the app starts it looks like this
The size of the stand locations shows the number of journeys from that location. Clicking on a stand then shows which other stands those journeys went to
The brightness of the line indicates the number of flows from the clicked stand to the stand the line goes to.
Some of the stands didn’t have any journeys made from them – I assume that the stand existed but wasn’t fully open on the day the data is taken from.
If the user prefers to have more of an idea where the stand locations are, pressing space will display a map background instead of the more basic one
Overall I’m really pleased with how it has turned out. I think it’s quite useful for seeing the journeys made from each of the hire stands, and I like the way it looks.
Here’s a video showing the app in use
A visualisation of a week’s worth of geocoded tweets that were all in or around Greater London.
It’s a fairly simple Processing app, displaying each tweet in order. The ellipses displayed at each point though stay for 5 seconds, getting gradually smaller and darker with each second. The best way I could think to do that was with a fading point class for each tweet. This is then poked every second to both update, and then return whether it should be removed from the stack of points or not.
Playing around with this also reminded me how to sort an ArrayList. My Java knowledge is slowly returning..
After playing around with the code I now have a suitable video of the bus route map being created. Time and file size savings were made by experimenting with the processing MovieMaker class, and also using it more wisely. Firstly it was changed to only add a frame every other time a new stop is added – there are a lot of stops and it runs quite quickly so this is hardly noticed. I also played around with different MovieMaker settings, in the end I found that using ANIMATION (type) and HIGH (quality) gave the best compromise between file size and quality.
The video has a marker that shows where it is currently drawing, which is handy towards the end when the map gets quite crowded. Because of the way I added it in though, it meant that I was re-drawing the whole map each time up to the point of the current stop. This is a very uneconomical way of getting what I was trying to achieve, but as video frames are grabbed only at the end of each draw of the map it made no difference to the video size. What it meant was that it took hours to create. Since making the video I’ve looked more into using buffered windows. A far better way to make the video would have been to build up the map on a buffer and then on each call of draw: clear the screen, add the buffer image, and then place the current position circle. The end result would have been the same though:
To kick off this blog…
I recently attended a Data Hack Day at the London Transport Museum, run by onedotzero and Protein. A day spent at the London Transport Museum was a good enough reason to get me there, playing with data was an added bonus.
Some really interesting work was done with the data – a few of them can be seen in the Protein link above. I spent part of the day playing with a csv file containing a list of stops on every bus route in London. There wasn’t that much time but it turned out to be relatively simple to create in Processing a map of London based solely on the bus routes. It spends about 20 minutes drawing the routes, stop by stop, and when done you get this:
The colours don’t refer to anything in particular, they just change as the creation of the map goes on to make it look more interesting. When I’ve managed to create a suitable video (one that isn’t 20 minutes long and huge), I’ll put that up here.