Fractal Fr0st 1.4 released

I’m glad to announce that the latest version of Fr0st has just been released!

Get Fractal Fr0st 1.4

A lot of work happened behind the scenes in this release. Stuff got cleaned out and fixed. For the next version, I’ll be focused on adding more features and improving the existing GUI elements. Anyway, here’s the changelog, listing some of the bigger items:

GUI:
-Variation preview now has layers of different depths, to better show off what each xform is actually doing.
-Highlight triangle corners when hovering over them with mouse.
-Small preview now uses multiple threads on systems with more than 2 cores.

Bugfixes:
-Allow unicode paths for favorite scripts.
-Fixed several bugs that occurred when manipulating flames with non-black backgrounds.
-Small alpha values in palette produced by smooth interpolation (due to rounding errors) are now ignored.
-Fixed bug where some error messages were being cut short.
-Fixed bug where starting a script while the canvas was being manipulated led to an inconsistent program state.

Fractal Fr0st 1.3 released

I’m happy to announce that the latest version of Fractal Fr0st is ready for download!

Get Fractal Fr0st 1.3

New in this version:

GUI:
-Added gradient browser, which is able to load .ugr, .map, .xml and .flame files.
-Preview renders are now cached, so the same images aren’t rendered over and over again.
-Added anim tab, where flame time and related attributes can be set. Also added a script to create interpolated animation sequences using those attributes.
-Increased size of small preview to better fill the available space.

Bugfixes:
-Fixed a bug that made it impossible to change some of the configuration settings.
-Added space requirement of output image to memory calculation in render dialog.
-Installer now displays the correct version.
-Various small fixes.

As usual, I appreciate all feedback, bug reports, constructive criticism, and link love.

New release on its way

I’m preparing the 1.3 release of Fr0st in what little free time I have these days, so it should be out shortly. I haven’t been able to look at the several flam4 related bugs that were reported recently, for lack of a CUDA capable graphics card (stuck with just a low-budget laptop right now). Before the end of the year I will be getting a new box, though, so you can count on all of that being sorted out by the subsequent release (currently scheduled for early 2011).

In the meantime, I hope you’ll enjoy the new features coming out, such as smart image caching, which makes the process of designing fractals a lot faster, specially when going back and forth between different versions of a flame. There’s also animation support coming, by wrapping the flam3 calls in an easy to use script.

Fractal Fr0st 1.2 released

After a long time of waiting, I’m proud to announce the release of fractal fr0st 1.2! Over the last 6 months, I got cut open to have my appendix extracted, moved to another continent and studied like mad to get admitted to university. In that tumult, Fr0st got relegated to the back burner, even though I really wanted it to be otherwise. But the wait is over, and I’ve resumed active development again, so expect to see another release in only 2-3 months time!

Get Fractal Fr0st 1.2

So what’s new in this version?

GUI:
-Triangles on canvas are now translucent.
-Disable GUI interaction while a script is running.
-Added list of recent flames and scripts to respective menus.
-Added list of favorite scripts with hotkeys for quick execution.

Installation:
-Added script for Ubuntu that automatically installs all dependencies.

Bugfixes:
-Avoid crash when rendering on 64-bit Unix systems.
-Rotate buttons in xform tab now take into account world pivot.
-Xform tab now updates correctly when selecting post transforms.
-Recovery after a crash now brings Fr0st back to its exact previous state, including full undo/redo history.
-Script input dialog now checks for invalid input and raises an error.
-Render dialog no longer displays flame names in status bar when rendering, as this could lead to overlapping text on some systems.
-Many, many more…

As usual, I appreciate all feedback, bug reports, constructive criticism, and link love.

1K downloads

Fr0st passed 1000 downloads today! I know it’s just a number, but I can’t help feeling a bit excited about it, a bit proud. Thanks for trying out Fr0st and thanks for sticking with it, even if it still has some bugs. In a month or so I’ll be picking up development more actively again — the 1.2 release is bound to follow soon after.

Rendering Large Flames

Ok, so I’ve written a pair of scripts to allow rendering a fractal in strips. This is useful since it allows rendering images that would otherwise be too large to fit into memory. If you render in 3 strips, for example, you’ll require only 1/3 as much memory, but on the flip-side the render will also take 3 times as long.*

It works pretty well: Just run slice_flame.py on a flame, render all flames in the resulting file, then run join_strips.py and point it at one of the rendered strips. The script will find the other strips and combine them all into a single image.

Download the scripts here: slice_rendering.zip

The only issue this approach has it that the resulting image shows visible seams if DE is turned on and the render quality is very low. This happens because the seed used for the random number generator is a different one for each strip. The problem goes away when rendering with high enough quality (let’s say 500 or higher).

One additional note: Don’t use the jpg format when employing this script! Since the image is saved twice (once when rendering the strips, second time when loading and combining them), you’d lose quality due to jpg compression twice as well.

As usual, if you have any issues or find a bug, please let me know so I can fix it!

* Actually, the total render would take the same time, but the quality would only be 1/3. You need to render the strips at 3x the quality to get the same result as rendering in a single slice (because quality is calculated in relation to render size)

Fr0st 1.2 delayed

I had surgery a little over a week ago. Nothing too big, just a case of appendicitis that was a bit more complicated than usual. This threw my schedule completely out of order.

Fractal Fr0st 1.2 won’t happen anytime before September. I had meant to do a release before the first half of the year was over, but now it looks like I’m missing my window. In less than a month I’ll be moving to another country, and things will just be crazy for a couple o months after that. I’ll hardly have time to hack on fr0st during this time.

I’m really excited about many of the new features that are already done and in the pipeline for the next release, such as translucent triangles in the editor and favorite scripts. But all of that will just have to wait (such is the life of an open-source project). When the release does come, it will be as awesome as usual. Thanks for sticking with fr0st.

Installing Fr0st in Ubuntu

I finally got an install script for linux users written and tested. It will install all dependencies of fr0st, including downloading and compiling flam3. So far it has only be tested under Ubuntu 10.04, so I’d appreciate any feedback from people installing fr0st on other releases/distros.

The file will start to be distributed with the 1.2 version of fr0st. For now, you can get it directly from here:

fr0st-install-dependencies

This can be used to run code from the 1.1 release (http://launchpad.net/fr0st/trunk/1.1.0/+download/fr0st-1.1-src.tgz) as well as the development version from the bazaar repo (“bzr branch lp:fr0st fr0st”)

If you run into any problem using this file, please let me know so I can make corrections. Thanks!

Fractal Fr0st 1.1 Released

Fr0st 1.1 has been released! Get the dowload files here:

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

There are lots of changes and improvements in this version:

GUI
-Added vibrancy to adjust panel
-Xform editor now handles post and final xforms much more intuitively.
-Hide irrelevant tabs when post or final xform is selected
-Preview and render dialogs now show rendering info in their title bars.
-Opening files is now faster.
-Eliminated several sources of slowdown when handling very large files.
-Don’t render thumbnails when opening large files.
-Quality of jpg renders can now be configured. Default is 95.
-Can now paste multiple flames at once.
-If a script causes an error, a helpful dialog with all details is shown.
-If fr0st crashes or the computer loses power, unsaved changes are recovered next time it is opened.

Flam3 integration:
-Rendering now 5-10% faster due to better integration with the GUI.
-Default buffer size is now 64-bit, making for another 10% speed improvement. Also improves performance of thumbnail and preview images.
-Images with non-black backgrounds now render correctly on windows.

Flam4 integration:
-Can now render transparent backgrounds.
-Fixed bug where black image was returned when changing certain parameters.

Installation:
-No longer have to compile extension module when installing on linux.

Various bugfixes:
-Fixed possible error when editing flame names.
-Fixed possible error when dragging flames around.
-Check for invalid paths (i.e. malformed or pointing to a read-only dir), and handle them correctly.
-Many, many more.

If you need help or have any questions, you can stop by the mailing list:

http://groups.google.com/group/fr0st

or go to the #fr0st-users irc channel at freenode.net.

Feedback and bug reports are very much appreciated.

Why you should prefer 64-bit buffers

In the next release of fr0st, it will use 64-bit buffers when rendering previews and thumbnails. This has increased rendering speed by about 10%.

Where does this speedup come from? It’s pretty simple: All math for the iterations is done in 64-bit no matter what. Therefore, when using a 32-bit buffer, flam3 has to cast from double to float and check for overflow at each iteration. In layman’s terms, you always calculate the fractal very precisely, but if you use a smaller buffer, you need to ’round’ the numbers to fit them into the available space, which makes the rendering process slower and less accurate.

There are some boundary conditions in which the compounded rounding error caused by using the smaller buffer creates a slight shift in color when changing opacity. This can be very visible when creating animations.

The downside is of course double memory usage. But I still recommend to use a 64-bit buffer for rendering whenever possible. It’s worth sacrificing a bit of oversample to do so (as long as you never reduce it below 2!). If you’re rendering huge images where memory is at a premium, you might be forced to reduce the buffer to 32-bit, but I would only do that if the alternative was rendering in slices.