Using Fr0st with Electric Sheep

Right now, it’s not easy to use fr0st for generating sheep that are accepted by the electric sheep. Fr0st is built on flam3 2.8 (the latest version), while electric sheep is still on 2.7. This means there are incompatibilities in the file format, invalid variations, etc.

I’ve been working on a script that addresses this problem. It’s still a beta version, so please don’t trust its output blindly, and let me know of any problems. You can get the script here:

http://dl.dropbox.com/u/2173295/fr0st/electricsheep_export.py

This script will take the currently selected flame, attempt to convert it, and save it to a separate file.

New Beta Released!

You know what to do. Get it here:

https://launchpad.net/fr0st/+download

Fr0st tips & tricks

I’ve aimed to make the fr0st interface as discoverable as possible. There are a couple of features hidden away, however, so I figured it’s important to write them down before they get lost in the sands of time, to be dug up by some lucky soul excavating through the source code.

Mouse Wheel + Ctrl and/or Alt

This sounds harder than it is, so let me explain:

Hold down ctrl while the mouse is on top of any textbox, and you can change its value by scrolling with the mouse wheel. Instead of ctrl, you can also hold ctrl+alt or just alt to get slower scaling. This works on top of virtually any textbox, including variations, chaos, color, weight, etc.

Preview Image

The above method also works on top of the preview image, where it changes the scale of the fractal. You should also try dragging the preview around with the mouse.

Double-Clicking Variations

Double clicking on the variation name will make the variation jump to 1 if it was at 0, and to 0 otherwise. This should be pretty familiar to those coming from Apophysis.

Keyboard Shortcuts

All keyboard shortcuts can be discovered just by looking at the menu items. Here are some of my favorites:

-F8 runs a script; F9 interrupts it
-Ctrl-z undoes the last change, while ctrl-shift-z undoes all changes. Same with y for redo.
-Ctrl-p opens the preview, ctrl-r the renderer and ctrl-e the script editor.

Copy & Paste

with ctrl-c and ctrl-v you can copy and paste fractals to and from fr0st into other programs such as text editors and other fractal programs.

Does any of this help you make better fractals? Of course not, but it does free up your mind to focus on the creation of art instead of struggling with the program. A good interface is one that fades into the background, turning almost invisible. I’m not sure we have achieved that quite yet, but we’re heading there.

Have fun with these tricks!

First beta released

The last few months have involved lots of coding, and very little writing about it. In that time, I took fr0st from an idea in my head to a fully fledged, cross-platform app. I didn’t do it alone of course. The project wouldn’t be where it is today without the help of several contributors who have really made a huge impact.

I’m really proud of fr0st and how it’s turned out. Code speaks louder than words of course, so I’ll just let the former do the talking.

https://launchpad.net/fr0st/+download

Installing Fr0st

Update 05-22-2010: These instructions are out of date. Releases are now available from launchpad. If you’re on a Linux distro, you should check out the updated Linux instructions.

—

Fr0st is still under heavy development, but it’s starting to look more and more like a usable program. To try it out, you’ll need to get a copy of the latest version first, which can be downloaded here:

http://fractalfrost.svn.sourceforge.net/viewvc/fractalfrost/trunk/

(click on the “Download GNU tarball” link at the bottom)

Windows

For the final 1.0 release, we’ll provide binary files. However, since fr0st is still in beta and changes day to day, you’ll have to run the source version for now.

You’ll need the following installed:

-python2.6.x: http://python.org/download
-wxpython: http://www.wxpython.org/download.php#binaries
-numpy: http://sourceforge.net/projects/numpy/files

Just run fr0st.py and you’ll be good to go.

Linux

These instructions have been tested in Ubuntu 9.04 only. You’ll need the following:

-python2.6.x (comes preinstalled)
-wxpython: sudo apt-get install wx-gtk2.8
-numpy: sudo apt-get install python-numpy

To install flam3 as a shared library, do the following:

-Add this software source:
deb http://ftp.de.debian.org/debian etch main

-Get the following through your package manager:
zlib1g-dev
libpng12-dev
libxml2-dev
libjpeg62-dev

-Get the source tree (http://flam3.svn.sourceforge.net/viewvc/flam3/branches/early-clip/src)
You can also get it via SVN: svn co https://flam3.svn.sourceforge.net/svnroot/flam3/branches/early-clip/src flam3-2.8

-In the folder you downloaded it to, type the following commands:
./configure –enable-shared
make clean
make
sudo make install

Just run ./fr0st.py and you’ll be good to go.

Mac

I don’t have a mac, so I’d appreciate if anyone could let me know the specific steps required. It shouldn’t be hard to figure out based on the windows and linux instructions found on this page.

Xaos is like inverted sculpting

You start with a base fractal that is a messy sea of intricate details. You start stripping away elements to create a bit of breathing room. Gradually, you refine the composition and reduce it to its core elements. By the end of this process, you will have revealed the beauty that was there from the beginning.

I started off with just a few transforms, like 3 or 4, and went through all xaos links to see which ones needed to be removed. Then I added an extra transform to create more detail where it was lacking, went over the additional xaos links created, and repeated the process as many times as was needed.

The final image consists of 6 transforms, for a total of 6*6 = 36 xaos links, of which only one is set between 0.0 and 1.0, one is above 1.0, and no less than 13 are set to 0. At least half of the time it took me to make the image was spent tweaking these links and other minor details such as variation weights.

In the end, this kind of effort is totally worth it. A good flame can take less than 10 minutes to make, but a truly great one (which I don’t claim this one to be!) will inevitably take hours of work, spread out over several sessions. That’s how it works for me at least – you’ll have to judge the result for yourself.

This is how the fractal would look like if xaos was disabled. Of course, it never actually looked like this at any point during its making, as the transforms were built up gradually. I’m including it here just to show the huge difference xaos makes in the whole process of creating fractal flames.

Xaos and the Generalization of the Fractal Flame Algorithm

Why do post transforms, linked transforms and final transforms even exist? They are a way to give more flexibility to the original idea of the fractal flame algorithm, which only contemplated a series of functions (transforms), connected strictly in parallel. That’s the whole point of an IFS.

Post transforms are a way to make this interaction more complex, allowing additional modification to a given function after the variations have already been applied. But looking at it in general terms, a post transform is a full fledged transform, which just happens to represent the identity function in terms of variations (meaning that it is the equivalent of linear=1).

That’s why linked transforms can be considered post transforms on steroids: they can also implement regular post xforms, but are free of any artificial limitations, making them an order of magnitude more powerful, but also much harder to use within a program that was designed without them in mind.

Imagine you’re happily fractalling in Apo, taking advantage of these enhanced post xforms, and then all of a sudden you realize that your entire construct of xaos paths has collapsed on itself because you dared to, um, add a transform (gasp!), so now all your linked xforms will happily assign a xaos value of 1 to this newcomer, because they don’t actually understand the abstraction they’re implementing for you.

In programming, this is known as a leaky abstraction; the program pretends to take care of some annoying low level stuff for you, but in practice you still need to understand exactly what’s going or or you will get randomly screwed up.

Aren’t computers supposed to flip bits for you, and not the other way around?

What if you had a different way of fiddling with the xaos paths of your flames? You could lay out and connect your transforms to each other in a completely freeform way. Instead of painfully working around the limits built into the flame algorithm or being forced to use the mess that is xaos in this regard, you could lay out the structure of your flame according to a graph, in which each transform is a node, joined to and from any other with connections of varying thickness (the xaos value), thus creating arbitrarily complex structures, with multiple post and final xforms, and structures of multiple xforms that can take the place of one.

These structures would then be translated down to a simple, xaotic representation (bad pun, I know), to be rendered by any fractal flame implementation that supports xaos. Currently, this is only Apophysis, but flam3, on which my app is based, is following suit with its 2.8 version (still under development).

This is the kind of thing for which I decided to change course and implement a standard flame editor before indulging in strange experiments that push the limit of current fractal programs. You need a solid base before being at liberty to go crazy with new ideas.

Open Formats, Open Development

It’s a specific goal of mine to make fr0st as open and accessible as possible. For instance, I want to make it easy for scriptwriters to build things that experiment and explore in new directions, and to incorporate the evolutionary result of this activity back into the core program, rather than leaving them trapped in the script editor forever, treated as second rate citizens.

With this kind of goal, it’s important that the file format of the flames themselves remains open and accessible to be extended by anyone. This is done by remaining as agnostic as possible about the meaning of each particular element in the parameter set. it’s up to the underlying renderer (flam3) to decide what to do with each of them, so if a particular script wants to incorporate additional data into the flame files, it can easily do so.

I’ve always believed that data should be kept packed together as closely as possible. I can’t stand the thought of storing a piece of data that needs specific information outside it to be interpreted properly.

Let’s look at some examples:

If you were to make an animated sequence of flames with a script such as apophymator in apophysis (both of which are good pieces of code, don’t get me wrong), you have no way to store information about keyframe lenght in the frames themselves. This is not a big problem when the intervals are regularly spaced, but can soon become burdensome if you’re trying to create something more elaborate. Why not store this data in the flame file, through a special attribute that can be safely ignored by any code that doesn’t know what it means.

Take the case of post-processed flames. It’s a headache that you can’t keep just the flame file, but also need the finished image and an exact sequence of steps that were applied during post processing. Otherwise, you can’t reliably produce the same output from the bare parameter file. What if there was a script that programmatically invoked image processing routines from a graphical library after your flame has finisehd rendering, based on data you can specify within the parameters? I’m not about to implement such functionality, but the door for this kind of thing is open.

You can also store info such as what renderer a particular flame was designed for, what script version produced it, etc. In a world where different fractal flame implementations are drifting apart and introducing small incompatibilities in how they handle coloring, xaos, etc, this kind of thing might unfortunately be needed. In the end, a format where the most useful and popular features win, represents the true spirit of open source much better than any closed, top-down desing I (or anyone else for that matter) could come up with.

These ideas are larger than any individual people working on them. Keeping fractal programs open (truly open, not just GPL’ed), is in the interest of us all.

New design goals for fr0st

Recently the direction in which I am developing fr0st has begun to change. At first it was an experimental way of rendering flames in realtime (and I consider it a moderate success in this regard), but it doesn’t make much sense to continue in this direction with the impressive development of GPU rendering we’ve seen lately.

My new vision of the project is to build a flexible GUI that combines the high usability of Apophysis with the portability and interoperability of flam3.

Once a basic skeleton with a reasonable set of features is up and running, I can start adding some really cool stuff, including built in support for rendering animations and a flam4 backend (with the ability to toggle between flam3 and flam4 rendering).

This will be quite an interesting challenge. We’ll have to see what it leads to.

The Power of Simplicity

It’s way too easy to lose oneself in complexity, and forget that even the most simple things can be full of beauty, specially if we’re talking about fractals.
These fractal images have only 2 transforms, each with a single variation set at 1. And yet, despite being concentrated and distilled down to a mere 9 dimensions out of the hundreds available in fractal space, they still carry a huge amount of expressive power, displaying intricate patterns emerging from the simplest forms.

If you thought that was the absolute lower limit at which an aesthetically pleasing image can be achieved, think again. Single transform flames, unable to ever escape monochromatic space, are still able to produce some pretty impressive effects, although they’re dangerously close to the absolute lower limit.

Beauty is in the eye of the beholder of course, but for me at least, the technical challenge of these constraints alone has made the achievement worthwhile 😉