More selected projects

Chaos Puzzle

This project uses webcam input to play with the concept of visual order. Starting with a simple sliding puzzle it solves itself, disolves into chaos, and reforms as a grid. It asks the viewer whether fractured images have more order than simple dots with clear rulesets.

produced by: Charlotte Dann

Find the code for this project on Github


Due to the project restrictions I started knowing I wanted to use webcam input somehow to enhance the complexity of my piece. As an avid puzzler, making something that had both confusion and resolution was a very attractive idea to me, and after experimenting with offset slicing of webcam imagery I decided that making a puzzle using different sections of a webcam image would be a fun concept.

Solved slide puzzles are boring, so I knew I had to have the program begin with it messed up and then slowly solve it. Instead of randomising the whole grid and using clever algorithms to figure out how to solve it, I went with the much simpler path of chosing a random direction for each move and keeping a record of those moves, so when the program starts it moves x times, and then does the opposite of those moves in reverse order in sequence.

Three minutes of solving a slide puzzle would also be boring. I definitely wanted to use the slide puzzle more than once, so knew I had to find a way to transition between the fixed grid and another messed up grid. The most exciting way I thought to do this was to reduce each tile to a particle and have them zoom around the page using flocking algorithms and then reassemble into a grid and grow back into tiles.

I really liked the idea of using Voronoi-like diagrams with the same gutter as the tiles to visualise the particles – that way they would naturally form the same grid as the puzzle when the particles are in a regular formation, eliminating the neccesity for complex visual morphing between the scenes. Alas, without the allowance for addons, this proved to be too difficult to achieve. I decided instead to determine the size of each of the particles based on its proximity to other particles in an attempt to visually take up as much space as possible. Since each of the particles had long-range attraction and short-range separation behaviour the size of each particle remained unstable, tending towards interesting visuals.


This project presented a number of technical challenges due to the changability of each element.

The first issue I stumbled upon was about performance. Because I made each tile an instance of a class, and wanted to be able to draw the image slice from inside the class, I had to save a subsection of the image in each tile instance, and update it from the main webcam feed. Manipulating images like this is very CPU heavy and brought the frame rate down to an unacceptable 5fps. I ended up updating the tile images every 5 frames, but to make it look less jerky decided to use the position of the tile to determine which frame out of 5 it updated on, resulting in a continual diagonal sweeping update of the tiles, which looks pretty cool.

Another challenging aspect was the transitions. To create more conflict in the piece I made all the tiles transition into the next scene at different times depending on its position in the grid. Because of the jump from image to square to circle back through square to image, I ended up with a variety of easing methods to create the smoothest effect possible. The sliding of the tiles uses a cubic ease-out function and their reduction into squares uses a cubic ease-in function, I wanted to be specific about their easing because their transitions are visual focal points. Many other transitions—like that of the shape shift between circle and square, and the fading from squares back into image sections—are incremented linearly because, since they don't happen simultaneously, there are lots of visual distractions so their smoothness is not important. Several transitions—like the colour of the dots—are done by lerping between the current value and target value; since the target value changes periodically a transition akin to Zeno's paradox is most appropriate. The hardest transition to accomodate was reforming the grid from the flocking particles. I needed to transition from their current position into the target position on the grid, but using pre-build easing functions didn't look right because the current position, and therefore flocking behaviour, was constantly changing. I ended up with a solution similar to the one for colours but increased the degree that it lerped exponentially from a very low value which resulted in a very smooth and low-conflict transition.