Fractal flame processing is split into three main sections: Iteration, density filtering and final color correction.
The first section is where the bulk of the time is spent. The second is very quick, but can take longer with large supersample values. Since the third is nearly instantaneous, this section will only focus on the first two.
After all processing is done, saving the image to disk is spawned in another thread. This allows subsequent images to begin processing without having to wait for the saving of the previous image to complete.
When benchmarking your system’s performance, it’s important to use either the Final Render dialog, or the command line tools to get an accurate measurement. The performance numbers from the interactive editor in Fractorium will be much worse than what your system is capable of. The reason is that after each iteration sub batch is complete, it processes any UI messages that have been queued up.
When rendering on the command line, the
--progress option will slow down performance by about 10% due to the time spent continuously updating the console text. Omit this option when benchmarking or when speed is absolutely critical.
The time spent iterating can vary greatly between flames, so it’s important to know which parameters have the greatest impact on performance. They are listed here in order from greatest to least impact.
Quality is expressed as the number of iterations per pixel to perform. For example, running a quality of 10 on an image with dimensions 1000×1000 would give 1M * 10 = 10M iterations. The higher the quality, the longer rendering will take.
Adjusting the zoom value zooms the image in, but also increases the quality to compensate. This allows for zooming without losing quality, which is what happens when using the scale value. The exact adjustment zoom makes to the quality is:
quality * SQR(pow(2, zoom))
So for a quality of 10, and a zoom of 3, the new quality becomes:
10 * SQR(8) = 640
As you can see, the number of iterations would be greatly increased, so use zoom sparingly if performance is a concern. One alternative is to use scale, and then adjust the quality manually until final image looks satisfactory.
Observe the status bar in Fractorium to see what the zoom scaled quality value is.
Different variations vary greatly in how much computation they do. Some are very simple, while others involve heavy loops.
The number of variations contained within each xform impacts performance. This is because when an xform is chosen for an iteration, every variation within it has to be applied. Having many variations in a single xform usually offers no improvement, as many of the best looking flames have one or two per xform.
The number of non-final xforms makes no difference in performance, since only one is selected per iteration, and the selection process is nearly instantaneous. However, having a final xform does slow down performance because it is applied on every iteration after the randomly chosen xform is applied. This means that two xforms are applied on each iteration.
Supersampling renders the image on a larger surface, then scales it back down. This is useful for getting smoother lines. While using a supersample value greater than one does not perform any additional operations, it increases the amount of memory used. This means that plotting the point for each iteration is less likely to hit a location in the cache, which leads to a slowdown in performance. For a final render, a value of two is suggested. Values of three or four offer noticeable visual improvement only in rare cases.
GUI vs. Command line
Rendering in the interactive window of Fractorium is much slower than using the final render dialog or the command line. This is because the render loop has to continually pause to update the GUI, then switch back to rendering where it left off. The interactive window is only meant for editing until you are satisfied with the general look. For high quality final renders, always use the final render dialog or the command line.
When iterating a sub-batch begins, a number of iterations are done, but the resulting points are not plotted. This allows the point trajectory to converge a bit before plotting begins. The number of such discarded iterations is the fuse count. Historically, values such as 15, 20 or 100 have been used. The default is 15, but Fractorium allows it to be configurable. A higher number will have an impact on performance, but in practice it’s mostly negligible. It also rarely has any noticeable effect on the output image and is kept as an option only for extreme cases where convergence is a problem.
The 3D parameters are: Z Pos, Perspective, Pitch, Yaw and Depth Blur. Setting any of these to a non-zero value will cause an extra step of 2D->3D projection calculations to be done on every iteration.
Affine transforms are applied before and optionally after the variations in each xform when those affines are not equal to the identity matrix. These calculations are very quick since they only involve a few multiplications and additions. However, if you set the affines to the identity matrix for a given xform by clicking
Reset on the Affine tab, they will be skipped over when that xform is applied. This will give a slight performance improvement.
Xaos adds an extra small computation to each iteration step. It also makes the xform selection buffer scale by the number of xforms, which is less cache-friendly. In practice, the performance penalty is only a couple of percentage points.
Palette indexing mode
This specifies how the color is retrieved when plotting a point. The input number to retrieve the color from the palette is a decimal value. Step mode just uses the integer portion of this value, while linear does a linear interpolation between the value and its neighbors. The latter obviously requires slightly more calculations, however in practice it has a negligible effect on iteration performance.
This usually finishes quickly, however it can slow down when supersample values greater than one are used. Two will give a slight slowdown, but three and four will dramatically slow down the process. Sometimes during interactive rendering at low quality values, density filtering with a supersample of three or four can take longer than the iteration phase. Like stated above, use large supersample values only when necessary.
The maximum size of the filter is set by the
Max DE Width value. A good number to use is nine, however you can disable it completely by setting it to zero.
The minimum size of the filter is set to zero by default. It can be increased to achieve more of a blurring effect, but this is seldom necessary. If done, be aware that it will slightly slow down the performance of this step.