Extended Options Screen Finite attractors: Many of Xmfract's fractals involve the iteration of functions of complex numbers until some "bailout" value is exceeded, then coloring the associated pixel according to the number of iterations performed. This process identifies which values tend to infinity when iterated, and gives us a rough measure of how "quickly" they get there. In dynamical terms, we say that "Infinity is an Attractor", as many initial values get "attracted" to it when iterated. The set of all points that are attracted to infinity is termed The Basin of Attraction of Infinity. The coloring algorithm used divides this Basin of Attraction into many distinct sets, each a single band of one color, representing all the points that are "attracted" to Infinity at the same "rate". These sets (bands of color) are termed "Level Sets" - all points in such a set are at the same "Level" away from the attractor, in terms of numbers of iterations required to exceed the bailout value. Thus, xmfract produces colored images of the Level Sets of the Basin of Attraction of Infinity, for all fractals that iterate functions of Complex numbers, at least. Now we have a sound mathematical definition of what xmfract's "bailout" processing generates, and we have formally introduced the terms Attractor, Basin of Attraction, and Level Set, so you should have little trouble following the rest of this section! For certain Julia-type fractals, xmfract can also display the Level Sets of Basins of Attraction of Finite Attractors. This capability is a by- product of the implementation of the MAGNETic fractal types, which always have at least one Finite Attractor. This option can be invoked by setting the "Look for finite attractor" option on the options screen, or by giving the "finattract=yes" command-line option. Most Julia-types that have a "lake" (normally colored blue by default) have a Finite Attractor within this lake, and the lake turns out to be, quite appropriately, the Basin of Attraction of this Attractor. The "finattract=yes" option (command-line or options screen) instructs xmfract to seek out and identify a possible Finite Attractor and, if found, to display the Level Sets of its Basin of Attraction, in addition to those of the Basin of Attraction of Infinity. In many cases this results in a "lake" with colored "waves" in it; in other cases there may be little change in the lake's appearance. For a quick demonstration, select a fractal type of LAMBDA, with a parameter of 0.5 + 0.5i. You will obtain an image with a large blue lake. Now set "Look for finite attractor" to 1 with the "Y" menu. The image will be re-drawn with a much more colorful lake. A Finite Attractor lives in the center of one of the resulting "ripple" patterns in the lake - turn the rbits display on to see where it is - the orbits of all initial points that are in the lake converge there. Xmfract tests for the presence of a Finite Attractor by iterating a Critical Value of the fractal's function. If the iteration doesn't bail out before exceeding twice the iteration limit, it is almost certain that we have a Finite Attractor - we assume that we have. Next we define a small circle around it and, after each iteration, as well as testing for the usual bailout value being exceeded, we test to see if we've hit the circle. If so, we bail out and color our pixels according to the number of iterations performed. Result - a nicely colored-in lake that displays the Level Sets of the Basin of Attraction of the Finite Attractor. Sometimes ! First exception: This does not work for the lakes of Mandel-types. Every point in a Mandel-type is, in effect, a single point plucked from one of its related Julia-types. A Mandel-type's lake has an infinite number of points, and thus an infinite number of related Julia-type sets, and consequently an infinite number of finite attractors too. It *MAY* be possible to color in such a lake, by determining the attractor for EVERY pixel, but this would probably treble (at least) the number of iterations needed to draw the image. Due to this overhead, Finite Attractor logic has not been implemented for Mandel-types. Secondly, certain Julia-types with lakes may not respond to this treatment, depending on the parameter value used. E.g., the Lambda Set for 0.5 + 0.5i responds well; the Lambda Set for 0.0 + 1.0i does not - its lake stays blue. Attractors that consist of single points, or a cycle of a finite number of points are ok. Others are not. If you're into fractal technospeke, the implemented approach fails if the Julia-type is a Parabolic case, or has Siegel Disks, or has Herman Rings. However, all the difficult cases have one thing in common - they all have a parameter value that falls exactly on the edge of the related Mandel- type's lake. You can avoid them by intelligent use of the Mandel-Julia Space-Bar toggle: Pick a view of the related Mandel-type where the center of the screen is inside the lake, but not too close to its edge, then use the space-bar toggle. You should obtain a usable Julia-type with a lake, if you follow this guideline. Thirdly, the initial implementation only works for Julia-types that use the "Standard" fractal engine in xmfract. Fractals with their own special algorithms are not affected by Finite Attractor logic, as yet. Finally, the finite attractor code will not work if it fails to detect a finite attractor. If the number of iterations is set too low, the finite attractor may be missed. Despite these restrictions, the Finite Attractor logic can produce interesting results. Just bear in mind that it is principally a bonus off-shoot from the development of the MAGNETic fractal types, and is not specifically tuned for optimal performance for other Julia types. (Thanks to Kevin Allen for the above). There is a second type of finite attractor coloring, which is selected by setting "Look for Finite Attractor" to a negative value. This colors points by the phase of the convergence to the finite attractor, instead of by the speed of convergence. For example, consider the Julia set for -0.1 + 0.7i, which is the three-lobed "rabbit" set. The Finite Attractor is an orbit of length three; call these values a, b, and c. Then, the Julia set iteration can converge to one of three sequences: a,b,c,a,b,c,..., or b,c,a,b,c,..., or c,a,b,c,a,b,... The Finite Attractor phase option colors the interior of the Julia set with three colors, depending on which of the three sequences the orbit converges to. Internally, the code determines one point of the orbit, say "a", and the length of the orbit cycle, say 3. It then iterates until the sequence converges to a, and then uses the iteration number modulo 3 to determine the color. Continuous Potential: Note: This option can only be used with 256 color modes. Xmfract's images are usually calculated by the "level set" method, producing bands of color corresponding to regions where the calculation gives the same value. When "3D" transformed most images other than plasma clouds are like terraced landscapes: most of the surface is either horizontal or vertical. To get the best results with the "illuminated" 3D fill options 5 and 6, there is an alternative approach that yields continuous changes in colors. Continuous potential is approximated by calculating potential = log(modulus)/2^iterations where "modulus" is the orbit value (magnitude of the complex number) when the modulus bailout was exceeded, at the "iterations" iteration. Clear as mud, right? Fortunately, you don't have to understand all the details. However, there ARE a few points to understand. First, xmfract's criterion for halting a fractal calculation, the "modulus bailout value", is generally set to 4. Continuous potential is inaccurate at such a low value. The parameters for continuous potential are: potential=maxcolor[/slope[/modulus[/16bit]]] These parameters are present on the options screen. "Maxcolor" is the color corresponding to zero potential, which plots as the TOP of the mountain. Generally this should be set to one less than the number of colors, i.e. usually 255. "Slope" affects how rapidly the colors change -- the slope of the "mountains" created in 3D. If this is too low, the palette will not cover all the potential values and large areas will be black. If it is too high, the range of colors in the picture will be much less than those available. There is no easy way to predict in advance what this value should be. "Modulus" is the bailout value used to determine when an orbit has "escaped". Larger values give more accurate and smoother potential. A value of 500 gives excellent results. "16bit": If you transform a continuous potential image to 3D, the illumination modes 5 and 6 will work fine, but the colors will look a bit granular. This is because even with 256 colors, the continuous potential is being truncated to integers. The "16bit" option can be used to add an extra 8 bits of goodness to each stored pixel, for a much smoother result when transforming to 3D. Xmfract's visible behavior is unchanged when 16bit is enabled, except that solid guessing and boundary tracing are not used. But when you save an image generated with 16bit continuous potential: o The saved file is a fair bit larger. o Xmfract names the file with a .POT extension instead of .GIF, if you didn't specify an extension in "savename". o The image can be used as input to a subsequent <3> command to get the promised smoother effect. o If you happen to view the saved image with a GIF viewer other than xmfract, you'll find that it is twice as wide as it is supposed to be. (Guess where the extra goodness was stored!) Though these files are structurally legal GIF files the double-width business made us think they should perhaps not be called GIF - hence the .POT filename extension. A 16bit (.POT) file can be converted to an ordinary 8 bit GIF by estoring it, changing "16bit" to "no" on the options screen, and aving. The following commands can be used to recreate the image that Mark Peterson first prototyped for us, and named "MtMand": type=mandel corners=-0.19920/-0.11/1.0/1.06707 inside=255 maxiter=255 potential=255/2000/1000/16bit passes=1 float=yes Note that prior to version 15.0, Fractint: o Produced "16 bit TGA potfiles" This format is no longer generated, but you can still (for a release or two) use and <3> with those files. o Assumed "inside=maxit" for continuous potential. It now uses the current "inside=" value - to recreate prior results you must be explicit about this parameter. Distance Estimator Method: This is Phil Wilson's implementation of an alternate method for the M and J sets, based on work by mathematician John Milnor and described in "The Science of Fractal Images", p. 198. While it can take full advantage of your color palette, one of the best uses is in preparing monochrome images for a printer. Using the 1600x1200x2 disk-video mode and an HP LaserJet, we have produced pictures of quality equivalent to the black and white illustrations of the M-set in "The Beauty of Fractals." The distance estimator method widens very thin "strands" which are part of the "inside" of the set. Instead of hiding invisibly between pixels, these strands are made one pixel wide. Though this option is available with any escape time fractal type, the formula used is specific to the mandel and julia types - for most other types it doesn't do a great job. To turn on the distance estimator method with any escape time fractal type, set the "Distance Estimator" value on the options screen (or use the "distest=" command line parameter). Setting the distance estimator option to a negative value -nnn enables edge-tracing mode. The edge of the set is display as color number nnn. This option works best when the "inside" and "outside" color values are also set to some other value(s). In a 2 color (monochrome) mode, setting to any positive value results in the inside of the set being expanded to include edge points, and the outside points being displayed in the other color. In color modes, setting to value 1 causes the edge points to be displayed using the inside color and the outside points to be displayed in their usual colors. Setting to a value greater than one causes the outside points to be displayed as contours, colored according to their distance from the inside of the set. Use a higher value for narrower color bands, a lower value for wider ones. 1000 is a good value to start with. The second distance estimator parameter ("width factor") sets the distance from the inside of the set which is to be considered as part of the inside. This value is expressed as a percentage of a pixel width, the default is 71. You should use 1 or 2 pass mode with the distance estimator method, to avoid missing some of the thin strands made visible by it. For the highest quality, "maxiter" should also be set to a high value, say 1000 or so. You'll probably also want "inside" set to zero, to get a black interior. Unfortunately, images using the distance estimator method can take many hours to calculate even on a fast machine, especially if a high "maxiter" value is used. One way of dealing with this is to leave it turned off while you find and frame an image. Then hit to save the current image information in a parameter file. Use an editor to change the parameter file entry, adding "distest=1", "maxiter=1000", and "inside=0". Run the parameter file entry with the <@> command when you won't be needing your machine for a while (over the weekend?) Inversion: Many years ago there was a brief craze for "anamorphic art": images painted and viewed with the use of a cylindrical mirror, so that they looked weirdly distorted on the canvas but correct in the distorted reflection. (This byway of art history may be a useful defense when your friends and family give you odd looks for staring at fractal images color- cycling on a CRT.) The Inversion option performs a related transformation on most of the fractal types. You define the center point and radius of a circle xmfract maps each point inside the circle to a corresponding point outside, and vice-versa. This is known to mathematicians as inverting (or if you want to get precise, "everting") the plane, and is something they can contemplate without getting a headache. John Milnor (also mentioned in connection with the {Distance Estimator Method}), made his name in the 1950s with a method for everting a seven-dimensional sphere, so we have a lot of catching up to do. For example, if a point inside the circle is 1/3 of the way from the center to the radius, it is mapped to a point along the same radial line, but at a distance of (3 * radius) from the origin. An outside point at 4 times the radius is mapped inside at 1/4 the radius. The inversion parameters on the options screen allow entry of the radius and center coordinates of the inversion circle. A default choice of -1 sets the radius at 1/6 the smaller dimension of the image currently on the screen. The default values for Xcenter and Ycenter use the coordinates currently mapped to the center of the screen. Try this one out with a Newton plot, so its radial "spokes" will give you something to hang on to. Plot a Newton-method image, then set the inversion radius to 1, with default center coordinates. The center "explodes" to the periphery. Inverting through a circle not centered on the origin produces bizarre effects that we're not even going to try to describe. Aren't computers wonderful? Color-cycling mode is entered with the 'c', '+', or '-' keys. Color cycling applies to the color numbers selected by the "cyclerange=" command line parameter (also changeable via the options screen and via the palette editor). By default, color numbers 2 to 255 inclusive are cycled. The '2' excludes the "lake" from color cycling. Set the value to '0' or '1' for images where you wish to cycle the lake as well. The cursor up/down arrow keys will increase or decrease the cycle speed. Periodicity Logic - controlled by the periodicity checking paramter: The "Mandelbrot Lake" in the center of the M-set images is the traditional bane of plotting programs. It sucks up the most computer time because it always reaches the iteration limit -- and yet the most interesting areas are invariably right at the edge the lake. Thanks to Mark Peterson for pointing out (well, he more like beat us over the head until we paid attention) that the iteration values in the middle of Mandelbrot Lake tend to decay to periodic loops (i.e., Z(n+m) == Z(n), a fact that is pointed out on pages 58-61 of "The Beauty of Fractals"). An intelligent program (like the one he wrote) would check for this periodicity once in a while, recognize that iterations caught in a loop are going to max out, and bail out early. For speed purposes, the current version of the program turns this checking algorithm on only if the last pixel generated was in the lake. (The checking itself takes a small amount of time, and the pixels on the very edge of the lake tend to decay to periodic loops very slowly, so this compromise turned out to be the fastest generic answer). Try a full M-set plot with a 1000-iteration maximum with any other program, and then try it on this one for a pretty dramatic proof of the value of periodicity checking. You can get a visual display of the periodicity effects if you press rbits while plotting. This toggles display of the intermediate iterations during the generation process. It also gives you an idea of how much work your poor little computer is going through for you! If you use this toggle, it's best to disable solid-guessing first using 1- or 2-pass mode because in its second pass, solid-guessing bypasses many of the pixel calculations precisely where the orbits are most interesting. Periodicity: Controls periodicity checking; "No" turns it off, "Show" lets you see which pixels were painted as "inside" due to being caught by periodicity. Specifying a number causes a more conservative periodicity test (each increase of 1 divides test tolerance by 2). Entering a negative number lets you turn on "show" with that number. Type lambdafn function=exp needs periodicity turned off to be accurate -- there may be other cases. The "Mandelbrot Lake" in the center of the M-set images is the traditional bane of plotting programs. It sucks up the most computer time because it always reaches the iteration limit -- and yet the most interesting areas are invariably right at the edge the lake. Thanks to Mark Peterson for pointing out (well, he more like beat us over the head until we paid attention) that the iteration values in the middle of Mandelbrot Lake tend to decay to periodic loops (i.e., Z(n+m) == Z(n), a fact that is pointed out on pages 58-61 of "The Beauty of Fractals"). An intelligent program (like the one he wrote) would check for this periodicity once in a while, recognize that iterations caught in a loop are going to max out, and bail out early. For speed purposes, the current version of the program turns this checking algorithm on only if the last pixel generated was in the lake. (The checking itself takes a small amount of time, and the pixels on the very edge of the lake tend to decay to periodic loops very slowly, so this compromise turned out to be the fastest generic answer). Try a full M-set plot with a 1000-iteration maximum with any other program, and then try it on this one for a pretty dramatic proof of the value of periodicity checking. You can get a visual display of the periodicity effects if you press rbits while plotting. This toggles display of the intermediate iterations during the generation process. It also gives you an idea of how much work your poor little PC is going through for you! If you use this toggle, it's best to disable solid-guessing first using <1> or <2> because in its second pass, solid-guessing bypasses many of the pixel calculations precisely where the orbits are most interesting. Symmetry If your "corners" choice is symmetrical, xmfract exploits the symmetry for faster display. Normally this is set by your selection of fractal type, and is included here because it makes debugging a new type easier, and for experimentation. Rseed The random number seed used for each plasma image is displayed on the information screen, and can be entered here to recreate a particular image. Showdot This colors the pixel currently being worked on using the specified color value (useful for those lloooonngg images being calculated using solid guessing - "where is it now?").