dextro - coding/animation

on non-linear processes and non-objective
visuals

all algorithmic works on dextro.org are based on non-linear mathematic scripts, meaning that the variables used are attributed a fixed numerical value only at the beginning, and as the calculations proceed the results of one iteration become the starting values of the next. like in nature, these processes refer to themselves: their current state is based upon their past, and movements resulting from them are dynamic. (it is not possible to predict where an object will be after a certain number of iterations, you can only find out by running the script.) unlike in nature, these non-linear processes are entirely repeatable: since the script is only calculated to the 4th decimal place (and even if it was to the 1000th decimal place) it will behave in exactly the same way whenever it is restarted, whereas any process involving real atoms does not. (whether this is merely due to a lack of information is still subject to debate among physicists.) one similarity between the two, however, is: when three or more equations are interlinked with each other their results start to show unexpected and counter-intuitive properties. artifacts appear, and disturbances, and the more equations are used, and (even more important) the more they are interlinked, the more so. it is such ripples of the uniform that i try to amplify them, and show them on dextro.org as animations, videos and images. (by the way, “non-linear” is not the same as “fractal” or “chaotic”: while all these animations are non-linear, only some are chaotic (meaning that consistency is enabled by constant feedback and repeated corrections instead of fixed paths) and none are fractal (meaning that their shapes and paths are similar to themselves at different sizes).)

the algorithmic works on dextro.org can be divided into particle animations and self-generating images. while their scripts can be similar or even identical, the difference lies in the fact that in the latter the objects leave a print of themselves wherever they are moved by the script and by doing so paint an image. (in macromedia director, the software i use for programming all these works, this function is called “trails”.)
usually all objects in such an animation, be it a particle animation of a self-generating image, obey the same rules, and only their position leads to their different paths. like in a flock of birds or a school of fish individual behaviour only results from applying identical rules to different situations.

floating in time:

while a film or video (and in most cases a flash animation, too) is based on a timeline, the kind of animations i make has only two frames: in one the variables are defined and attributed a value, and in a second one the calculations are performed. frame one will be passed only once when the animation is started, and after that frame two will be passed repeatedly, in a loop. this way numeric values change constantly, and it is possible to influence them at any time, for example through combining them with the x- and y-coordinates of the cursor (which we call “interaction” then). whenever a script is too complex to be run in real-time on the viewers pc, i pre-render it and publish it as video. in this case there cannot be any interaction, and linearly (or circularly) changing numeric values are used instead. typically, such videos show different movements than the corresponding animations, since the images (the frames of the video) they consist of, are not building up but are already finished, and only the different parameters in the script lead to movement.

programming such animations is not so much a target-oriented process as one might expect. of course there has to be a clear idea at the beginning, but then, in the process of programming it, other aspects become more interesting. my attention then shifts from translating real-world observations into code to experimenting with the code itself. this is not so much my choice as it is a necessity, since all numbers have to be kept within certain boundaries: first, i want the objects to stay within the format of the animation, but i also want the interesting aspects of it to be in a certain size, and not become too small or too big to even see them. since the numerical window, that i have to find for each variable, can be very small, and since all variables affect one another, programming an animation like this is very time-consuming: i have to watch it run for a long time to make sure it behaves as i want it to. my intention when creating interactive animations has always been to enable the viewer to take part in the process, so every script has to offer a certain amount of variety, that can be triggered by interacting with it. it should be predictable, but not too much. the challenge is to enable diversity while avoiding randomness.

in my opinion these scripts can only partially be created intentionally, partially they can only be found, discovered. when finished, they are very short (yet interlaced), shorter than we might expect judging from the intricacy of the shapes and movements they produce. they are surely shorter than they would be if programmed in an aim-oriented manner (if it is at all possible, which i doubt).

one way to understand how these scripts work is to imagine magnetic fields: invisible points apply attraction or repulsion to the visible ones, according to their distance or angle. when such images slowly build up by repeatedly moving thousands of objects (usually just one pixel in size, and with 2% transparency) from their random starting positions, it is like scattering magnetic dust onto a set of magnets: the dust will settle down on certain areas, and avoid others. indeed images like the ones from the “k456”-series are visualizations of force fields, the difference to magnetic fields being their ability to interfere with one another in more complex ways (usually defined by trigonomic functions), which is why the resulting images don’t resemble photos of iron powder in magnetic fields. yet their forming principles are the same...

it is my aim to keep the animations and videos relatively simple, so that viewers can, to some extent, still understand their underlying principles, and be it only through their subconscious. this way not only aesthetic preferences can be shown and shared, but an understanding of mechanisms can be conveyed, mechanisms that can be found in nature and in our mind. while a single image can only show one possible application of its forming principles, an interactive animation can, through the variety it offers, show these principles much more directly. for that, an intuitive approach has to be enabled. i try to ensure it by avoiding addressing the rational mind of the viewer, which is why i don’t offer any concepts and explanations of the works on my site, nor information about my person.

translations:

the scripts used in the animations on dextro.org can easily be translated into words and diagrams (which could one day result in a (hardware) video synthesizer). this diagram visualizes the script of the “k456”-series. (the icons in it are fictional and don’t comply with technical standards.)

selecting from overabundance:

working with algorithms is, in my eyes, a good way to overcome creative limits. every script defines a frame for possible behaviours set up during the process of programming and observing it. once it is finished it yields an abundance of more or less different images, from which i can then choose. visual solutions that i would otherwise not even think of are now presented to me and i can choose from them. most of these images i will never use, but making these decisions is something completely different than not thinking of them at all (comparable to carving a figure out of stone, as opposed to modeling it with clay): i intentionally discard them, i knowingly exclude everything that doesn’t match my way of expression, thereby making it more precise.

dextro.org exists since 1994 and shows non-objective graphic design experiments, algorithmic animations, videos, photos and paintings. turux.org, a project i started in 1997, was entirely dedicated to interactive animations. most of it is integrated into dextro.org now.