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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: