Un Coup de Dés
I got really interested in the way complicated, diverse systems could be created from relatively simple sets of rules applied to a limited set of tokens, or alphabets. These generative principles seem to apply to forms in nature as well as the grammars of human and artificial languages. But I wanted also to avoid creating a wholly deterministic system so I thought an element of accident or chance could be introduced by kicking the process with a dice roll, which always feels like a bit of a leap into the unknown.
produced by: richard moores
Introduction
The piece is an attempt to combine deterministic Lindenmeyer systems with an element of chance, in order to create unpredictible generative images, which retain something of an organic quality and potentially capture some of the fragility found in organic forms but not so often seen in computer graphics.
Concept and background research
The title of the piece is taken from Mallarmé's poem, 'Un Coup de Dés Jamais N'Abolira L'Hasard' [1], which continually plays with the tension between its chaotic appearance on the page and its underlying structure which verges on mathematical.
I was equally interested in the work of Przemyslaw Prusinkiewicz and the Biological Modeling and Visualization research group who use l-systems to try an accurately simulate nature, adding schochastic variation to try and make the results less geometric.
I found the theorectical background of formal grammars fascinating, and hadn't realised this was the area Chomsky was working in when he developed his theory of generative grammar (and consequently of child language developement).
Technical
The piece is run on Raspberry Pi computers: one (a Pi 3 model) does the detection of the dice and sends out OSC data on a wifi connection to a number of other Pis connected to screens. I had 4 model B Pi's to play with but would have scaled this up if possible. The receivers use the incoming data to construct l-system rulesets, which are then drawn according to a set of instructions associated with each member of the alphabet.
Everything is in openFrameworks - the arUco markers are detected using the ofxAruco addon (which in turn uses openCV). Data is sent and received using ofxOsc. The data is broadcast over wifi, but limited to one update per second to avoid flooding the network.
I wanted to avoid an obvious physical link between the dice rolling surface and the screens and also didn't want the dice end to look too 'technical'. The Pi's were useful in a multiscreen set-up which otherwise would have needed extra graphics processors and a large computer. This way more screens could be added by cloning the Pi's SD cards. I wanted the installation to have a chaotic appearance, with the wire and circuits of broken screens mirroring the forms on screen to a degree.
The main issue i faced was translating the incoming data (the numbers 1-6) into random but viable l-system rulesets which would produce interesting, branching systems without being over-determined. I also wanted to retain a family resemblance betwen the different interpretations across the screens. I had originally envisaged using numerical dice, and so my first arUco versions only used 6 different marker IDs. I realised I needed a way to differentiate between the 6 dice, so that i could map a specific dice consistently to the same parameter (angle, number of iterations etc) in the l-system, so i ended up using 36 markers to individually identify the dice by which 6 of the markers they carried.
I had to try and get to grips with a lot of more openGL than I'd previously used. OpenFrameworks is slightly different on a Pi, particularly as far as openGL is concerned. It uses openGLES 1.1, and though the Pi natively uses openGLES 2.0, switching to the newer version (which allows the use of shaders) broke some fundamental bits of ofxArUco and openCV. [if i understood what was happening, ofImage does not necessary create a CPU copy of a texture's pixels, which is what ofxarUco's detection function was passing around].
Lighting was also pretty important for the camera - with hindsight i would have painted the box interior white to reflect more light up at the dice.
Future development
Although the Pi's performed very well, I wanted to add more drama to the images by using camera and lighting (ofNode). I found that beyond a certain level of complexity the framerate dropped hugely. I then spent a lot of time trying to figure out a way to avoid re-drawing the entire system every cycle - by first drawing it into an fbo, or vboMesh, and then using a matrix to transform it, but needed a better understanding of the openGL processes. Equally i would like to see if it's possible to move the processing into a shader to speed things up. All the above depends on me gaining a much better understanding of openGL.
I think some screens should be wall mounted.
More colour variation would could be interesting, but would have to have a consistent palette .
Self evaluation
Overall I think the system produced some images i was really pleased with, which were delicate and intricate enough to seem naturalistic. The gesture of throwing the dice into box felt like a good way of triggering the system. Its possible to alter one dice at a time and get a discernable change in one aspect of the image.
Building in a way of curating the images is tricky - it can take a lot of throws before an interesting image is created. I wondered if I should have moved the code which seeds the random rulesets onto the sender, so that each receiver Pi started with the same sentence to which it could then add its unique variation. Possibly using a genetic algorithm rather than purely random selection. I think that would have created more of a consistent connection between the screens. I also suspect I should have used noise rather than random numbers to introduce variation, it seems less clunky and better suited to natural looking images.
I would include variations in colour - initially i liked the restricted palette but it got a bit tiring.
I was never very happy with the screen installation. More screens would help, some wall-hung. Viewing angles are definitely an issue. I wanted the electronic 'guts' to be visible but i don't think i properly resolved this aspect into the rest of the piece.
References
[1] Mallarmé poem image - WikiMedia Commons
ofxArUco - openFrameworks addon by Arturo, based on the AR library - http://www.uco.es/investiga/grupos/ava/node/26
'The Algorithmic Beauty of Plants', Aristid Lindenmeyer & Przemyslaw Prusinkiewicz at http://algorithmicbotany.org/papers/abop/abop-fm.pdf