Installing Fr0st

September 13, 2009

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

June 19, 2009

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.

grj

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.

grj no xaos

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

April 15, 2009

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

March 29, 2009

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

February 13, 2009

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

December 21, 2008

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.

crossroads

void

rose

movement

julia

heart

glass

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.

one
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 😉


Getting Closer

December 9, 2008

The next fr0st release is on its way. It took much longer than expected and has a lot of things missing, but it’s still a huge improvement over the 0.3 version, and I’m overdue for a new release. I can see something resembling an actual program starting to take shape, so that gives me some hope.

-Support for all variations included in flam3, through Pyflam3.
-The scripting mechanism was overhauled significantly, and now counts with a clean and easy to use implementation of flame objects in python.
I’ll put up an announcement here and on the apo mailing list once the release is out of the door, some minor things still need to be taken care of.