Understanding the *.flam4 format: Part 1: Introduction

When I first envisioned creating a new *.flam4 format to describe the parameters of a particular flame or set of flames, I was pondering how to go about adding support for custom variations in the flame code, so that the user could enter their own fractal equations instead of relying on an increasingly long (and thus hard to maintain) list of predefined variations.  Apophysis had already taken this path, but the problem here was that adding a new variation required writing a plugin, which is basically a .dll containing the function call wrapping the little piece of code that the user wanted to try out.  The downsides of this approach are obvious.  First, the amount of work involved in writing and compiling a plugin was absurd given the scope of a variation, which may be a simple as taking a point (x,y) and returning (sin(x),sin(y)).  A second, more nefarious problem was that in order for any one else to render a flame that uses a given nonstandard variation, the user must first track down and obtain the plugin for that variation, which, owing to the nature of the internet, may indeed be lost, perhaps forever.

Another goal was to replace the chaos tag with something more sensable, but hopefully more powerful.  As it proved, doing this allowed boiling down several special cases in flam3 to use a single general case in flam4, namely post transformations, final xforms, symmetry kind, and pre/post variations, as well as expanding above and beyond.

Finally, I wanted to provide a cleaner format than the flam3 format, which, to put it bluntly, is a textbook example of how not to use XML.

Other topics also came up, even if they haven't (yet!) all been implemented into the *.flam4 format.  These include more control over animations, post processing procedures, and true 3D support.

With this in mind, the next series of posts will detail the anatomy of the *.flam4 format, and how you can (ab)use it to generate images not otherwise possible.