For the default 2D image mode, you will need a fast machine or patience. For the optional animation mode, you will need both.
On starting the application, a grid of images is displayed. (Resize or maximise the application if you like, but the more pixels have to be calculated, the slower it will be.)
Simply repeat the following until bored:
IMPORTANT: Initially you should select images with some sort of variation. If you select a uniform image, you may get stuck in a degenerate zone with little to mutate and therefore little chance of escape to a more interesting area. You can always reset/restart from the "File" menu (the difference is that "reset" also resets the mutation parameters to their default values). Selecting one of the "warp" options from a context menu (right-click on an image) can also help by introducing an additional opportunity for mutation on subsequent spawns.
Note that various spirals, grids and tiles, although complex looking, are actually implemented by a single function node and may leave you stuck too.
NB You cannot simply munge single character options into one big string (i.e "-FM" is not the same as "-F -M") and space IS required between options and numeric arguments (ie use "-t 4" not "-t4")
evolvotron -x FunctionSpiralLinear
evolvotron -X FunctionKaleidoscope Note that you can also specify iterative & fractal function types as an argument to -x/-X, even when they are disabled (as they are by default) in the mutation parameters. Function name recognition is case sensitive.
A left-click on an image in the main window spawns the mutant offspring of that image to all the other (non-locked) displays in the grid.
Right clicking on an image gets you a few more options:
[NB This feature will probably only be of practical use to those with multi-GHz machines].
You can use the middle mouse button to drag-adjust individual images. This is useful for "final composition" type tweaks, e.g centering an image's most interesting feature, or just for satisfying your curiosity about what's off the edge of the image.
It also works on enlarged images, although it's virtually unusable without a bit of practice on smaller, faster ones (just boldly make the adjustment you want, release the button... and wait).
Changes made can be rolled-back on the main Edit-Undo menu item, one drag-action at a time.
An unmodified middle-mouse drag pans the image around following the mouse motion.
A SHIFT-middle drag zooms the image in and out with scaling proportional to the distance from the centre of the image. Beware of generating huge zooms by clicking too near the centre of the image.
An ALT-SHIFT-middle drag is similar but anisotropic: the scaling may be different in X and Y. Warning: this technique is very sensitive and can be quite tricky to use! In particular, if you initially click near the centre axes of the image the zoom factor can be HUGE, so the best way to start using this is to click about halfway on a diagonal between the image centre and a corner and gently move in and out radially. Dragging from one side of the image to the other flips it over (the degenerate case of infinite zoom at the centre is handled cleanly I think). If it all goes horribly wrong, undo and try again.
A CTRL-middle drag rotates the image about its centre.
A CTRL-ALT-middle drag shears the image (the best way to see what this does is to click in the corner of an image and move the mouse horizontally or vertically).
The image display windows created by selecting "Enlarge" from a
context menu also have a couple of keyboard operations:
An area on the status bar shows how many "tasks" are outstanding. Each "task" is the recomputation of an image at some resolution. Tasks are prioritised by their number of pixels (small image implies higher priority). This is why, if the main grid is still recomputing, recalculations of enlargements will appear to freeze after they have reached a certain resolution, at least until other lower resolution tasks have completed.
As of version 0.2.0 evolvotron contains some experimental support for generation of animations (although so far the results have been pretty disappointing IMHO, but it's still early days).
NB THIS IS EVEN MORE COMPUTATIONALLY AND MEMORY INTENSIVE THAN THE CONVENTIONAL STATIC IMAGE MODE.
Simply supply a -f frames command line option and evolvotron will generate animated sequences with the specified number of frames. These will be displayed at the frame rate specified by the optional -r framerate option (default 8). So "evolvotron -f 24" will generate 3 second long animations. Animations reverse direction at each end to avoid a sudden jump.
If you save an animation, multiple files will be saved with .fnnnnnn (where nnnnnn is the zero-filled frame number) inserted in each filename before the filetype qualifier. This is a bit awkward, but is a consequence of Qt lacking support for saving movie format files, so I suggest you use the ImageMagick tools to convert to a more usable format (GIF or MNG) for now.
For example, if you enter foo.ppm as the filename to save,
files foo.f000000.ppm, foo.f000001.ppm... will be saved.
You can convert these to a MNG (a multi-frame PNG) playing at
approx. 8 frames per second with:
convert -delay 12 foo.f??????.ppm foo.mng
(I have had some problems with .mng format; try .gif instead if this is the case).
Evolvotron's idea of an image is a function which converts XYZ co-ordinates to an RGB colour (however we can only display a 2D plane for now so the input Z is fixed to zero, or varied with time when animating).
The image functions are constructed from trees of function nodes. (In the mathematical expression 1+(2*x) the "+" and the "*" would be function nodes.) Evolvotron's functions tend to correspond to geometric or colour-space operations or anything else which can be applied to a 3D vector.
By mutating the structure of the function tree (adding random branches, for example) and the values of the constant embedded within it, the image can be changed.
The mutation parameters are under control from the dialog accessible via the Edit-Mutation Parameters... menu, and also from buttons on the status bar).
There are two kinds of mutation: perturbations to the magnitude of constants,
and structural mutations which rearrage the function tree of an image.
Four types of structural mutations are currently implemented:
The probability (per function node) of these mutations is controlled from spinboxes on the dialog (expressed as chances-in-a-million), as is the size of perturbations to constants.
It is useful to think of the constant perturbations as being a thermal effect (hence the "heat" and "cool" buttons), while structural alterations are more drastic and are caused by high energy gamma rays or something (hence "irradiate" and "shield" buttons to adjust the probability of structual mutations).
So why would you want to change the mutation parameters from the initial defaults ? Basically, if you're getting too much variation in spawned images (this tends to happen after many generations of images, by which time the function trees have grown quite large and therefore are experiencing a lot of mutations) then cool and/or shield. If all the images look too similar, heat and/or irradiate.
2 types of function node are considered fundamental: constant nodes
(which return a constant) and position nodes (which should really be
called identity nodes) which return their position argument. There
are two slider controls to affect things realted to these:
On the mutation parameters dialog there are tick boxes to enable two classes of function which are disabled by default. These are "iterative" functions and "fractal" functions (Mandelbrot and Julia set type things). The main reason for their being optional is that, in the former case they're expensive, and in the latter case they're expensive and ugly. Note that if fractal functions are enabled, then iterative functions are enabled too.
This release also builds two other executables:
evolvotron_render [-v] [-s width height] [-f frames] [file.ppm | file.png] < file.xml
Reads a XML function description from it's standard input and renders it to the
file specified (suffix determines type, defaults to ppm if not recognised) at the
specified resolution. Image size is specified by -s option and defaults to 512x512.
The -f option generates multi-frame animations. .fnnnnnn is inserted/appended to
the specified filename in the same way as animations saved from evolvotron.
(You can use this on functions which weren't evolved in animation mode, but there's
no guarantee they have any interesting time/z variation).
Use the -v option to monitor the progress of a long animation run.
[NB This app does not use multiple compute threads].
evolvotron_mutate [-g | < file_in.xml] > file_out.xml
With the -g (generate, genesis?) option, creates a new random
evolvotron function and writes its XML description to standard out.
Without the -g option, reads an XML function description from
standard input, mutates it (using the same algorithm and parameters
as evolvotron in its default state) and writes the new function's XML
representation to the standard output.
Evolving and mutating on the command line:
evolvotron_mutate -g | tee fn.xml | evolvotron_render /tmp/xxx.ppm ; display /tmp/xxx.ppm
cat fn.xml | evolvotron_mutate | evolvotron_render /tmp/xxx.ppm ; display /tmp/xxx.ppm
Animating a function ani.xml saved from evolvotron in animation mode:
cat ani.xml | evolvotron_render -f 100 -v -s 256 256 ani.ppm ; animate ani.f??????.ppm
Check the TODO file first before you send me suggestions!
Please don't ask me to port evolvotron to proprietary platforms. You are of course Free under the terms of the GPL to do so yourself, but please read http://www.fefe.de/nowindows/ first.
To those who have contributed feedback, suggestions and patches:
To the participants in a SIGGRAPH conference panel many years ago who first got me interested in this kind of thing.
To www.di.fm, www.somafm.com and Trance4Ever for music to code to.
I have always admired those who have the skill to wield a pen or paintbrush and fill a sheet of paper or a canvas with some striking image from their imagination. Unfortunately I lack the patience to learn such skills, and probably the necessary manual dexterity and imagination too. Evolvotron, and several predecessors developed on and off over a decade since I first came across the idea, are an attempt to compensate for this using the skills I do have i.e some mathematical sensibility and the ability to write working code (well, sometimes). If you like an image it produces, then as far as I'm concerned that's as satisfying a result as if you liked something I'd drawn myself.
Tim