dave's blog of art and programming

missing acceptable use policy

This is the emotional colour map for Germination X. It's a 22 by 8 sized image, with 8 colours for each OCC emotion (those we haven't done yet are white).

From left to right, these represent: LOVE, HATE, HOPE, FEAR, SATISFACTION, RELIEF, FEARS_CONFIRMED, DISAPPOINTMENT, JOY, DISTRESS, HAPPY_FOR, PITY, RESENTMENT, GLOATING, PRIDE, SHAME, GRATIFICATION, REMORSE, ADMIRATION, REPROACH, GRATITUDE, ANGER.

It's primarily based on a set of colours Lina has been working on. She found it useful to group the emotions into positive and negative sets. Something I think is significant is that these colours were made with the colours of the plants and the general feel of the game in mind. I think the problems I found with this exercise was a lack of context - perhaps thinking too abstractly about this is a bad idea.

It's great to see this work being picked up by the Life project by Evan Raskobb at Space Studios - looking forward to seeing more of where they go with this.

We're currently putting the new plant spirit characters in Germination X and thinking more about how to use colour changes as part of the expression of the many emotions the FAtiMA agents contain.

I made this chart quickly, deliberately avoiding thinking about potential reasons for my choices. Interestingly I found I needed to start with the motion curves first (which describe how the colours are blended between over time) and these seemed much less arbitrary than the actual colours I chose. The reason could be that there is a closer connection between movement (however simple) and gestural expressions.

A third and final update on the Mathematickal Arts Workshop - following the previous outline, some more detail on the process of going from software to textile using plain weave.

First create a program and choose the colours:

Axiom: O
Rule: O => : O O :
Repeat 5 generations

: = Green
0 = Orange

Then "compile" the code to expand the pattern:

1= O
2= : O O :
3= : : O O : : O O : :
4= : : : O O : : O O : : : : O O : : O O : : :
5= : : : : O O : : O O : : : : O O : : O O : : : : : : O O : : O O : : : : O O : : O O : : : :

The resulting weave can be previewed in ASCII as described earlier. This was useful to discover the range of patterns possible. When done, install the compiled code on the loom as a warp thread colour sequence.

Then you follow the same sequence for the weft threads, choosing the colour based on the code generated. In this way you become a mere part of the process yourself.

This is another, more complex program with 2 rules. This expands rather quicker than the last one, so only three generations are required:

Axiom: O
Rule 1: O => O : O :
Rule 2: : => : O :
Run for 3 generations

This technique draws comparisons with Jacquard looms, but obviously it's far simpler as the weave itself is the same, we are only changing between 2 colours (and a human is very much required to do the weaving in this case). However, one of the activities I would have tried with more time available would have been reverse engineering Jacquard woven fabric - to attempt to decode the rules used.

During the workshop it was also suggested that a woven quine may be possible - where the pattern somehow contains the instructions for it's own manufacture.

For my contribution to the Mathematickal Arts workshop, I wanted to explore weaving, specifically plain weave. This is the simplest form of weaving, but when combined with sequences of colour it can produce many different types of pattern.

Some of these patterns when combined with muted colours, have in the past been used as a type of camouflage - and are classified into District Checks for use in hunting in Lowland Scotland. This is, I guess, a kind of less prestigious form of Tartan.

I started off by trying to understand how the patterns emerge, beginning with the basic structure:

The threads running top to bottom are the warp, those running across are the weft. If we consider the top most thread as visible, we can figure out the colours of this small section of weave. A few lines of scheme calculate and print the colours of an arbitrarily sized weave, by using lists of warp and weft as input.

; return warp or weft, dependant on the position
(define (stitch x y warp weft)
  (if (eq? (modulo x 2)
           (modulo y 2))
      warp weft))

; prints out a weaving
(define (weave warp weft)
  (for ((x (in-range 0 (length weft))))
       (for ((y (in-range 0 (length warp))))
            (display (stitch x y
                             (list-ref warp y)
                             (list-ref weft x))))
       (newline)))

I've been visualising the weaves with single characters representing colours for ascii previewing, here are some examples:

(weave '(O O O O O O O) '(: : : : : : : : :))
=>
 O : O : O : O
 : O : O : O :
 O : O : O : O
 : O : O : O :
 O : O : O : O
 : O : O : O :
 O : O : O : O
 : O : O : O :
 O : O : O : O

(weave '(O O : : O O : : O O) '(O : : O O : : O O :))
 =>
 : O : : : O : : : O
 O : : : O : : : O :
 O O O : O O O : O O
 O O : O O O : O O O
 : O : : : O : : : O
 O : : : O : : : O :
 O O O : O O O : O O
 O O : O O O : O O O
 : O : : : O : : : O

This looked quite promising as ascii art, but I didn't really know how it would translate into a textile. I also wanted to look into ways of generating new patterns algorithmically, using formal grammars - this was actually one of the simpler parts of the project. The idea is that you begin with an axiom, or starting state, and do a search replace on it repeatedly following one or more simple rules:

Axiom: O
Rule: O -> :O:O

Generation 1: O
Generation 2: :O:O
Generation 3: ::O:O::O:O
Generation 4: :::O:O::O:O:::O:O::O:O

We can then generate quite complex patterns for the warp and the weft from very small instructions, next I'll show what happens when some of these are translated into real woven fabric...

More sketching, this time for use in the game rather than concept design:

Getting stuff to work on PS2 wasn't quite as easy as I probably made it sound in the last homebrew post. The problem with loading code from usb stick is that there is no way to debug anything, no remote debugging, no stdout - not even any way to render text unless you write your own program to do that.

The trick is to use the fact that we are rendering a CRT TV signal and that you can control what gets rendered in the overscan area (think 8bit loading screens). There is a register which directly sets the background colour of the scanline - this macro is all you need:

#define gs_p_bgcolor        0x120000e0    // Set CRTC background color

#define GS_SET_BGCOLOR(r,g,b) \
            *(volatile unsigned long *)gs_p_bgcolor =    \
        (unsigned long)((r) & 0x000000FF) <<  0 | \
        (unsigned long)((g) & 0x000000FF) <<  8 | \
        (unsigned long)((b) & 0x000000FF) << 16

Which you can use to set the background to green for example:

GS_SET_BGCOLOR(0,255,0);

Its a good idea to change this at different points in your program. When you get a crash the border colour it's frozen with will tell you what area it was last in, allowing you to track down errors.

There is also a nice side effect that this provides a visual profile of your code at the same time. Rendering is synced to the vertical blank - when the CRT laser shoots back to the top of the screen a new frame is started and you have a 50th of a second (PAL) to get everything done. In the screenshot below you can see how the frame time breaks down rendering 9 animated primitives - and why it might be a good idea to use some of these other processors:

Some LED bike light tracking using a particle filter:

I've been invited to do a lecture for Markku Nousiainen's experimental course on computational photography next week, so I've been constructing some demos that display different computer vision algorithms based on the work I've been doing on Lirec. The idea is that they may serve as inspiration for how algorithmic understanding of images can be used for artistic purposes.

The code is part of the mysterious magic squares library.

Some schemebricks hacking in preparation for a workshop I'm doing with Alex McLean at Piksel in a few weeks. This is just a case of making it work a little bit more like you'd expect - messing with empty parentheses:

This is my update from Amsterdam on day two of our Naked on Pluto residency. Marloes' report on day 1 is here.

Today was all about taking the themes from yesterday and making them into concrete game mechanics we can use. We started by mapping out possible constraints imposed by multiplayer activities. We want a large amount of what you do on pluto to be coordinated with other players - and this impacts on the logic of the game world. For instance, doors can be locked - sometimes in a room full of people we only want players who are carrying a key to be able to get through the door, at other times a single player might be able to unlock a door for everyone (perhaps for a limited time).

A locking conundrum.

This sort of play requires a way for players to coordinate with each other, for example using a realtime chat system. A minor crisis involving the details of how to handle this feature was narrowly averted and we escaped to the shores of Ljsselmeer to begin considering the vertical slice, the moustache as core game feature, community service and mandatory fanny packs.