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.