Recently I've been looking at Povray, pyprocessing, and cfdg (version 3.0) as tools for creating digital images. I have branched two separate blogs where I mainly explore jruby + processing and processing.py

Saturday, 11 July 2009

Automated Mutating of Context Free Rules

There exists a tool for the automated mutation of your rules file, this can be downloaded from http://www.wickedbean.co.uk/cfdg/index.html.
It consist of a c++ file a Makefile and a python script. The python script is designed to be modified to fit your local setup, however I needed to modify the c++ and Makefile to get it to compile. My compiler is getting a bit fussy (gcc 4.3.2) prefers to be called as g++ when compiling c++, complains about anonymous structs and the comparison of signed and unsigned integers etc. But the main problem was the #includes which needed updating/amending to include:-
#include <ctime>
#include <cmath>
#include <cstdlib>
#include <cstdio>
#include <cstring>

This may be specific to the gnu compiler but I doubt it (by the way you can just name the structs, they are not nested and it does no harm, and it does stop the compiler from complaining, usually a good thing, after all the guys that wrote the compilers are a lot brighter than the average hacker).

Initially I tried it out with the test example of a very simple rule that produces a single black square that slowly evolves to produce a group of squares on a bit of a tilt.
Here is the starting cfdg file sans randomising values (that are necessary for the mutation, but are quoted at beginning of file, so do not affect cfdg operations)

   1:startshape box
2:rule box {
3:SQUARE{ }
4:}


After several generations of intelligent (well I think so) selection this is rule you get:
   1:startshape box
2:rule box {
3:6*{x 0.997317 s 0.996725 }
4:SQUARE{r 0.999948 flip 0.997377 }
5:1*{h 0.998266 }
6:SQUARE{y 0.999894 z 0.996235 flip 0.998095 }
7:}
8:rule R1697921991440238347 {
9:}


The go.py script is set up to display the results as a gwenview slide show (I can confirm that it works equally well with feh) so after viewing the results you just need to remember the index value result you liked, then enter that value as the parent of a new generation of mutated children (a ghastly thought). From simple beginnings complexity will arise. Of course with the random nature of cfdg the saved rule may not generate exactly what you want when you run it again, so saving the image might be a good idea!!!
Seems to fall over if you start off with too complicated a set of rules.
I would recommend something fairly simple but including mix of both and either type rules, see previous post. I got radically different results on each go let alone each generation, it doesn't seem to take much to tip the balance. Sometimes all squares sometimes a mix of squares and circles. Here is one such starting rule I tried earlier:-
   1:startshape random
2:rule random {
3:either{}
4:}
5:rule either{
6:CIRCLE{s 1 x 1 b 1 hue 360 sat 1}
7:}
8:rule either{
9:SQUARE{s 1 x 1 b 1 hue 220 sat 1}
10:}
11:rule either{
12:both{}
13:}
14:rule both{
15:CIRCLE{s 1 x 1 b 1 hue 360 sat 1}
16:SQUARE{s 1 x 1 b 1 hue 220 sat 1}
17:}


Which evolved with a bit of selection pressure to give:-
   1:startshape both
2:rule random {
3:}
4:rule either {
5:SQUARE{x 0.99859 s 1.00378 r 1.00062 b 0.996975 h 219.799 sat 1.0038 flip 1.00382 }
6:TRIANGLE{y 0.998851 s 1.00263 }
7:1*{b 0.999472 skew 0.998291 0.998976 }
8:CIRCLE{s 0.997799 flip 1.00161 }
9:}
10:rule either {
11:both{r 1.00019 b 0.998818 sat 1.00008 }
12:CIRCLE{}
13:SQUARE{y 1.00053 }
14:}
15:rule both {
16:CIRCLE{x 0.998878 s 1.00458 b 1.00698 h 358.756 sat 0.998698 }
17:1*{x 0.99717 z 0.997329 r 1.00341 }
18:SQUARE{x 1.00534 s 1.00349 h 220.191 flip 1.00302 skew 1.00375 1.00032 }
19:either{s 0.998295 }
20:}

Yielding the following image (its a bit of fun really, how did the triangle creep in?).


Here is an image and another rule set that I generated, that perfectly illustrates the importance of saving the image (if you liked it) as the rules produce sufficiently random results that you will be a long time running the rules to produce the horn shape. Gives me the idea to create a script just to re-run the same rule, without 'genetic' modification.



   1:startshape random
2:rule random {
3:1*{flip 1.00015 }
4:both{z 0.998358 s 1.00082 h 359.708 sat 0.996078 flip 0.998614 }
5:either{x 1.00037 s 1.00178 h 1.00006 skew 1 1.00138 }
6:}
7:rule either {
8:CIRCLE{}
9:}
10:rule either {
11:2*{s 1.00195 }
12:translate{y 0.997974 s 1.00127 }
13:}
14:rule both {
15:either{}
16:SQUARE{s 0.9669 r 0.99898 b 0.997186 h 218.95 sat 1.00311 flip 0.998008 skew 1.00472 0.999026 }
17:1*{}
18:TRIANGLE{x 1.00006 sat 0.993161 flip 1.00098 }
19:TRIANGLE{b 1.00181 h 359.502 sat 1.00049 }
20:}
21:rule translate {
22:1*{skew 0.998559 1 }
23:either{x 0.997803 y 1.00134 z 1.0016 s 0.999745 r 45.0287 h 0.998107 sat 0.999604 flip 1.00223 skew 1.00107 0.998019 }
24:SQUARE{}
25:}
26:rule R7964349831326658285 {
27:TRIANGLE{}
28:}


It seem as though there was a bit of debate about what was and was not possible in doing genetic transformations a couple of years ago on the CFDG wiki follow the link to read the debate, PS the creator of this tool was Andrew Borrell as you will read.

No comments:

Post a Comment

Followers

Blog Archive

About Me

My photo
Pembrokeshire, United Kingdom
I have developed JRubyArt and propane new versions of ruby-processing for JRuby-9.1.5.0 and processing-3.2.2