Iterated Dynamics

Iterated Dynamics is open source software. The copyright is retained by the primary author, Richard Thomson. Legacy code is copyright the Stone Soup Group.

Iterated Dynamics may be freely copied and distributed in unmodified form but may not be sold. Iterated Dynamics may be used personally or in a business - if you can do your job better by using Iterated Dynamics, or using images from it, that’s great! It may not be given away with commercial products without explicit permission from Richard Thomson.

There is no warranty of Iterated Dynamics’s suitability for any purpose, nor any acceptance of liability, express or implied.

Source code for Iterated Dynamics is freely available on github at https://github.com/LegalizeAdulthood/iterated-dynamics

See the file LICENSE.txt for details on distributing the program.

To start the program, locate the Id executable in the installation directory. The program displays an initial "credits" screen. If Id doesn’t start properly, please see Common Problems.

Hitting Enter gets you from the initial screen to the main menu. You can select options from the menu by moving the highlight with the arrow keys (Left, Right, Up, Down) and pressing Enter, or you can enter commands directly.

As soon as you select a video mode, Id begins drawing an image - the "full" Mandelbrot set if you haven’t selected another fractal type.

For a quick start, after starting Id try one of the following:

After the initial Mandelbrot image has been displayed, try zooming into it (see Zoom Box Commands) and color cycling (see Color Cycling Commands ). Once you’re comfortable with these basics, start exploring other functions from the main menu.

Help is available from the menu and at most other points in Id by pressing the F1 key.

At any time, you can hit a command key to select a function. You do not need to wait for a calculation to finish, nor do you have to return to the main menu.

When entering commands, note that for the "typewriter" keys, upper and lower case are equivalent in most situations, e.g. B and Shift+B have the same result. When an upper case letter is required, such as telling Id to delete the current file in browse mode, it will be described as Shift+D.

Many commands and parameters can be passed to Id as command-line arguments or read from a configuration file; see "Command Line Parameters, Parameter Files, Batch Mode" for details.

Function keys & various combinations are used to select a video mode and redraw the screen. For a quick start try one of the following:

M or Esc Return from a displayed image to the main menu.

Esc From the main menu, Esc is used to exit from Id.

Delete Same as choosing "select video mode" from the main menu. Goes to the "select video mode" screen. See Video Mode Function Keys.

H Redraw the previous image in the circular history buffer, revisiting fractals you previously generated this session in reverse order. Id saves the last ten images worth of information including fractal type, coordinates, colors, and all options. Image information is saved only when some item changes. After ten images the circular buffer wraps around and earlier information is overwritten. You can set image capacity of the history feature using the maxhistory=<nnn> command.

Ctrl+H Redraw the next image in the circular history buffer. Use this to return to images you passed by when using H.

Tab Display the current fractal type, parameters, video mode, screen or (if displayed) zoom-box coordinates, maximum iteration count, and other information useful in keeping track of where you are. The Tab function is non-destructive - if you press it while in the midst of generating an image, you will continue generating it when you return. The Tab function tells you if your image is still being generated or has finished - a handy feature for those overnight, 1024x768 resolution fractal images. If the image is incomplete, it also tells you whether it can be interrupted and resumed. (Any function other than Tab and F1 counts as an "interrupt".)

The Tab screen also includes a pixel-counting function, which will count the number of pixels colored in the inside color. This gives an estimate of the area of the fractal. Note that the inside color must be different from the outside color(s) for this to work; inside=0 is a good choice.

T Select a fractal type. Move the cursor to your choice (or type the first few letters of its name) and hit Enter. Next you will be prompted for any parameters used by the selected type - hit Enter for the defaults. See Fractal Types for a list of supported types.

F Toggles the use of floating-point algorithms (see Limitations of Integer Math (and How We Cope)). Whether floating point is in use is shown on the Tab status screen. The floating point option can also be turned on and off using the "X" options screen. X Select a number of eXtended options. Brings up a full-screen menu of options, any of which you can change at will. These options are: "passes=" - see Drawing Method Floating point toggle - see F key description below "maxiter=" - see Image Calculation Parameters "inside=" and "outside=" - see Color Parameters "savename=" filename - see File Parameters "overwrite=" option - see File Parameters "sound=" option - see Sound Parameters "logmap=" - see Logarithmic Palettes and Color Ranges "biomorph=" - see Biomorphs "decomp=" - see Decomposition "fillcolor=" - see Drawing Method

Y More options which we couldn’t fit under the X command: "finattract=" - see Finite Attractors "potential=" parameters - see Continuous Potential "invert=" parameters - see Inversion "distest=" parameters - see Distance Estimator Method "cyclerange=" - see Color Cycling Commands

P Options that apply to the Passes feature: "periodicity=" - see Periodicity Logic "orbitdelay=" - see Passes Parameters "orbitinterval=" - see Passes Parameters "screencoords=" - see Passes Parameters "orbitdrawmode=" - see Passes Parameters

Z Modify the parameters specific to the currently selected fractal type. This command lets you modify the parameters which are requested when you select a new fractal type with the T command, without having to repeat that selection. You can enter "e" or "p" in column one of the input fields to get the numbers e and pi (2.71828…​ and 3.14159…​). From the fractal parameters screen, you can press F6 to bring up a sub parameter screen for the coordinates of the image’s corners. With selected fractal types, Z allows you to change the Bailout Test.

+ or - Switch to color-cycling mode and begin cycling the palette by shifting each color to the next "contour." See Color Cycling Commands.

C Switch to color-cycling mode but do not start cycling. The normally black "overscan" border of the screen changes to white. See Color Cycling Commands.

E Enter Palette-Editing Mode. See Palette Editing Commands.

Space Toggle between Mandelbrot set images and their corresponding Julia-set images. Read the notes in Fractal Types, Julia Sets before trying this option if you want to see anything interesting.

J Toggle between Julia escape time fractal and the Inverse Julia orbit fractal. See Inverse Julias

Enter Enter is used to resume calculation after a pause. It is only necessary to do this when there is a message on the screen waiting to be acknowledged, such as the message shown after you save an image to disk.

I Modify 3D transformation parameters used with 3D fractal types such as "Lorenz3D" and 3D "IFS" definitions, including the selection of "funny glasses" red/blue 3D.

A Convert the current image into a fractal 'starfield'. See Starfields.

Ctrl+A Unleash an image-eating ant automaton on current image. See Ant Automaton.

Ctrl+S (or K) Convert the current image into a Random Dot Stereogram (RDS). See Random Dot Stereograms (RDS).

O (the letter, not the number) If pressed while an image is being generated, toggles the display of intermediate results — the "orbits" Id uses as it calculates values for each point. Slows the display a bit, but shows you how clever the program is behind the scenes. (See "A Little Code" in Fractals and the PC.)

D Shell to a command prompt. Return to Id by exiting your command shell, usually by entering the command "exit".

Insert Restart at the "credits" screen and reset most variables to their initial state. Variables which are not reset are: savename, lightname, video, startup filename.

L Enter Browsing Mode. See Browse Commands.

Ctrl+E Enter Explorer/Evolver Mode. See Evolver Commands.

Zoom Box functions can be invoked while an image is being generated or when it has been completely drawn. Zooming is supported for most fractal types, but not all.

The general approach to using the zoom box is: Frame an area using the keys described below, then Enter to expand what’s in the frame to fill the whole screen (zoom in); or Ctrl+Enter to shrink the current image into the framed area (zoom out). With a mouse, double-click the left button to zoom in, double click the right button to zoom out.

PageUp, PageDown Use PageUp to initially bring up the zoom box. It starts at full screen size. Subsequent use of these keys makes the zoom box smaller or larger. Using PageDown to enlarge the zoom box when it is already at maximum size removes the zoom box from the display. Moving the mouse away from you or toward you while holding the left button down performs the same functions as these keys.

Using the "arrow" keys (Left, Right, Up, Down) or moving the mouse without holding any buttons down, moves the zoom box.

Holding Ctrl while pressing arrow keys moves the box 5 times faster.

Panning: If you move a fullsize zoombox and don’t change anything else before performing the zoom, Id just moves what’s already on the screen and then fills in the new edges, to reduce drawing time. This feature applies to most fractal types but not all. A side effect is that while an image is incomplete, a full size zoom box moves in steps larger than one pixel. Id keeps the box on multiple pixel boundaries, to make panning possible. As a multi-pass (e.g. solid guessing) image approaches completion, the zoom box can move in smaller increments.

In addition to resizing the zoom box and moving it around, you can do some rather warped things with it. If you’re a new Id user, we recommend skipping the rest of the zoom box functions for now and coming back to them when you’re comfortable with the basic zoom box functions.

Ctrl+Keypad-, Ctrl+Keypad+ Holding Ctrl and pressing the numeric keypad’s + or - keys rotates the zoom box. Moving the mouse left or right while holding the right button down performs the same function.

Ctrl+PageUp, Ctrl+PageDown These commands change the zoom box’s "aspect ratio", stretching or shrinking it vertically. Moving the mouse away from you or toward you while holding both buttons (or the middle button on a 3-button mouse) down performs the same function. There are no commands to directly stretch or shrink the zoom box horizontally - the same effect can be achieved by combining vertical stretching and resizing.

Ctrl+Home, Ctrl+End These commands "skew" the zoom box, moving the top and bottom edges in opposite directions. Moving the mouse left or right while holding both buttons (or the middle button on a 3-button mouse) down performs the same function. There are no commands to directly skew the left and right edges - the same effect can be achieved by using these functions combined with rotation.

Ctrl+Insert, Ctrl+Delete These commands change the zoom box color. This is useful when you’re having trouble seeing the zoom box against the colors around it. Moving the mouse away from you or toward you while holding the right button down performs the same function.

You may find it difficult to figure out what combination of size, position rotation, stretch, and skew to use to get a particular result. (We do.)

A good way to get a feel for all these functions is to play with the Gingerbreadman fractal type. Gingerbreadman’s shape makes it easy to see what you’re doing to him. A warning though: Gingerbreadman will run forever, he’s never quite done! So, pre-empt with your next zoom when he’s baked enough.

If you accidentally change your zoom box shape or rotate and forget which way is up, just use PageDown to make it bigger until it disappears, then PageUp to get a fresh one. With a mouse, after removing the old zoom box from the display release and re-press the left button for a fresh one.

If your video mode does not have a 4:3 "aspect ratio" (i.e. if the visible display area on it is not 1.333 times as wide as it is high), rotating and zooming will have some odd effects - angles will change, including the zoom box’s shape itself, circles (if you are so lucky as to see any with a non-standard aspect ratio) become non-circular, and so on.

Zooming is not implemented for the plasma and diffusion fractal types, nor for overlayed and 3D images. A few fractal types support zooming but do not support rotation and skewing - nothing happens when you try it.

Color-cycling mode is entered with the C, +, or - keys from an image, or with the C key from Palette-Editing mode.

You can also enter color-cycling while using a disk-video mode, to load or save a palette - other functions are not supported in disk-video.

Color cycling applies to the color numbers selected by the "cyclerange=" command line parameter (also changeable via the Y options screen and via the palette editor). By default, color numbers 1 to 255 inclusive are cycled. On some images you might want to set "inside=0" (X options or command line parameter) to exclude the "lake" from color cycling. When you are in color-cycling mode, you will either see the screen colors cycling, or will see a white "overscan" border when paused, as a reminder that you are still in this mode. The keyboard commands available once you’ve entered color-cycling. are described below.

F1 Bring up a help screen with commands specific to color cycling mode.

Esc Leave color-cycling mode.

Home Restore original palette.

+ or - Begin cycling the palette by shifting each color to the next "contour." + cycles the colors in one direction, - in the other.

< or > Force a color-cycling pause, disable random colorizing, and single-step through a one color-cycle. For "fine-tuning" your image colors.

Up/Down Increase/decrease the cycling speed.

F2 through F10 Switches from simple rotation to color selection using randomly generated color bands of short (F2) to long (F10) duration.

1 through 9 Causes the screen to be updated every 'n' color cycles (the default is 1). Handy for slower computers.

Enter Randomly selects a function key (F2 through F10) and then updates ALL the screen colors prior to displaying them for instant, random colors. Hit this over and over again (we do).

Space Pause cycling with white overscan area. Cycling restarts with any command key (including another spacebar).

Shift+F1 …​ Shift+F10 Pause cycling and reset the palette to a preset two color "straight" assignment, such as a spread from black to white

Ctrl+F1 …​ Ctrl+F10 Pause & set a 2-color cyclical assignment, e.g. red→yellow→red.

Alt+F1 …​ Alt+F10 Pause & set a 3-color cyclical assignment, e.g. green→white→blue.

Shift+R, Shift+G, Shift+B Pause and increase the red, green, or blue component of all colors by a small amount. Note the case distinction of this vs: R, G, B Pause and decrease the red, green, or blue component of all colors by a small amount.

D or A Pause and load an external color map from the files default.map or altern.map, supplied with the program.

L Pause and load an external color map (.map file). Several .map files are supplied with Id. See Color Maps.

S Pause, prompt for a filename, and save the current color palette to the named file (.map assumed). See Color Maps.

Palette-editing mode provides a number of tools for modifying the colors in an image. Many thanks to Ethan Nagel for creating the palette editor.

Use the E key to enter palette-editing mode from a displayed image or from the main menu.

When this mode is entered, an empty palette frame is displayed. You can use the arrow keys to position the frame outline, and PageUp and PageDown to change its size. (The upper and lower limits on the size depend on the current video mode.) When the frame is positioned where you want it, hit Enter to display the current palette in the frame.

Note that the palette frame shows R(ed) G(reen) and B(lue) values for two color registers at the top. The active color register has a solid frame, the inactive register’s frame is dotted. Within the active register, the active color component is framed.

With a video mode of 640x400 or higher, a status area appears between the two color registers. This status area shows:

Using the commands described below, you can assign particular colors to the registers and manipulate them. Note that at any given time there are two colors "X"d - these are pre-empted by the editor to display the palette frame. They can be edited but the results won’t be visible. You can change which two colors are borrowed ("X"d out) by using the V command.

Once the palette frame is displayed and filled in, the following commands are available: F1 Bring up a help screen with commands specific to palette-editing mode.

Esc Leave palette-editing mode

H Hide the palette frame to see full image; the cross-hair remains visible and all functions remain enabled; hit H again to restore the palette display.

Left, Right, Up, Down Move the cross-hair cursor around. In 'auto' mode (the default) the color under the center of the cross-hair is automatically assigned to the active color register. Control-arrow keys move the cross-hair faster. A mouse can also be used to move around.

R, G, B Select the Red, Green, or Blue component of the active color register for subsequent commands

Insert, Delete Select previous or next color component in active register

+, - Increase or decrease the active color component value by 1. Numeric keypad + and - keys do the same.

PageUp, PageDown Increase or decrease the active color component value by 5; Moving the mouse up/down with left button held is the same

0, 1, 2, 3, 4, 5, 6 Set the active color component’s value to 0 10 20 …​ 60

Space Select the other color register as the active one. In the default 'auto' mode this results in the now-inactive register being set to remember the color under the cursor, and the now-active register changing from whatever it had previously remembered to now follow the color.

, (comma), . (period) Rotate the palette one step. By default colors 1 through 255 inclusive are rotated. This range can be over-ridden with the "cyclerange" parameter, the Y options screen, or the O command described below.

<, > Rotate the palette continuously (until next keystroke)

O (oh, not zero) Set the color cycling range to the range of colors currently defined by the color registers.

C Enter Color-Cycling Mode. When you invoke color-cycling from here, it will subsequently return to palette-editing when you Esc from it. See Color Cycling Commands.

= Create a smoothly shaded range of colors between the colors selected by the two color registers.

M Specify a gamma value for the shading created by =.

D Duplicate the inactive color register’s values to the active color register.

T Stripe-shade - create a smoothly shaded range of colors between the two color registers, setting only every Nth register. After hitting T, hit a numeric key from 2 to 9 to specify N. For example, if you press T 3, smooth shading is done between the two color registers, affecting only every 3rd color between them. The other colors between them remain unchanged. W Convert current palette to gray-scale. (If the X or Y exclude ranges described later are in force, only the active range of colors is converted to gray-scale.)

Shift+F2 …​ Shift+F9 Store the current palette in a temporary save area associated with the function key. The temporary save palettes are useful for quickly comparing different palettes or the effect of some changes - see next command. The temporary palettes are only remembered until you exit from palette-editing mode. When palette editing mode is entered, the original palette is stored in the area associated with Shift+F2.

F2 …​ F9 Restore the palette from a temporary save area. If you haven’t previously saved a palette for the function key, you’ll get a simple grey scale.

L Pause and load an external color map (.map file). See Color Maps.

S Pause, prompt for a filename, and save the current color palette to the named file (.map assumed). See Color Maps.

I Invert frame colors. With some colors the palette is easier to see when the frame colors are interchanged.

\ Move or resize the palette frame. The frame outline is drawn - it can then be repositioned and sized with the arrow keys, PageUp and PageDown, just as was done when first entering palette-editing mode. Hit Enter when done moving/sizing.

V Use the colors currently selected by the two color registers for the palette editor’s frame. When palette editing mode is entered, the last two colors are "X"d out for use by the palette editor; this command can be used to replace the default with two other color numbers.

A Toggle 'auto' mode on or off. When on (the default), the active color register follows the cursor; when off, Enter must be pressed to set the active register to the color under the cursor.

Enter Only useful when 'auto' is off, as described above; double clicking the left mouse button is the same as Enter.

X Toggle 'exclude' mode on or off - when toggled on, only those image pixels which match the active color are displayed. Y Toggle 'exclude' range on or off - similar to X, but all pixels matching colors in the range of the two color registers are displayed.

N Make a negative color palette - will convert only current color if in 'x' mode or range between editors in 'y' mode or entire palette if in "normal" mode.

!, @, # Swap R/G, G/B, and R/B columns. !, @, and # are Shift+1, Shift+2, and Shift+3, which you may find easier to remember.

U Undoes the last palette editor command. Will undo all the way to the beginning of the current session.

E Redoes the undone palette editor commands.

F Toggles "Freestyle mode" on and off (Freestyle mode changes a range of palette values smoothly from a center value outward). With your cursor inside the palette box, press the F key to enter Freestyle mode. A default range of colors will be selected for you centered at the cursor (the ends of the color range are noted by putting dashed lines around the corresponding palette values). While in Freestyle mode:

For more details see Freestyle mode tutorial

S saves the current image to disk. All parameters required to recreate the image are saved with it. Progress is marked by colored lines moving down the screen’s edges.

The default filename for the first image saved after starting Id is fract001.gif; subsequent saves in the same session are automatically incremented 002, 003…​ Use the "savename=" parameter or X options screen to change the name. By default, files left over from previous sessions are not overwritten - the first unused fractnnn name is used. Use the "overwrite=yes" parameter or X options screen) to overwrite existing files.

A save operation can be interrupted by pressing any key. If you interrupt, you’ll be asked whether to keep or discard the partial file.

R restores an image previously saved with S, or an ordinary GIF file. After pressing R you are shown the file names in the current directory which match the current file mask. To select a file to restore, move the cursor to it (or type the first few letters of its name) and press Enter.

Directories are shown in the file list with a "\" at the end of the name. When you select a directory, the contents of that directory are shown. Or, you can type the name of a different directory and press Enter for a new display. You can also type a mask such as "*.xyz" and press Enter to display files whose name ends with the matching suffix (xyz).

You can use F6 to switch directories to the default Id directory or to your own directory which is specified through the environment variable "FRACTDIR".

Once you have selected a file to restore, a summary description of the file is shown, with a video mode selection list. Usually you can just press Enter to go past this screen and load the image. Other choices available at this point are: Arrow keys: select a different video mode Tab: display more information about the fractal F1: for help about the "err" column in displayed video modes If you restore a file into a video mode which does not have the same pixel dimensions as the file, Id will make some adjustments: The view window parameters (see V command) will automatically be set to an appropriate size, and if the image is larger than the screen dimensions, it will be reduced by using only every Nth pixel during the restore.

Parameter files can be used to save/restore all options and settings required to recreate particular images. The parameters required to describe an image require very little disk space, especially compared with saving the image itself.

@ or 2

The @ or 2 command loads a set of parameters describing an image. (Actually, it can also be used to set non-image parameters such as sound, but at this point we’re interested in images. Other uses of parameter files are discussed in Parameter Files and the @ Command.)

When you hit @ or 2, Id displays the names of the entries in the currently selected parameter file. The default parameter file, id.par, is included with the Id release and contains parameters for some sample images. After pressing @ or 2, highlight an entry and press Enter to load it, or press F6 to change to another parameter file.

Note that parameter file entries specify all calculation related parameters, but do not specify things like the video mode - the image will be plotted in your currently selected mode.

B

The B command saves the parameters required to describe the currently displayed image, which can subsequently be used with the @ or 2 command to recreate it.

After you press B, Id prompts for:

G

The G command lets you give a startup parameter interactively.

See "3D" Images for details of these commands.

3 Restore a saved image as a 3D "landscape", translating its color information into "height". You will be prompted for all KINDS of options. # Restore in 3D and overlay the result on the current screen.

Id command keys can be loosely grouped as:

An image which is Saved before it completes can later be Restored and continued. The calculation is automatically resumed when you restore such an image.

When a slow fractal type resumes after an interruption in the third category above, there may be a lag while nothing visible happens. This is because most cases of resume restart at the beginning of a screen line. If unsure, you can check whether calculation has resumed with the Tab key.

The following fractal types cannot (currently) be resumed: plasma, 3D transformations, julibrot, and 3D orbital types like lorenz3d. To check whether resuming an image is possible, use the Tab key while it is calculating. It is resumable unless there is a note under the fractal type saying it is not.

The Batch Mode section discusses how to resume in batch mode.

To Restore and resume a "formula", "lsystem", or "ifs" type fractal your "formulafile", "lfile", or "ifsfile" must contain the required name.

The O key turns on the Orbit mode. In this mode a cursor appears over the fractal. A window appears showing the orbit used in the calculation of the color at the point where the cursor is. Move the cursor around the fractal using the arrow keys or the mouse and watch the orbits change. Try entering the Orbits mode with View Windows (V) turned on. The following keys take effect in Orbits mode. C Circle toggle - makes little circles with radii inversely proportional to the iteration. Press C again to toggle back to point-by-point display of orbits. L Line toggle - connects orbits with lines (can use with C) N Numbers toggle - shows complex coordinates & color number of the cursor on the screen. Press N again to turn off numbers. P Enter pixel coordinates directly H Hide fractal toggle. Works only if View Windows is turned on and set for a small window (such as the default size.) Hides the fractal, allowing the orbit to take up the whole screen. Press H again to uncover the fractal. S Saves the fractal, cursor, orbits, and numbers as they appear on the screen. < or , Zoom orbits image smaller > or . Zoom orbits image larger Z Restore default zoom.

The V command is used to set the view window parameters described below. These parameters can be used to: * Define a small window on the screen which is to contain the generated images. Using a small window speeds up calculation time (there are fewer pixels to generate). You can use a small window to explore quickly, then turn the view window off to recalculate the image at full screen size. * Generate an image with a different "aspect ratio"; e.g. in a square window or in a tall skinny rectangle. * View saved GIF images which have pixel dimensions different from any mode supported by your hardware. This use of view windows occurs automatically when you restore such an image. * Define a disk video mode up to 32767x32767. First select a disk video mode using Delete. Then on the V screen enter both an X and a Y value at the Virtual Screen Total Pixels prompts. * Define a virtual video mode up to the size that fits in memory. First select a video mode using Delete. Then on the V screen enter both an X and a Y value at the Virtual Screen Total Pixels prompts. The Keep Aspect prompt is used if the asked for virtual screen is larger than video memory. If set, the X and Y values will both be reduced such that the ratio between them is maintained. If not set, just the Y value will be reduced.

"Preview display" Set this to "yes" to turn on view window, "no" for full screen display. While this is "no", the only view parameter which has any affect is "final media aspect ratio". When a view window is being used, all other Id functions continue to operate normally - you can zoom, color-cycle, and all the rest.

"Reduction factor" When an explicit size is not given, this determines the view window size, as a factor of the screen size. For example, a reduction factor of 2 makes the window 1/2 as big as the screen in both dimensions.

"Final media aspect ratio" This is the height of the final image you want, divided by the width. The default is 0.75 because typical video modes have a height:width ratio of 3:4. For example, set this to 2.0 for an image twice as high as it is wide. The effect of this parameter is visible only when "preview display" is enabled. If the explicit size of both x and y are set, setting this value to 0 will cause the appropriate value to be calculated based on x and y.

"Crop starting coordinates" This parameter affects what happens when you change the aspect ratio. If set to "no", then when you change aspect ratio, the prior image will be squeezed or stretched to fit into the new shape. If set to "yes", the prior image is "cropped" to avoid squeezing or stretching.

"Explicit size" Setting these to non-zero values over-rides the "reduction factor" with explicit sizes in pixels. If only the "x pixels" size is specified, the "y pixels" size is calculated automatically based on x and the aspect ratio.

The following option is available when using disk video or virtual screen modes:

"Virtual screen" Setting these allow defining a virtual screen as large as the available video memory will permit.

The following options are available when using virtual screen modes:

"Keep aspect" If this is set, when the asked for virtual screen is larger than video memory the X and Y values will both be reduced such that the ratio between them is maintained. If not set, just the Y value will be reduced.

"Zoombox scrolling" The fixed setting tries to maintain the zoombox in the center of the screen by moving the virtual image. The relaxed setting moves the virtual image when the zoombox reached the edges of the screen.

More about final aspect ratio: If you want to produce a high quality hard-copy image which is say 8" high by 5" down, based on a vertical "slice" of an existing image, you could use a procedure like the following. You’ll need some method of converting a GIF image to your final media (slide or whatever) - Id can only do the whole job with a PostScript printer, it does not preserve aspect ratio with other printers. * restore the existing image * set view parameters: preview to yes, reduction to anything (say 2), aspect ratio to 1.6, and crop to yes * zoom, rotate, whatever, till you get the desired final image * set preview display back to no * trigger final calculation in some high res disk video mode, using the appropriate video mode function key * print directly to a PostScript printer, or save the result as a GIF file and use external utilities to convert to hard copy.

The concept of a "video mode" in Id is somewhat of a misnomer. Id is just another GUI program on your desktop and doesn’t control the video display directly. The size of the video mode determines the pixel dimenions of any saved images. So you can think of the "video mode" as "image size". In a future release, the saved image size will be decoupled from the size of the displayed image.

The video modes that can be selected are determined entirely from the settings in the id.cfg file. See _id_cfg to customize the set of supported video modes.

Any supported video mode can be selected by going to the "Select Video Mode" screen (from main menu or by using Delete), then using the Up and Down arrow keys and/or PageUp and PageDown keys to highlight the desired mode, then pressing Enter.

Up to 39 modes can be assigned to the keys F2-F10, SF1-SF10 (Shift+Fn), CF1-CF10 (Ctrl+Fn), and AF1-AF10 (Alt+Fn). The modes assigned to function keys can be invoked directly by pressing the assigned key, without going to the video mode selection screen.

30 key combinations can be reassigned: F1 to F10 combined with any of Shift, Ctrl, or Alt. The video modes assigned to F2 through F10 can not be changed - these are assigned to the most common video modes, which might be used in demonstration files or batches.

To reassign a function key to a mode you often use, go to the "select video mode" screen, highlight the video mode, press the keypad + key, then press the desired function key or key combination. The new key assignment will be remembered for future runs.

To unassign a key (so that it doesn’t invoke any video mode), highlight the mode currently selected by the key and press the keypad - key.

See "Disk-Video" Modes for a description of these non-display modes.

The following keystrokes function while browsing an image:

Arrow Keys Step through the outlines on the screen. Enter Selects the image to display. \,H Recalls the last image selected. Shift+D Deletes the selected file. Shift+R Renames the selected file. S Saves the current image with the browser boxes displayed. Esc,L Toggles the browse mode off. Ctrl+B Brings up the Browser Parameters screen. Ctrl+Insert, Change the browser boxes color. Ctrl+Delete

This is a "visual directory" showing the relationship between saved images on disk and the region of the complex plane they represent.

When typing L from a fractal display, the current directory is searched for any saved files that are deeper zooms of the current image and their position shown on screen by a box (or crosshairs if the box would be too small). See also Browser Parameters for more on how this is done.

One outline flashes, the selected outline can be changed by using the arrow keys. At the moment the outlines are selected in the order that they appear in your directory, so don’t worry if the flashing window jumps all over the place!

When enter is pressed, the selected image is loaded. In this mode a stack of the last sixteen selected filenames is maintained and the \ or H key pops and loads the last image you were looking at. Using this it is possible to set up sequences of images that allow easy exploration of your favorite fractal without having to wait for recalc once the level of zoom gets too high, great for demos! (also useful for keeping track of just exactly where fract532.gif came from :-) )

You can also use this facility to tidy up your disk: by typing Shift+D when a file is selected the browser will delete the file for you, after making sure that you really mean it, you must reply to the "are you sure" prompts with an Shift+Y and nothing else, otherwise the command is ignored. Just to make absolutely sure you don’t accidentally wipe out the fruits of many hours of CPU time the default setting is to have the browser prompt you twice, you can disable the second prompt within the parameters screen, however, if you’re feeling overconfident :-).

To complement the delete function there is a rename function, use the Shift+R key for this. You need to enter the full new file name, no .gif is implied.

It is possible to save the current image along with all of the displayed boxes indicating subimages by pressing the S key. This exits the browse mode to save the image and the boxes become a permanent part of the image. Currently, the screen image ends up with stray dots colored after it is saved. Esc backs out of image selecting mode.

Here’s a tip on how to zoom out beyond your starting point when browsing: Suppose you restore a fractal deeply-zoomed down in a directory of related zoomed images, and then bring up the browser. How do you zoom out? You can’t use \ because you started with the zoomed image, and there is no browser command to detect the next outer image. What you can do is exit the browser, press PageUp until the zoom box won’t get any smaller, zoom out with Ctrl+Enter, and before any image starts to develop, call up the browser again, locate your zoomed image that you started with, and see if there is another image that contains it - if so, restore it with the browser. You can also use a view window V to load the first image, and then use the browser.

POSSIBLE ERRORS:

"Sorry..I can’t find anything" The browser can’t locate any files which match the file name mask. See Browser Parameters This is also displayed if you have less than 10K of far memory free when you run Id.

"Sorry…​. no more space" At the moment the browser can only cope with 450 sub images at one time. Any subsequent images are ignored. Make sure that the minimum image size isn’t set too small on the parameters screen.

"Sorry…​it’s a read only file, can’t del [filename]" "Sorry…​.can’t rename" The file which you were trying to delete or rename has the read only attribute set, you’ll need to reset this with your operating system before you can get rid of it.

The following keystrokes function while viewing an RDS image:

Enter or Space  — Toggle calibration bars on and off. Ctrl+S or K  — Return to RDS Parameters Screen. S  — Save RDS image, then restore original. C, +, -  — Color cycle RDS image. Other keys  — Exit RDS mode, restore original image, and pass keystroke on to main menu.

For more about RDS, see Random Dot Stereograms (RDS)

Remember, you do NOT have to wait for the program to finish a full screen display before entering a command. If you see an interesting spot you want to zoom in on while the screen is half-done, don’t wait — do it! If you think after seeing the first few lines that another video mode would look better, go ahead — Id will shift modes and start the redraw at once. When it finishes a display, it beeps and waits for your next command.

In general, the most interesting areas are the "border" areas where the colors are changing rapidly. Zoom in on them for the best results. The first Mandelbrot-set (default) fractal image has a large, solid-colored interior that is the slowest to display; there’s nothing to be seen by zooming there.

Plotting time is directly proportional to the number of pixels in a screen, and hence increases with the resolution of the video mode. You may want to start in a low-resolution mode for quick progress while zooming in, and switch to a higher-resolution mode when things get interesting. Or use the solid guessing mode and pre-empt with a zoom before it finishes. Plotting time also varies with the maximum iteration setting, the fractal type, and your choice of drawing mode. Solid-guessing (the default) is fastest, but it can be wrong: perfectionists will want to use dual-pass mode (its first-pass preview is handy if you might zoom pre-emptively) or single-pass mode.

When you start systematically exploring, you can save time (and hey, every little bit helps — these "objects" are INFINITE, remember!) by Saving your last screen in a session to a file, and then going straight to it the next time by using the command id fractxxx (the .gif extension is assumed), or by starting Id normally and then using the R command to reload the saved file. Or you could hit B to create a parameter file entry with the "recipe" for a given image, and next time use the @ command to re-plot it.

This initial 1.0 release of Iterated Dynamics builds on unix, but the port is incomplete. A subsequent release will restore parity of functionality between unix and Windows, resulting in a truly cross- platform release. This should also make a macOS release possible, marking the first time this code base has been ported to the Macintosh line of computers.

(type=mandel)

This set is the classic: the only one implemented in many plotting programs, and the source of most of the printed fractal images published. Like most of the other types in Id, it is simply a graph: the x (horizontal) and y (vertical) coordinate axes represent ranges of two independent quantities, with various colors used to symbolize levels of a third quantity which depends on the first two. So far, so good: basic analytic geometry.

Now things get a bit hairier. The x axis is ordinary, vanilla real numbers. The y axis is an imaginary number, i.e. a real number times i, where i is the square root of -1. Every point on the plane — in this case, Id’s main window — represents a complex number of the form:

If your math training stopped before you got to imaginary and complex numbers, this is not the place to catch up. Suffice it to say that they are just as "real" as the numbers you count fingers with (they’re used every day by electrical engineers) and they can undergo the same kinds of algebraic operations.

OK, now pick any complex number — any point on the complex plane — and call it C, a constant. Pick another, this time one which can vary, and call it Z. Starting with Z=0 (i.e., at the origin, where the real and imaginary axes cross), calculate the value of the expression

Take the result, make it the new value of the variable Z, and calculate again. Take that result, make it Z, and do it again, and so on: in mathematical terms, iterate the function Z(n+1) = Z(n)^2 + C. For certain values of C, the result "levels off" after a while. For all others, it grows without limit. The Mandelbrot set you see at the start — the solid-colored lake (blue by default), the blue circles sprouting from it, and indeed every point of that color — is the set of all points C for which the magnitude of Z is less than 2 after 150 iterations (150 is the default setting, changeable via the X options screen or "maxiter=" parameter). All the surrounding "contours" of other colors represent points for which the magnitude of Z exceeds 2 after 149 iterations (the contour closest to the M-set itself), 148 iterations, (the next one out), and so on.

We actually don’t test for the magnitude of Z exceeding 2 - we test the magnitude of Z squared against 4 instead because it is easier. This value (FOUR usually) is known as the "bailout" value for the calculation, because we stop iterating for the point when it is reached. The bailout value can be changed on the Z options screen but the default is usually best. See also Bailout Test.

Some features of interest:

(type=julia)

These sets were named for mathematician Gaston Julia, and can be generated by a simple change in the iteration process described for the Mandelbrot Set. Start with a specified value of C, "C-real + i * C- imaginary"; use as the initial value of Z "x-coordinate + i * y- coordinate"; and repeat the same iteration, Z(n+1) = Z(n)^2 + C. There is a Julia set corresponding to every point on the complex plane — an infinite number of Julia sets. But the most visually interesting tend to be found for the same C values where the M-set image is busiest, i.e. points just outside the boundary. Go too far inside, and the corresponding Julia set is a circle; go too far outside, and it breaks up into scattered points. In fact, all Julia sets for C within the M- set share the "connected" property of the M-set, and all those for C outside lack it.

Id’s spacebar toggle lets you "flip" between any view of the M-set and the Julia set for the point C at the center of that screen. You can then toggle back, or zoom your way into the Julia set for a while and then return to the M-set. So if the infinite complexity of the M-set palls, remember: each of its infinite points opens up a whole new Julia set.

Historically, the Julia sets came first: it was while looking at the M- set as an "index" of all the Julia sets' origins that Mandelbrot noticed its properties.

The relationship between the Mandelbrot set and Julia set can hold between other sets as well. Many of Id’s types are "Mandelbrot/Julia" pairs — sometimes called "M-sets" or "J-sets". All these are generated by equations that are of the form z(k+1) = f(z(k),c), where the function orbit is the sequence z(0), z(1), …​, and the variable c is a complex parameter of the equation. The value c is fixed for "Julia" sets and is equal to the first two parameters entered with the "params=Creal/Cimag" command. The initial orbit value z(0) is the complex number corresponding to the screen pixel. For Mandelbrot sets, the parameter c is the complex number corresponding to the screen pixel. The value z(0) is c plus a perturbation equal to the values of the first two parameters. See the discussion of Mandellambda Sets. This approach may or may not be the "standard" way to create "Mandelbrot" sets out of "Julia" sets.

Some equations have additional parameters. These values are entered as the third or fourth params= value for both Julia and Mandelbrot sets. The variables x and y refer to the real and imaginary parts of z; similarly, cx and cy are the real and imaginary parts of the parameter c and fx(z) and fy(z) are the real and imaginary parts of f(z). The variable c is sometimes called lambda for historical reasons.

The spacebar toggle has been enhanced for the classic Mandelbrot and Julia types. When viewing the Mandelbrot, the spacebar turns on a window mode that displays the Inverse Julia corresponding to the cursor position in a window. Pressing the spacebar then causes the regular Julia escape time fractal corresponding to the cursor position to be generated. The following keys take effect in Inverse Julia mode. Space Generate the escape-time Julia Set corresponding to the cursor position. Only works if fractal is a "Mandelbrot" type. N Numbers toggle - shows coordinates of the cursor on the screen. Press N again to turn off numbers. P Enter new pixel coordinates directly H Hide fractal toggle. Works only if View Windows is turned on and set for a small window (such as the default size.) Hides the fractal, allowing the orbit to take up the whole screen. Press H again to uncover the fractal. S Saves the fractal, cursor, orbits, and numbers. < or , Zoom inverse julia image smaller. > or . Zoom inverse julia image larger. Z Restore default zoom.

The Julia Inverse window is only implemented for the classic Mandelbrot (type=mandel). For other "Mandelbrot" types Space turns on the cursor without the Julia window, and allows you to select coordinates of the matching Julia set.

(type=julia_inverse)

Pick a function, such as the familiar Z(n) = Z(n-1) squared plus C (the defining function of the Mandelbrot Set). If you pick a point Z(0) at random from the complex plane, and repeatedly apply the function to it, you get a sequence of new points called an orbit, which usually either zips out toward infinity or zooms in toward one or more "attractor" points near the middle of the plane. The set of all points that are "attracted" to infinity is called the "basin of attraction" of infinity. Each of the other attractors also has its own basin of attraction. Why is it called a basin? Imagine a lake, and all the water in it "draining" into the attractor. The boundary between these basins is called the Julia Set of the function.

The boundary between the basins of attraction is sort of like a repeller; all orbits move away from it, toward one of the attractors. But if we define a new function as the inverse of the old one, as for instance Z(n) = sqrt(Z(n-1) minus C), then the old attractors become repellers, and the former boundary itself becomes the attractor! Now, starting from any point, all orbits are drawn irresistibly to the Julia Set! In fact, once an orbit reaches the boundary, it will continue to hop about until it traces the entire Julia Set! This method for drawing Julia Sets is called the Inverse Iteration Method, or IIM for short.

Unfortunately, some parts of each Julia Set boundary are far more attractive to inverse orbits than others are, so that as an orbit traces out the set, it keeps coming back to these attractive parts again and again, only occasionally visiting the less attractive parts. Thus it may take an infinite length of time to draw the entire set. To hasten the process, we can keep track of how many times each pixel on our computer screen is visited by an orbit, and whenever an orbit reaches a pixel that has already been visited more than a certain number of times, we can consider that orbit finished and move on to another one. This "hit limit" thus becomes similar to the iteration limit used in the traditional escape-time fractal algorithm. This is called the Modified Inverse Iteration Method, or MIIM, and is much faster than the IIM.

Now, the inverse of Mandelbrot’s classic function is a square root, and the square root actually has two solutions; one positive, one negative. Therefore at each step of each orbit of the inverse function there is a decision; whether to use the positive or the negative square root. Each one gives rise to a new point on the Julia Set, so each is a good choice. This series of choices defines a binary decision tree, each point on the Julia Set giving rise to two potential child points. There are many interesting ways to traverse a binary tree, among them breadth first, depth first (left or negative first), depth first (right or positive first), and completely at random. It turns out that most traversal methods lead to the same or similar pictures, but that how the image evolves as the orbits trace it out differs wildly depending on the traversal method chosen. As far as we know, this fact is an original discovery by Michael Snyder, andversion 18.2 of Id’s ancestor, Fractint, was its first publication.

Pick a Julia constant such as Z(0) = (-.74543, .11301), the popular Seahorse Julia, and try drawing it first breadth first, then depth first (right first), depth first (left first), and finally with random walk.

Caveats: the video memory is used in the algorithm, to keep track of how many times each pixel has been visited (by changing it’s color). Therefore the algorithm will not work well if you zoom in far enough that part of the Julia Set is off the screen.

This method has the limitation that it does not work with disk video modes and it is not resumable.

The J key toggles between the inverse Julia orbit and the corresponding Julia escape time fractal.

(type=newtbasin)

The Newton formula is an algorithm used to find the roots of polynomial equations by successive "guesses" that converge on the correct value as you feed the results of each approximation back into the formula. It works very well — unless you are unlucky enough to pick a value that is on a line between two actual roots. In that case, the sequence explodes into chaos, with results that diverge more and more wildly as you continue the iteration.

This fractal type shows the results for the polynomial Z^n - 1, which has n roots in the complex plane. Use the Type command and enter "newtbasin" in response to the prompt. You will be asked for a parameter, the "order" of the equation (an integer from 3 through 10 — 3 for x^3-1, 7 for x^7-1, etc.). A second parameter is a flag to turn on alternating shades showing changes in the number of iterations needed to attract an orbit. Some people like stripes and some don’t, as always, Id gives you a choice!

The coloring of the plot shows the "basins of attraction" for each root of the polynomial — i.e., an initial guess within any area of a given color would lead you to one of the roots. As you can see, things get a bit weird along certain radial lines or "spokes", those being the lines between actual roots. By "weird", we mean infinitely complex in the good old fractal sense. Zoom in and see for yourself.

This fractal type is symmetric about the origin, with the number of "spokes" depending on the order you select.

(type=newton)

The generating formula here is identical to that for newtbasin, but the coloring scheme is different. Pixels are colored not according to the root that would be "converged on" if you started using Newton’s formula from that point, but according to the iteration when the value is close to a root. For example, if the calculations for a particular pixel converge to the 7th root on the 23rd iteration, newtbasin will color that pixel using color #7, but newton will color it using color #23.

If you have a 256-color mode, use it: the effects can be much livelier than those you get with type=newtbasin, and color cycling becomes, like, downright cosmic. If your "corners" choice is symmetrical, Id exploits the symmetry for faster display.

The applicable "params=" values are the same as newtbasin. Try "params=4." Other values are 3 through 10. 8 has twice the symmetry and is faster.

(type=complexnewton/complexbasin)

Well, hey, "Z^n - 1" is so boring when you can use "Z^a - b" where "a" and "b" are complex numbers! The new "complexnewton" and "complexbasin" fractal types are just the old "newton" and "newtbasin" fractal types with this little added twist. When you select these fractal types, you are prompted for four values (the real and imaginary portions of "a" and "b"). If "a" has a complex portion, the fractal has a discontinuity along the negative axis - relax, we finally figured out that it’s supposed to be there!

(type=lambda)

This type calculates the Julia set of the formula lambda*Z*(1-Z). That is, the value Z[0] is initialized with the value corresponding to each pixel position, and the formula iterated. The pixel is colored according to the iteration when the sum of the squares of the real and imaginary parts exceeds 4.

Two parameters, the real and imaginary parts of lambda, are required. Try 0 and 1 to see the classical fractal "dragon". Then try 0.2 and 1 for a lot more detail to zoom in on.

It turns out that all quadratic Julia-type sets can be calculated using just the formula z^2+c (the "classic" Julia"), so that this type is redundant, but we include it for reason of it’s prominence in the history of fractals.

(type=mandellambda)

This type is the "Mandelbrot equivalent" of the lambda set. A comment is in order here. Almost all the Id "Mandelbrot" sets are created from orbits generated using formulas like z(n+1) = f(z(n),C), with z(0) and C initialized to the complex value corresponding to the current pixel. Our reasoning was that "Mandelbrots" are maps of the corresponding "Julias". Using this scheme each pixel of a "Mandelbrot" is colored the same as the Julia set corresponding to that pixel. However, Kevin Allen informs us that the mandellambda set appears in the literature with z(0) initialized to a critical point (a point where the derivative of the formula is zero), which in this case happens to be the point (.5,0). Since Kevin knows more about Dr. Mandelbrot than we do, and Dr. Mandelbrot knows more about fractals than we do, we defer! Id calculates mandelambda Dr. Mandelbrot’s way instead of our way. But all the other "Mandelbrot" sets in Id are still calculated our way! (Fortunately for us, for the classic Mandelbrot Set these two methods are the same!)

Well now, folks, apart from questions of faithfulness to fractals named in the literature (which we do take seriously!), if a formula makes a beautiful fractal, it is not wrong. In fact some of the best fractals in Id are the results of mistakes! Nevertheless, thanks to Kevin for keeping us accurate!

(See description of "initorbit=" command in Image Calculation Parameters for a way to experiment with different orbit intializations).

(type=circle)

This fractal types is from A. K. Dewdney’s "Computer Recreations" column in "Scientific American". It is attributed to John Connett of the University of Minnesota.

(Don’t tell anyone, but this fractal type is not really a fractal!) Fascinating Moire patterns can be formed by calculating x^2 + y^2 for each pixel in a piece of the complex plane. After multiplication by a magnification factor (the parameter), the number is truncated to an integer and mapped to a color via color = value modulo (number of colors). That is, the integer is divided by the number of colors, and the remainder is the color index value used. The resulting image is not a fractal because all detail is lost after zooming in too far. Try it with different resolution video modes - the results may surprise you!

If inside=startrail is used, it will automatically be set to inside=norm by Id. This is because type circle and inside=startrail locks up Id.

(type=plasma)

Plasma clouds are real live fractals, even though we didn’t know it at first. They are generated by a recursive algorithm that randomly picks colors of the corner of a rectangle, and then continues recursively quartering previous rectangles. Random colors are averaged with those of the outer rectangles so that small neighborhoods do not show much change, for a smoothed-out, cloud-like effect. The more colors your video mode supports, the better. The result, believe it or not, is a fractal landscape viewed as a contour map, with colors indicating constant elevation. To see this, save and view with the 3 command (see "3D" Images) and your "cloud" will be converted to a mountain!

You’ve got to try color cycling on these (hit "+" or "-"). If you haven’t been hypnotized by the drawing process, the writhing colors will do it for sure. We have now implemented subliminal messages to exploit the user’s vulnerable state; their content varies with your bank balance, politics, gender, accessibility to a Id programmer, and so on. A free copy of "The Millionaire Next Door" to the first person who spots them!

This type accepts four parameters.

The first determines how abruptly the colors change. A value of .5 yields bland clouds, while 50 yields very grainy ones. The default value is 2.

The second determines whether to use the original algorithm (0) or a modified one (1). The new one gives the same type of images but draws the dots in a different order. It will let you see what the final image will look like much sooner than the old one.

The third determines whether to use a new seed for generating the next plasma cloud (0) or to use the previous seed (1).

The fourth parameter turns on 16-bit .POT output which provides much smoother height gradations. This is especially useful for creating mountain landscapes when using the plasma output with a ray tracer such as POV-Ray. With parameter three set to 1, the next plasma cloud generated will be identical to the previous but at whatever new resolution is desired.

Zooming is ignored, as each plasma-cloud screen is generated randomly.

The random number seed used for each plasma image is displayed on the Tab information screen, and can be entered with the command line parameter "rseed=" to recreate a particular image.

The algorithm is based on the Pascal program distributed by Bret Mulvey. We have ported it to C and integrated it with Id’s graphics and animation facilities. This implementation does not use floating-point math. The algorithm was modified so that the plasma effect is independent of screen resolution.

Saved plasma-cloud screens are excellent starting images for fractal "landscapes" created with the "3D" Commands.

(type=lambdafn)

Function=[sin|cos|sinh|cosh|exp|log|sqr|…​]) is specified with this type. In the following description, we will use the shorthand "lambdasine" for "lambdafn with function=sin".

These types calculate the Julia set of the formula lambda*fn(Z), for various values of the function "fn", where lambda and Z are both complex. Two values, the real and imaginary parts of lambda, should be given in the "params=" option. For the feathery, nested spirals of LambdaSines and the frost-on-glass patterns of LambdaCosines, make the real part = 1, and try values for the imaginary part ranging from 0.1 to 0.4 (hint: values near 0.4 have the best patterns). In these ranges the Julia set "explodes". For the tongues and blobs of LambdaExponents, try a real part of 0.379 and an imaginary part of 0.479.

Each LambdaSine/Cosine iteration calculates a hyperbolic sine, hyperbolic cosine, a sine, and a cosine (the LambdaExponent iteration "only" requires an exponent, sine, and cosine operation)! However, Id can compute these transcendental functions with fast integer math. In a few cases the fast math is less accurate, so floating point code is used. To use the floating-point code exclusively, use the float=yes parameter or the X options screen.

(type=mandelfn)

Function=[sin|cos|sinh|cosh|exp|log|sqr|…​]) is specified with this type.

These are "pseudo-Mandelbrot" mappings for the LambdaFn Julia functions. They map to their corresponding Julia sets via the spacebar command in exactly the same fashion as the original M/J sets. In general, they are interesting mainly because of that property (the function=exp set in particular is rather boring). Generate the appropriate "Mandelfn" set, zoom on a likely spot where the colors are changing rapidly, and hit the spacebar key to plot the Julia set for that particular point.

Try "type=mandelfn corners=4.68/4.76/-.03/.03 function=cos" with the G command for a graphic demonstration that we’re not taking Mandelbrot’s name in vain here. We didn’t even know these little buggers were here until Mark Peterson found them!

(type=barnsleym1/…​/j3)

Michael Barnsley has written a fascinating college-level text, "Fractals Everywhere", on fractal geometry and its graphic applications. (See Bibliography.) In it, he applies the principle of the M and J sets to more general functions of two complex variables.

We have incorporated three of Barnsley’s examples in Id. Their appearance suggests polarized-light microphotographs of minerals, with patterns that are less organic and more crystalline than those of the M/J sets. Each example has both a "Mandelbrot" and a "Julia" type. Toggle between them using the spacebar.

The parameters have the same meaning as they do for the "regular" Mandelbrot and Julia. For types M1, M2, and M3, they are used to "warp" the image by setting the initial value of Z. For the types J1 through J3, they are the values of C in the generating formulas.

Be sure to try the Orbit function while plotting these types.

(type=ifs)

One of the most remarkable spin-offs of fractal geometry is the ability to "encode" realistic images in very small sets of numbers — parameters for a set of functions that map a region of two-dimensional space onto itself. In principle (and increasingly in practice), a scene of any level of complexity and detail can be stored as a handful of numbers, achieving amazing "compression" ratios…​ how about an image of a forest, more than 300,000 pixels at eight bits apiece, from a 1-KB "seed" file?

Again, Michael Barnsley and his co-workers at the Georgia Institute of Technology are to be thanked for pushing the development of these iterated function systems (IFS).

When you select this fractal type, Id scans the current IFS file (default is id.ifs, a set of definitions supplied with Id) for IFS definitions, then prompts you for the IFS name you wish to run. Fern and 3dfern are good ones to start with. You can press F6 at the selection screen if you want to select a different .IFS file you’ve written.

Note that some Barnsley IFS values generate images quite a bit smaller than the initial (default) screen. Just bring up the zoom box, center it on the small image, and hit Enter to get a full-screen image.

To change the number of dots Id generates for an IFS image before stopping, you can change the "maximum iterations" parameter on the X options screen.

Id supports two types of IFS images: 2D and 3D. In order to fully appreciate 3D IFS images, since your monitor is presumably 2D, we have added rotation, translation, and perspective capabilities. These share values with the same variables used in Id’s other 3D facilities; for their meaning see Rectangular Coordinate Transformation. You can enter these values from the command line using:

rotation=xrot/yrot/zrot (try 30/30/30) shift=xshift/yshift (shifts before applying perspective!) perspective=viewerposition (try 200)

Alternatively, entering I from main screen will allow you to modify these values. The defaults are the same as for regular 3D, and are not always optimum for 3D IFS. With the 3dfern IFS type, try rotation=30/30/30. Note that applying shift when using perspective changes the picture — your "point of view" is moved.

A truly wild variation of 3D may be seen by entering "2" for the stereo mode (see Stereo 3D Viewing), putting on red/blue "funny glasses", and watching the fern develop with full depth perception right there before your eyes!

This feature used to be dedicated to Bruce Goren, as a bribe to get him to send us more knockout stereo slides of 3D ferns, now that we have made it so easy! Bruce, what have you done for us LATELY?? (Just kidding, really!)

Each line in an IFS definition (look at id.ifs with your editor for examples) contains the parameters for one of the generating functions, e.g. in fern: a b c d e f p _ 0 0 0 .16 0 0 .01 .85 .04 -.04 .85 0 1.6 .85 .2 -.26 .23 .22 0 1.6 .07 -.15 .28 .26 .24 0 .44 .07

The values on each line define a matrix, vector, and probability: matrix vector prob |a b| |e| p |c d| |f|

The "p" values are the probabilities assigned to each function (how often it is used), which add up to one. Id supports up to 32 functions, although usually three or four are enough. 3D IFS definitions are a bit different. The name is followed by (3D) in the definition file, and each line of the definition contains 13 numbers: a b c d e f g h i j k l p, defining: matrix vector prob |a b c| |j| p |d e f| |k| |g h i| |l|

You can save the points in your IFS fractal in the file orbits.raw which is overwritten each time a fractal is generated.

(type=sierpinski)

Another pre-Mandelbrot classic, this one found by W. Sierpinski around World War I. It is generated by dividing a triangle into four congruent smaller triangles, doing the same to each of them, and so on, yea, even unto infinity. (Notice how hard we try to avoid reiterating "iterating"?)

If you think of the interior triangles as "holes", they occupy more and more of the total area, while the "solid" portion becomes as hopelessly fragile as that gasket you had to remove without damaging it — you remember, that Sunday afternoon when all the parts stores were closed? There’s a three-dimensional equivalent using nested tetrahedrons instead of triangles, but it generates too much pyramid power to be safely unleashed yet.

There are no parameters for this type. We were able to implement it with integer math routines, so it runs fairly quickly.

(type=mandel4/julia4)

These fractal types are the moral equivalent of the original M and J sets, except that they use the formula Z(n+1) = Z(n)^4 + C, which adds additional pseudo-symmetries to the plots. The "Mandel4" set maps to the "Julia4" set via — surprise! — the spacebar toggle. The M4 set is kind of boring at first (the area between the "inside" and the "outside" of the set is pretty thin, and it tends to take a few zooms to get to any interesting sections), but it looks nice once you get there. The Julia sets look nice right from the start.

Other powers, like Z(n)^3 or Z(n)^7, work in exactly the same fashion. We used this one only because we’re lazy, and Z(n)^4 = (Z(n)²⁾2.

(type=manfn+zsqrd/julfn+zsqrd, manzpower/julzpower, manzzpwr/julzzpwr, manfn+exp/julfn+exp)

These types have been explored by Clifford A. Pickover, of the IBM Thomas J. Watson Research center. As implemented in Id, they are regular Mandelbrot/Julia set pairs that may be plotted with or without the "biomorph" option Pickover used to create organic-looking beasties (see below).

These types are produced with formulas built from the functions z^z, z^n, sin(z), and e^z for complex z. Types with "power" or "pwr" in their name have an exponent value as a third parameter. For example, type=manzpower params=0/0/2 is our old friend the classical Mandelbrot, and type=manzpower params=0/0/4 is the Quartic Mandelbrot. Other values of the exponent give still other fractals. Since these were the original "biomorph" types, we should give an example. Try:

to see a big biomorph digesting little biomorphs!

(type=popcorn/popcornjul)

Here is another Pickover idea. This one computes and plots the orbits of the dynamic system defined by:

In the original the functions were: sin, tan, sin, tan, and C was 3.

The initializers x(0) and y(0) equal to all the complex values within the "corners" values, and h=.01. All these orbits are superimposed, resulting in "popcorn" effect. You may want to use a maxiter value less than normal - Pickover recommends a value of 50. Although you can zoom and rotate popcorn, the results may not be what you’d expect, due to the superimposing of orbits and arbitrary use of color. The orbits frequently occur outside of the screen boundaries. To view the fractal in its entirety, set the preview display to "yes" using the V command.

As a bonus, type=popcornjul shows the Julia set generated by these same equations with the usual escape-time coloring. Turn on orbit viewing with the O command, and as you watch the orbit pattern you may get some insight as to where the popcorn comes from.

(type=marksmandel, marksjulia, cmplxmarksmand, cmplxmarksjul, marksmandelpwr, tim’s_error)

These fractal types are contributions of Mark Peterson. MarksMandel and MarksJulia are two families of fractal types that are linked in the same manner as the classic Mandelbrot/Julia sets: each MarksMandel set can be considered as a mapping into the MarksJulia sets, and is linked with the spacebar toggle. The basic equation for these sets is: Z(n+1) = (lambda^(exp-1) * Z(n)^2) + lambda where Z(0) = 0.0 and lambda is (x + iy) for MarksMandel. For MarksJulia, Z(0) = (x + iy) and lambda is a constant (taken from the MarksMandel spacebar toggle, if that method is used). The exponent is a positive integer or a complex number. We call these "families" because each value of the exponent yields a different MarksMandel set, which turns out to be a kinda-polygon with (exponent) sides. The exponent value is the third parameter, after the "initialization warping" values. Typically one would use null warping values, and specify the exponent with something like "params=0/0/5", which creates an unwarped, pentagonal MarksMandel set.

In the process of coding MarksMandelPwr formula type, Tim Wegner created the type "tim’s_error" after making an interesting coding mistake.

(type=unity)

This Peterson variation began with curiosity about other "Newton-style" approximation processes. A simple one,

produces the fractal called Unity.

One of its interesting features is the "ghost lines." The iteration loop bails out when it reaches the number 1 to within the resolution of a screen pixel. When you zoom a section of the image, the bailout criterion is adjusted, causing some lines to become thinner and others thicker.

Only one line in Unity that forms a perfect circle: the one at a radius of 1 from the origin. This line is actually infinitely thin. Zooming on it reveals only a thinner line, up (down?) to the limit of accuracy for the algorithm. The same thing happens with other lines in the fractal, such as those around |x| = |y| = (1/2)^(1/2) = .7071

Try some other tortuous approximations using the Test Stub and let us know what you come up with!

(type=fn(z*z), fn*fn, fn*z+z, fn+fn, fn+fn(pix), sqr(1/fn), sqr(fn), spider, tetrate, manowar)

Two of Id’s faithful users went bonkers when we introduced the "formula" type, and came up with all kinds of variations on escape-time fractals using trig functions. We decided to put them in as regular types, but there were just too many! So we defined the types with variable functions and let you, the overwhelmed user, specify what the functions should be! Thus Scott Taylor’s "z = sin(z) + z^2" formula type is now the "fn+fn" regular type, and EITHER function can be one of sin, cos, tan, cotan, sinh, cosh, tanh, cotanh, exp, log, sqr, recip, ident, zero, one, conj, flip, cosxx, asin, asinh, acos, acosh, atan, atanh, sqrt, abs, or cabs.

Plus we give you 4 parameters to set, the complex coefficients of the two functions! Thus the innocent-looking "fn+fn" type is really 729 different types in disguise, not counting the damage done by the parameters!

Lee informs us that you should not judge fractals by their "outer" appearance. For example, the images produced by z = sin(z) + z^2 and z = sin(z) - z^2 look very similar, but are different when you zoom in.

(type=kamtorus, kamtorus3d)

This type is created by superimposing orbits generated by a set of equations, with a variable incremented each time.

After each orbit, 'orbit' is incremented by a step size. The parameters are angle "a", step size for incrementing 'orbit', stop value for 'orbit', and points per orbit. Try this with a stop value of 5 with sound=x for some weird fractal music (ok, ok, fractal noise)! You will also see the KAM Torus head into some chaotic territory that Scott Taylor wanted to hide from you by setting the defaults the way he did, but now we have revealed all!

The 3D variant is created by treating 'orbit' as the z coordinate.

With both variants, you can adjust the "maxiter" value (X options screen or parameter maxiter=) to change the number of orbits plotted.

If you’re wondering where KAM comes from in the name of this fractal, it comes from the Kolmogorov-Arnold-Moser theorem. This theorem is a result in dynamical systems about the persistence of quasiperiodic motions under small perturbations. The problem is whether or not a small perturbation of a conservative dynamical system results in a lasting quasiperiodic orbit. The original breakthrough to this problem was given by Andrey Kolmogorov in 1954. This was rigorously proved and extended by Jurgen Moser in 1962 (for smooth twist maps) and Vladimir Arnold in 1963 (for analytic Hamiltonian systems), and the general result is known as the KAM theorem. Quasiperiodic orbits are more affectionatly known as chaotic orbits! (Thanks, Wikipedia!)

(type=bifxxx)

The wonder of fractal geometry is that such complex forms can arise from such simple generating processes. A parallel surprise has emerged in the study of dynamical systems: that simple, deterministic equations can yield chaotic behavior, in which the system never settles down to a steady state or even a periodic loop. Often such systems behave normally up to a certain level of some controlling parameter, then go through a transition in which there are two possible solutions, then four, and finally a chaotic array of possibilities.

This emerged many years ago in biological models of population growth. Consider a (highly over-simplified) model in which the rate of growth is partly a function of the size of the current population:

New Population = Growth Rate * Old Population * (1 - Old Population)

where population is normalized to be between 0 and 1. At growth rates less than 200 percent, this model is stable: for any starting value, after several generations the population settles down to a stable level. But for rates over 200 percent, the equation’s curve splits or "bifurcates" into two discrete solutions, then four, and soon becomes chaotic.

Type=bifurcation illustrates this model. (Although it’s now considered a poor one for real populations, it helped get people thinking about chaotic systems.) The horizontal axis represents growth rates, from 190 percent (far left) to 400 percent; the vertical axis normalized population values, from 0 to 4/3. Notice that within the chaotic region, there are narrow bands where there is a small, odd number of stable values. It turns out that the geometry of this branching is fractal; zoom in where changing pixel colors look suspicious, and see for yourself.

Three parameters apply to bifurcations: Filter Cycles, Seed Population, and Function or Beta.

Filter Cycles (default 1000) is the number of iterations to be done before plotting maxiter population values. This gives the iteration time to settle into the characteristic patterns that constitute the bifurcation diagram, and results in a clean-looking plot. However, using lower values produces interesting results too. Set Filter Cycles to 1 for an unfiltered map.

Seed Population (default 0.66) is the initial population value from which all others are calculated. For filtered maps the final image is independent of Seed Population value in the valid range (0.0 < Seed Population < 1.0). Seed Population becomes effective in unfiltered maps - try setting Filter Cycles to 1 (unfiltered) and Seed Population to 0.001 ("params=1/.001" on the command line). This results in a map overlaid with nice curves. Each Seed Population value results in a different set of curves.

Function (default "ident") is the function applied to the old population before the new population is determined. The "ident" function calculates the same bifurcation fractal that was generated before these formulae were generalized.

Beta is used in the bifmay bifurcations and is the power to which the denominator is raised.

Note that Id normally uses periodicity checking to speed up bifurcation computation. However, in some cases a better quality image will be obtained if you turn off periodicity checking with "periodicity=no"; for instance, if you use a high number of iterations and a smooth colormap.

Many formulae can be used to produce bifurcations. Mitchel Feigenbaum studied lots of bifurcations in the mid-70’s, using a HP-65 calculator (Personal computers, fractals, and Id, were all science fiction then!). He studied where bifurcations occurred, for the formula r*p*(1-p), the one described above. He found that the ratios of lengths of adjacent areas of bifurcation were four and a bit. These ratios vary, but, as the growth rate increases, they tend to a limit of 4.669+. This helped him guess where bifurcation points would be, and saved lots of time.

When he studied bifurcations of r*sin(PI*p), he found a similar pattern, which is not surprising in itself. However, 4.669+ popped out, again. Different formulae, same number? Now, that’s surprising! He tried many other formulae and always got 4.669+ - Hot Damn!!! So hot, in fact, that he phoned home and told his mom it would make him famous! He also went on to tell other scientists. The rest is history…​

(It has been conjectured that if Feigenbaum had a copy of Id, and used it to study bifurcations, he may never have found his number, as it only became obvious from long perusal of hand-written lists of values, without the distraction of wild color-cycling effects!). We now know that this number is as universal as pi or e, the base of the natural logarithm. It appears in situations ranging from fluid-flow turbulence, electronic oscillators, chemical reactions, and even the Mandelbrot Set - yup, fraid so: "budding" of the Mandelbrot Set along the negative real axis occurs at intervals determined by Feigenbaum’s constant, 4.669201660910…​..

Id does not make direct use of the Feigenbaum constant (yet!). However, it does now reflect the fact that there is a whole sub-species of bifurcation-type fractals. Those implemented to date, and the related formulae, (writing P for pop[n+1] and p for pop[n]) are :

It took a while for bifurcations to appear here, despite them being over a century old, and intimately related to chaotic systems. However, they are now truly alive and well in Id!

Orbit fractals are generated by plotting an orbit path in two or three dimensional space.

See Lorenz Attractors, Rossler Attractors, Henon Attractors, Pickover Attractors, Gingerbreadman, and Martin Attractors.

The orbit trajectory for these types can be saved in the file orbits.raw by invoking Id with the "orbitsave=yes" command-line option. This file will be overwritten each time you generate a new fractal, so rename it if you want to save it.

(type=lorenz/lorenz3d)

The "Lorenz attractor" is a "simple" set of three deterministic equations developed by Edward Lorenz while studying the non- repeatability of weather patterns. The weather forecaster’s basic problem is that even very tiny changes in initial patterns ("the beating of a butterfly’s wings" - the official term is "sensitive dependence on initial conditions") eventually reduces the best weather forecast to rubble.

The Lorenz attractor is the plot of the orbit of a dynamic system consisting of three first order non-linear differential equations. The solution to the differential equation is vector-valued function of one variable. If you think of the variable as time, the solution traces an orbit. The orbit is made up of two spirals at an angle to each other in three dimensions. We change the orbit color as time goes on to add a little dazzle to the image. The equations are:

We solve these differential equations approximately using a method known as the first order taylor series. Calculus teachers everywhere will kill us for saying this, but you treat the notation for the derivative dx/dt as though it really is a fraction, with "dx" the small change in x that happens when the time changes "dt". So multiply through the above equations by dt, and you will have the change in the orbit for a small time step. We add these changes to the old vector to get the new vector after one step. This gives us:

We connect the successive points with a line, project the resulting 3D orbit onto the screen, and voila! The Lorenz attractor!

We have added two versions of the Lorenz attractor. "Type=lorenz" is the Lorenz attractor as seen in everyday 2D. "Type=lorenz3d" is the same set of equations with the added twist that the results are run through our perspective 3D routines, so that you get to view it from different angles (you can modify your perspective "on the fly" by using the I command.) If you set the "stereo" option to "2", and have red/blue funny glasses on, you will see the attractor orbit with depth perception.

Hint: the default perspective values (x = 60, y = 30, z = 0) aren’t the best ones to use for fun Lorenz attractor viewing. Experiment a bit - start with rotation values of 0/0/0 and then change to 20/0/0 and 40/0/0 to see the attractor from different angles.- and while you’re at it, use a non-zero perspective point. Try 100 and see what happens when you get inside the Lorenz orbits. Here comes one - Duck! While you are at it, turn on the sound with the "X". This way you’ll at least hear it coming!

Different Lorenz attractors can be created using different parameters. Four parameters are used. The first is the time-step (dt). The default value is .02. A smaller value makes the plotting go slower; a larger value is faster but rougher. A line is drawn to connect successive orbit values. The 2nd, third, and fourth parameters are coefficients used in the differential equation (a, b, and c). The default values are 5, 15, and 1. Try changing these a little at a time to see the result.

(type=rossler3d)

This fractal is named after the German Otto Rossler, a non-practicing medical doctor who approached chaos with a bemusedly philosophical attitude. He would see strange attractors as philosophical objects. His fractal namesake looks like a band of ribbon with a fold in it. All we can say is we used the same calculus-teacher-defeating trick of multiplying the equations by "dt" to solve the differential equation and generate the orbit. This time we will skip straight to the orbit generator - if you followed what we did above with type Lorenz you can easily reverse engineer the differential equations.

Default parameters are dt = .04, a = .2, b = .2, c = 5.7

(type=henon)

Michel Henon was an astronomer at Nice observatory in southern France. He came to the subject of fractals via investigations of the orbits of astronomical objects. The strange attractor most often linked with Henon’s name comes not from a differential equation, but from the world of discrete mathematics - difference equations. The Henon map is an example of a very simple dynamic system that exhibits strange behavior. The orbit traces out a characteristic banana shape, but on close inspection, the shape is made up of thicker and thinner parts. Upon magnification, the thicker bands resolve to still other thick and thin components. And so it goes forever! The equations that generate this strange pattern perform the mathematical equivalent of repeated stretching and folding, over and over again.

The default parameters are a=1.4 and b=.3.

(type=pickover)

Clifford A. Pickover of the IBM Thomas J. Watson Research center is such a creative source for fractals that we attach his name to this one only with great trepidation. Probably tomorrow he’ll come up with another one and we’ll be back to square one trying to figure out a name!

This one is the three dimensional orbit defined by: xnew = sin(a*y) - z*cos(b*x) ynew = z*sin(c*x) - cos(d*y) znew = sin(x)

Default parameters are: a = 2.24, b = .43, c = -.65, d = -2.43

(type=gingerbreadman)

This simple fractal is a charming example stolen from "Science of Fractal Images", p. 149.

The initial x and y values are set by parameters, defaults x=-.1, y = 0.

(type=hopalong/martin)

These fractal types are from A. K. Dewdney’s "Computer Recreations" column in "Scientific American". They are attributed to Barry Martin of Aston University in Birmingham, England.

Hopalong is an "orbit" type fractal like lorenz. The image is obtained by iterating this formula after setting z(0) = y(0) = 0: x(n+1) = y(n) - sign(x(n))*sqrt(abs(b*x(n)-c)) y(n+1) = a - x(n) Parameters are a, b, and c. The function "sign()" returns 1 if the argument is positive, -1 if argument is negative.

This fractal continues to develop in surprising ways after many iterations.

Another Martin fractal is simpler. The iterated formula is: x(n+1) = y(n) - sin(x(n)) y(n+1) = a - x(n) The parameter is "a". Try values near the number pi.

Michael Peters has based the HOP program on variations of these Martin types. You will find three of these here: chip, quadruptwo, and threeply.

(type=icon/icon3d)

This fractal type was inspired by the book "Symmetry in Chaos" by Michael Field and Martin Golubitsky (ISBN 0-19-853689-5, Oxford Press). To quote from the book’s jacket,

The icon type implemented here maps the classic population logistic map of bifurcation fractals onto the complex plane in Dn symmetry.

The initial points plotted are the more chaotic initial orbits, but as you wait, delicate webs will begin to form as the orbits settle into a more periodic pattern. Since pixels are colored by the number of times they are hit, the more periodic paths will become clarified with time. These fractals run continuously.

There are 6 parameters: Lambda, Alpha, Beta, Gamma, Omega, and Degree Omega 0 = Dn, or dihedral (rotation + reflectional) symmetry !0 = Zn, or cyclic (rotational) symmetry Degree = n, or Degree of symmetry

(type=test)

This is a stub that we (and you!) use for trying out new fractal types. "Type=test" fractals make use of Id’s structure and features for whatever code is in the routine 'testpt()' (located in the small source file testpt.cpp) to determine the color of a particular pixel.

If you have a favorite fractal type that you believe would fit nicely into Id, just rewrite the function in testpt.cpp (or use the prototype function there, which is a simple M-set implementation) with an algorithm that computes a color based on a point in the complex plane.

After you get it working, send your code as a pull request on our github project and we might just add it to the next release of Id, with full credit to you. Our criteria are: 1) an interesting image and 2) a formula significantly different from types already supported. (Bribery may also work. This author is completely honest, but I don’t trust those other guys.) Be sure to include an explanation of your algorithm and the parameters supported, preferably formatted as you see here to simplify folding it into the documentation.

(type=formula)

This is a "roll-your-own" fractal interpreter - you don’t even need a compiler!

To run a "type=formula" fractal, you first need a text file containing formulas (there’s a sample file - id.frm - included with this distribution). When you select the "formula" fractal type, Id scans the current formula file (default is id.frm) for formulas, then prompts you for the formula name you wish to run. After prompting for any parameters, the formula is parsed for syntax errors and then the fractal is generated. If you want to use a different formula file, press F6 when you are prompted to select a formula name.

There are two command-line options that work with type=formula ("formulafile=" and "formulaname="), useful when you are using this fractal type in batch mode.

The following documentation is supplied by Mark Peterson, who wrote the formula interpreter:

Formula fractals allow you to create your own fractal formulas. The general format is:

Initial conditions are set, then the iterations performed while the bailout criteria remains true or until 'z' turns into a periodic loop. All variables are created automatically by their usage and treated as complex. If you declare 'v = 2' then the variable 'v' is treated as a complex with an imaginary value of zero.

Sequential processing of the formula can be altered with the flow control instructions:

where the expressions are evaluated and the statements executed are those immediately following the first "true" expression (the real part of the complex variable being nonzero). Nesting of if..endif blocks is permitted.

Precedence may be overridden by use of parenthesis. Note the modulus squared operator |z| is also parenthetic and always sets the imaginary component to zero. This means 'c * |z - 4|' first subtracts 4 from z, calculates the modulus squared then multiplies times 'c'. Nested modulus squared operators require overriding parenthesis:

The functions fn1(…​) to fn4(…​) are variable functions - when used, the user is prompted at run time (on the Z screen) to specify one of sin, cos, sinh, cosh, exp, log, sqr, etc. for each required variable function.

Most of the functions have their conventional meaning, here are a few notes on others that are not conventional.

The formulas are performed using either integer or floating point mathematics depending on the F floating point toggle.

The 'rand' predefined variable is changed with each iteration to a new random number with the real and imaginary components containing a value between zero and 1. Use the srand() function to initialize the random numbers to a consistent random number sequence. If a formula does not contain the srand() function, then the formula compiler will use the system time to initialize the sequence. This could cause a different fractal to be generated each time the formula is used depending on how the formula is written.

A formula containing one of the predefined variables "maxit", "scrnpix" or "scrnmax" will be automatically run in floating point mode.

The rounding functions must be used cautiously; formulas that depend on exact values of numbers will not work reliably in all cases. For example, in floating point mode, trunc(6/3) returns 1 while trunc(6/real(3)) returns 2.

Note that if x is an integer, floor(x) = ceil(x) = trunc(x) = round(x) = x.

Remember that when using integer math there is a limited dynamic range, so what you think may be a fractal could really be just a limitation of the integer math range. God may work with integers, but God’s dynamic range is many orders of magnitude greater than our puny 32 bit mathematics! Always verify with the floating point F toggle. The possible values for symmetry are: XAXIS, XAXIS_NOPARM YAXIS, YAXIS_NOPARM XYAXIS, XYAXIS_NOPARM ORIGIN, ORIGIN_NOPARM PI_SYM, PI_SYM_NOPARM XAXIS_NOREAL XAXIS_NOIMAG

These will force the symmetry even if no symmetry is actually present, so try your formulas without symmetry before you use these.

For mathematical formulas of functions used in the parser language, see Trig Identities

(type=julibrot)

The Julibrot fractal type uses a general-purpose renderer for visualizing three dimensional solid fractals. Originally Mark Peterson developed this rendering mechanism to view a 3-D sections of a 4-D structure he called a "Julibrot". This structure, also called "layered Julia set" in the fractal literature, hinges on the relationship between the Mandelbrot and Julia sets. Each Julia set is created using a fixed value c in the iterated formula z^2 + c. The Julibrot is created by layering Julia sets in the x-y plane and continuously varying c, creating new Julia sets as z is incremented. The solid shape thus created is rendered by shading the surface using a brightness inversely proportional to the virtual viewer’s eye.

The Julibrot engine can be used with other Julia formulas besides the classic z^2 + c. The first field on the Julibrot parameter screen lets you select which orbit formula to use.

You can also use the Julibrot renderer to visualize 3D cross sections of true four dimensional Quaternion and Hypercomplex fractals.

The Julibrot Parameter Screens

Orbit Algorithm - select the orbit algorithm to use. The available possibilities include 2-D Julia and both mandelbrot and Julia variants of the 4-D Quaternion and Hypercomplex fractals.

Orbit parameters - the next screen lets you fill in any parameters belonging to the orbit algorithm. This list of parameters is not necessarily the same as the list normally presented for the orbit algorithm, because some of these parameters are used in the Julibrot layering process.

Distance between the eyes - set this to 2.5 if you want a red/blue anaglyph image, 0 for a normal greyscale image.

Number of z pixels - this sets how many layers are rendered in the screen z-axis. Use a higher value with higher resolution video modes.

The remainder of the parameters are needed to construct the red/blue picture so that the fractal appears with the desired depth and proper 'z' location. With the origin set to 8 inches beyond the screen plane and the depth of the fractal at 8 inches the default fractal will appear to start at 4 inches beyond the screen and extend to 12 inches if your eyeballs are 2.5 inches apart and located at a distance of 24 inches from the screen. The screen dimensions provide the reference frame.

(type=diffusion)

Standard diffusion begins with a single point in the center of the screen. Subsequent points move around randomly until coming into contact with a point already on the screen, at which time their locations are fixed and they are drawn. This process repeats until the fractals reaches the edge of the screen. Use the show orbits function to see the points' random motion.

One unfortunate problem is that on a large screen, this process will tend to take eons. To speed things up, the points are restricted to a box around the initial point. The first parameter to diffusion contains the size of the border between the fractal and the edge of the box. If you make this number small, the fractal will look more solid and will be generated more quickly.

The second parameter to diffusion changes the type of growth. If you set it to 1, then the diffusion will start with a line along the bottom of the screen. Points will appear above this line and the fractal will grow upward. For this fractal, the points are restricted to a box which is as wide as the screen but whose distance from the fractal is given by the border size (the first parameter). Initial points are released from a centered segment along the top of this box which has a width equal to twice the border size.

If the second parameter is set to 2, then diffusion begins with a square box on the screen. Points appear on a circle inside the box whose distance from the box is equal to the border size. This fractal grows very slowly since the points are not restricted to a small box.

The third and last parameter for diffusion controls the color of the fractal. If it is set to zero then points are colored randomly. Otherwise, it tells how often to shift the color of the points being deposited. If you set it to 150, for example, then the color of the points will shift every 150 points leading to a radial color pattern if you are using the standards diffusion type.

Diffusion was inspired by a Scientific American article a couple of years back which includes actual pictures of real physical phenomena that behave like this.

Thanks to Adrian Mariano for providing the diffusion code and documentation. Juan J. Buhler added additional options.

(type=magnet1m/…​/magnet2j)

These fractals use formulae derived from the study of hierarchical lattices, in the context of magnetic renormalisation transformations. This kinda stuff is useful in an area of theoretical physics that deals with magnetic phase-transitions (predicting at which temperatures a given substance will be magnetic, or non-magnetic). In an attempt to clarify the results obtained for real temperatures (the kind that you and I can feel), the study moved into the realm of complex numbers, aiming to spot real phase-transitions by finding the intersections of lines representing complex phase-transitions with the real axis. The first people to try this were two physicists called Yang and Lee, who found the situation a bit more complex than first expected, as the phase boundaries for complex temperatures are (surprise!) fractals.

And that’s all the technical (?) background you’re getting here! For more details (are you serious?!) read "The Beauty of Fractals". When you understand it all, you might like to rewrite this section, before you start your new job as a professor of theoretical physics…​

In Id terms, the important bits of the above are "fractals", "complex numbers", "formulae", and "The Beauty of Fractals". Lifting the formulae straight out of the book and iterating them over the complex plane (just like the Mandelbrot set) produces fractals.

The formulae are a bit more complicated than the Z^2+C used for the Mandelbrot set, that’s all. They are :

These aren’t quite as horrific as they look (oh yeah ?!) as they only involve two variables (Z and C), but cubing things, doing division, and eventually squaring the result (all in complex numbers) don’t exactly spell s-p-e-e-d ! These are not the fastest fractals in Id!

As you might expect, for both formulae there is a single related Mandelbrot-type set (magnet1m, magnet2m) and an infinite number of related Julia-type sets (magnet1j, magnet2j), with the usual toggle between the corresponding Ms and Js via the spacebar.

If you fancy delving into the Julia-types by hand, you will be prompted for the real and imaginary parts of the parameter denoted by C. The result is symmetrical about the real axis (and therefore the initial image gets drawn in half the usual time) if you specify a value of zero for the imaginary part of C.

Id historical note: Another complication (besides the formulae) in implementing these fractal types was that they all have a finite attractor (1.0 + 0.0i), as well as the usual one at infinity. This fact spurred the development of finite attractor logic in Id. Without this code you can still generate these fractals, but you usually end up with a pretty boring image that is mostly deep blue "lake", courtesy of Id’s standard Periodicity Logic. See Finite Attractors for more information on this aspect of Id internals.

(Thanks to Kevin Allen for magnetic type documentation above).

(type=lsystem)

In 1968, the Hungarian biologist Aristid Lindenmayer developed a formal language for describing the growth of plant cell structures. Lindenmayer used his formal language to describe the growth patterns of various types of algae. Later, the formal language was used to describe the branching structures of higher plants. The work was popularized among fractal enthusiasts in the book "The Algorithmic Beauty of Plants" (1990), by Przemyslaw Prusinkiewicz and Aristid Lindenmayer. Lindenmayer died in 1989, but his work was continued and extended by Prusinkiewicz whose main work consists of using Lindenmayer grammars to model plant growth.

A Lindenmayer system, or L-system for short, consists of a set of symbols, a grammar, an interpretation scheme for the symbols and an initial string of symbols, called the axiom. The interpretation scheme operates on a string of symbols to create a picture. The grammar says how symbols in the string are replaced in each generation of the system. Starting with the initial string of symbols, the rules of the grammar are applied to all the symbols in the string to produce a new string of symbols. Each application of the grammar rules is called a generation. Well, that’s enough theory!

These fractals are constructed from line segments using rules specified in drawing commands. Starting with an initial string, the axiom, transformation rules are applied a specified number of times, to produce the final command string which is used to draw the image.

Like the type=formula fractals, this type requires a separate data file. A sample file, id.l, is included with this distribution. When you select type lsystem, the current L-system file is read and you are asked for the L-system name you wish to run. Press F6 at this point if you wish to use a different L-system file. After selecting an L-system, you are asked for one parameter - the "order", or number of times to execute all the transformation rules. It is wise to start with small orders, because the size of the substituted command string grows exponentially and it is very easy to exceed your resolution. (Higher orders take longer to generate too.) The command line options "lname=" and "lfile=" can be used to over-ride the default file name and L-system name.

Each L-system entry in the file contains a specification of the angle, the axiom, and the transformation rules. Each item must appear on its own line and each line must be less than 160 characters long.

The statement "angle n" sets the angle to 360/n degrees; n must be an integer greater than two and less than fifty.

"Axiom string" defines the axiom.

Transformation rules are specified as "a=string" and convert the single character 'a' into "string." If more than one rule is specified for a single character all of the strings will be added together. This allows specifying transformations longer than the 160 character limit. Transformation rules may operate on any characters except space, tab or '}'.

Any information after a ; (semi-colon) on a line is treated as a comment.

Here is a sample L-system:

These commands increment angle by the user specified angle value. They should be used when possible because they are fast. If greater flexibility is needed, use the following commands which keep a completely separate angle pointer which is specified in degrees.

Other characters are perfectly legal in command strings. They are ignored for drawing purposes, but can be used to achieve complex translations.

The characters '+', '-', '<', '>', '[', ']', '|', '!', '@', '/', '\', and 'c' are reserved symbols and cannot be redefined. For example, c=f+f and ⇐, are syntax errors.

The integer code produces incorrect results in five known instances, Peano2 with order >= 7, SnowFlake1 with order >=6, and SnowFlake2, SnowFlake3, and SnowflakeColor with order >= 5. If you see strange results, switch to the floating point code.

(type=lyapunov)

The bifurcation fractal illustrates what happens in a simple population model as the growth rate increases. The Lyapunov fractal expands that model into two dimensions by letting the growth rate vary in a periodic fashion between two values. Each pair of growth rates is run through a logistic population model and a value called the Lyapunov exponent is calculated for each pair and is plotted. The Lyapunov exponent is calculated by adding up log | r - 2*r*x| over many cycles of the population model and dividing by the number of cycles. Negative Lyapunov exponents indicate a stable, periodic behavior and are plotted in color. Positive Lyapunov exponents indicate chaos (or a diverging model) and are colored black.

Order parameter: Each possible periodic sequence yields a two dimensional space to explore. The order parameter selects a sequence. The default value 0 represents the sequence ab which alternates between the two values of the growth parameter. On the screen, the a values run vertically and the b values run horizontally. Here is how to calculate the space parameter for any desired sequence. Take your sequence of a’s and b’s and arrange it so that it starts with at least 2 a’s and ends with a b. It may be necessary to rotate the sequence or swap a’s and b’s. Strike the first a and the last b off the list and replace each remaining a with a 1 and each remaining b with a zero. Interpret this as a binary number and convert it into decimal.

An example: I like sonnets. A sonnet is a poem with fourteen lines that has the following rhyming sequence: abba abba abab cc. Ignoring the rhyming couplet at the end, let’s calculate the order parameter for this pattern.

An order parameter of 618 gives the Lyapunov equivalent of a sonnet. "How do I make thee? Let me count the ways…​"

Population Seed: When two parts of a Lyapunov overlap, which spike overlaps which is strongly dependent on the initial value of the population model. Any changes from using a different starting value between 0 and 1 may be subtle. The values 0 and 1 are interpreted in a special manner. A seed of 1 will choose a random number between 0 and 1 at the start of each pixel. A seed of 0 will suppress resetting the seed value between pixels unless the population model diverges in which case a random seed will be used on the next pixel.

Filter Cycles: Like the Bifurcation model, the Lyapunov allow you to set the number of cycles that will be run to allow the model to approach equilibrium before the lyapunov exponent calculation is begun. The default value of 0 uses one half of the iterations before beginning the calculation of the exponent.

Reference: A.K. Dewdney, Mathematical Recreations, Scientific American, Sept. 1991

(type=lambda(fn||fn), manlam(fn||fn), julia(fn||fn), mandel(fn||fn))

Two functions=[sin|cos|sinh|cosh|exp|log|sqr|…​]) are specified with these types. The two functions are alternately used in the calculation based on a comparison between the modulus of the current Z and the shift value. The first function is used if the modulus of Z is less than the shift value and the second function is used otherwise.

The lambda(fn||fn) type calculates the Julia set of the formula lambda*fn(Z), for various values of the function "fn", where lambda and Z are both complex. Two values, the real and imaginary parts of lambda, should be given in the "params=" option. The third value is the shift value. The space bar will generate the corresponding "pseudo Mandelbrot" set, manlam(fn||fn).

The manlam(fn||fn) type calculates the "pseudo Mandelbrot" set of the formula fn(Z)*C, for various values of the function "fn", where C and Z are both complex. Two values, the real and imaginary parts of Z(0), should be given in the "params=" option. The third value is the shift value. The space bar will generate the corresponding julia set, lamda(fn||fn).

The julia(fn||fn) type calculates the Julia set of the formula fn(Z)+C, for various values of the function "fn", where C and Z are both complex. Two values, the real and imaginary parts of C, should be given in the "params=" option. The third value is the shift value. The space bar will generate the corresponding mandelbrot set, mandel(fn||fn).

The mandel(fn||fn) type calculates the Mandelbrot set of the formula fn(Z)+C, for various values of the function "fn", where C and Z are both complex. Two values, the real and imaginary parts of Z(0), should be given in the "params=" option. The third value is the shift value. The space bar will generate the corresponding julia set, julia(fn||fn).

(type=halley)

The Halley map is an algorithm used to find the roots of polynomial equations by successive "guesses" that converge on the correct value as you feed the results of each approximation back into the formula. It works very well — unless you are unlucky enough to pick a value that is on a line between two actual roots. In that case, the sequence explodes into chaos, with results that diverge more and more wildly as you continue the iteration.

This fractal type shows the results for the polynomial Z*(Z^a - 1), which has a+1 roots in the complex plane. Use the Type command and enter "halley" in response to the prompt. You will be asked for a parameter, the "order" of the equation (an integer from 2 through 10 — 2 for Z*(Z^2 - 1), 7 for Z*(Z^7 - 1), etc.). A second parameter is the relaxation coefficient, and is used to control the convergence stability. A number greater than one increases the chaotic behavior and a number less than one decreases the chaotic behavior. The third parameter is the value used to determine when the formula has converged. The test for convergence is ||Z(n+1)|^2 - |Z(n)|^2| < epsilon. This convergence test produces the whisker-like projections which generally point to a root.

(type=dynamic, dynamic2)

These fractals are based on a cyclic system of differential equations: x'(t) = -f(y(t)) y'(t) = f(x(t)) These equations are approximated by using a small time step dt, forming a time-discrete dynamic system: x(n+1) = x(n) - dt*f(y(n)) y(n+1) = y(n) + dt*f(x(n)) The initial values x(0) and y(0) are set to various points in the plane, the dynamic system is iterated, and the resulting orbit points are plotted.

In Id, the function f is restricted to: f(k) = sin(k + a*fn1(b*k)) The parameters are the spacing of the initial points, the time step dt, and the parameters (a,b,fn1) that affect the function f. Normally the orbit points are plotted individually, but for a negative spacing the points are connected.

This fractal is similar to the Pickover Popcorn. A variant is the implicit Euler approximation: y(n+1) = y(n) + dt*f(x(n)) x(n+1) = x(n) - dt*f(y(n+1)) This variant results in complex orbits. The implicit Euler approximation is selected by entering dt < 0.

There are two options that have unusual effects on these fractals. The orbit delay value controls how many initial points are computed before the orbits are displayed on the screen. This allows the orbit to settle down. The outside=summ option causes each pixel to increment color every time an orbit touches it; the resulting display is a 2-d histogram.

These fractals are discussed in Chapter 14 of Pickover’s "Computers, Pattern, Chaos, and Beauty".

(type=mandelcloud)

This fractal computes the Mandelbrot function, but displays it differently. It starts with regularly spaced initial pixels and displays the resulting orbits. This idea is somewhat similar to the Dynamic System.

There are two options that have unusual effects on this fractal. The orbit delay value controls how many initial points are computed before the orbits are displayed on the screen. This allows the orbit to settle down. The outside=summ option causes each pixel to increment color every time an orbit touches it; the resulting display is a 2-d histogram.

This fractal was invented by Noel Giffin.

(type=quat,quatjul)

These fractals are based on quaternions. Quaternions are an extension of complex numbers, with 4 parts instead of 2. That is, a quaternion Q equals a+ib+jc+kd, where a,b,c,d are reals. Quaternions have rules for addition and multiplication. The normal Mandelbrot and Julia formulas can be generalized to use quaternions instead of complex numbers.

There is one complication. Complex numbers have 2 parts, so they can be displayed on a plane. Quaternions have 4 parts, so they require 4 dimensions to view. That is, the quaternion Mandelbrot set is actually a 4-dimensional object. Each quaternion C generates a 4-dimensional Julia set.

One method of displaying the 4-dimensional object is to take a 3- dimensional slice and render the resulting object in 3-dimensional perspective. Id isn’t that sophisticated, so it merely displays a 2- dimensional slice of the resulting object. (Note: Now Id is that sophisticated! See the Julibrot type!)

In Id, for the Julia set, you can specify the four parameters of the quaternion constant: c=(c1,ci,cj,ck), but the 2-dimensional slice of the z-plane Julia set is fixed to (xpixel,ypixel,0,0).

For the Mandelbrot set, you can specify the position of the c-plane slice: (xpixel,ypixel,cj,ck).

These fractals are discussed in Chapter 10 of Pickover’s "Computers, Pattern, Chaos, and Beauty".

See also HyperComplex and Quaternion and Hypercomplex Algebra

(type=hypercomplex,hypercomplexj)

These fractals are based on hypercomplex numbers, which like quaternions are a four dimensional generalization of complex numbers. It is not possible to fully generalize the complex numbers to four dimensions without sacrificing some of the algebraic properties shared by real and complex numbers. Quaternions violate the commutative law of multiplication, which says z1*z2 = z2*z1. Hypercomplex numbers fail the rule that says all non-zero elements have multiplicative inverses - that is, if z is not 0, there should be a number 1/z such that (1/z)*(z) = 1. This law holds most of the time but not all the time for hypercomplex numbers.

However hypercomplex numbers have a wonderful property for fractal purposes. Every function defined for complex numbers has a simple generalization to hypercomplex numbers. Id’s implementation takes advantage of this by using "fn" variables - the iteration formula is h(n+1) = fn(h(n)) + C. where "fn" is the hypercomplex generalization of sin, cos, log, sqr etc. You can see 3D versions of these fractals using fractal type Julibrot. Hypercomplex numbers were brought to our attention by Clyde Davenport, author of "A Hypercomplex Calculus with Applications to Relativity" (ISBN 0-9623837-0-8).

See also Quaternion and Quaternion and Hypercomplex Algebra

(type=cellular)

These fractals are generated by 1-dimensional cellular automata. Consider a 1-dimensional line of cells, where each cell can have the value 0 or 1. In each time step, the new value of a cell is computed from the old value of the cell and the values of its neighbors. On the screen, each horizontal row shows the value of the cells at any one time. The time axis proceeds down the screen, with each row computed from the row above.

Different classes of cellular automata can be described by how many different states a cell can have (k), and how many neighbors on each side are examined (r). Id implements the binary nearest neighbor cellular automata (k=2,r=1), the binary next-nearest neighbor cellular automata (k=2,r=2), and the ternary nearest neighbor cellular automata (k=3,r=1) and several others.

The rules used here determine the next state of a given cell by using the sum of the states in the cell’s neighborhood. The sum of the cells in the neighborhood are mapped by rule to the new value of the cell. For the binary nearest neighbor cellular automata, only the closest neighbor on each side is used. This results in a 4 digit rule controlling the generation of each new line: if each of the cells in the neighborhood is 1, the maximum sum is 1+1+1 = 3 and the sum can range from 0 to 3, or 4 values. This results in a 4 digit rule. For instance, in the rule 1010, starting from the right we have 0→0, 1→1, 2→0, 3→1. If the cell’s neighborhood sums to 2, the new cell value would be 0.

For the next-nearest cellular automata (kr = 22), each pixel is determined from the pixel value and the two neighbors on each side. This results in a 6 digit rule.

For the ternary nearest neighbor cellular automata (kr = 31), each cell can have the value 0, 1, or 2. A single neighbor on each side is examined, resulting in a 7 digit rule.

A zero rule will randomly generate the rule to use.

Hitting the space bar toggles between continuously generating the cellular automata and stopping at the end of the current screen.

Recommended reading: "Computer Software in Science and Mathematics", Stephen Wolfram, Scientific American, September, 1984. "Abstract Mathematical Art", Kenneth E. Perry, BYTE, December, 1986. "The Armchair Universe", A. K. Dewdney, W. H. Freeman and Company, 1988. "Complex Patterns Generated by Next Nearest Neighbors Cellular Automata", Wentian Li, Computers & Graphics, Volume 13, Number 4.

(type=ant)

This fractal type is the generalized ant automaton described in the "Computer Recreations" column of the July 1994 Scientific American. The article attributes this automaton to Greg Turk of Stanford University, Leonid A. Bunivomitch of the Georgia Institute of Technology, and S. E. Troubetzkoy of the University of Bielefeld.

The ant wanders around the screen, starting at the middle. A rule string, which the user can input as Id’s first parameter, determines the ant’s direction. This rule string is stored as a double precision number in our implementation. Only the digit 1 is significant — all other digits are treated as 0. When the type 1 ant leaves a cell (a pixel on the screen) of color k, it turns right if the kth symbol in the rule string is a 1, or left otherwise. Then the color in the abandoned cell is incremented. The type 2 ant uses only the rule string to move around. If the digit of the rule string is a 1, the ant turns right and puts a zero in current cell, otherwise it turns left and put a number in the current cell. An empty rule string causes the rule to be generated randomly.

Id’s 2nd parameter is a maximum iteration to guarantee that the fractal will terminate.

The 3rd parameter is the number of ants (up to 256). If you select 0 ants, then the number of ants is random.

The 4th paramter allows you to select ant type 1 (the original), or type 2.

The 5th parameter determines whether the ant’s progress stops when the edge of the screen is reaches (as in the original implementation), or whether the ant’s path wraps to the opposite side of the screen. You can slow down the ant to see her better using the P screen orbit delay - try 10. The 6th parameter accepts a random seed, allowing you to duplicate images using random values (empty rule string or 0 maximum ants.

Try rule string 10. In this case, the ant moves in a seemingly random pattern, then suddenly marches off in a straight line. This happens for many other rule strings. The default 1100 produces symmetrical images.

If the screen initially contains an image, the path of the ant changes. To try this, generate a fractal, and press Ctrl+A. Note that images seeded with an image are not (yet) reproducible in PAR files. When started using the Ctrl+A keys, after the ant is finished the default fractal type reverts to that of the underlying fractal.

Special keystrokes are in effect during the ant’s march. The Space key toggles a step-by-step mode. When in this mode, press Enter to see each step of the ant’s progress. When orbit delay (on P screen) is set to 1, the step mode is the default.

If you press the right or left arrow during the ant’s journey, you can adjust the orbit delay factor with the arrow keys (increment by 10) or Ctrl+Arrow keys (increment by 100). Press any other key to get out of the orbit delay adjustment mode. Higher values cause slower motion. Changed values are not saved after the ant is finished, but you can set the orbit delay value in advance from the P screen.

(type=phoenix, mandphoenix, phoenixcplx, mandphoenixclx)

The phoenix type defaults to the original phoenix curve discovered by Shigehiro Ushiki, "Phoenix", IEEE Transactions on Circuits and Systems, Vol. 35, No. 7, July 1988, pp. 788-789. These images do not have the X and Y axis swapped as is normal for this type.

The mandphoenix type is the corresponding Mandelbrot set image of the phoenix type. The spacebar toggles between the two as long as the mandphoenix type has an initial z(0) of (0,0). The mandphoenix is not an effective index to the phoenix type, so explore the wild blue yonder.

To reproduce the Mandelbrot set image of the phoenix type as shown in Stevens' book, "Fractal Programming in C", set initorbit=0/0 on the command line or with the G key. The colors need to be rotated one position because Stevens uses the values from the previous calculation instead of the current calculation to determine when to bailout.

The phoenixcplx type is implemented using complex constants instead of the real constants that Stevens used. This recreates the mapping as originally presented by Ushiki.

The mandphoenixclx type is the corresponding Mandelbrot set image of the phoenixcplx type. The spacebar toggles between the two as long as the mandphoenixclx type has a perturbation of z(0) = (0,0). The mandphoenixclx is an effective index to the phoenixcplx type.

(type=frothybasin)

Frothy basins, or riddled basins, were discovered by James C. Alexander of the University of Maryland. The discussion below is derived from a two page article entitled "Basins of Froth" in Science News, November 14, 1992 and from correspondence with others, including Dr. Alexander.

The equations that generate this fractal are not very different from those that generate many other orbit fractals.

One of the things that makes this fractal so interesting is the shape of the dynamical system’s attractors. It is not at all uncommon for a dynamical system to have non-point attractors. Shapes such as circles are very common. Strange attractors are attractors which are themselves fractal. What is unusual about this system, however, is that the attractors intersect. This is the first case in which such a phenomenon has been observed. The attractors for this system are made up of line segments which overlap to form an equilateral triangle. This attractor triangle can be seen by using the "show orbits" option (the O key) or the "orbits window" option (the Ctrl+O key).

The number of attractors present is dependant on the value of A, the imaginary part of C. For values where A ⇐ 1.028713768218725…​, there are three attractors. When A is larger than this critical value, two of attractors merge into one, leaving only two attractors. An interesting variation on this fractal can be generated by applying the above mapping twice per each iteration. The result is that some of the attractors are split into two parts, giving the system either six or three attractors, depending on whether A is less than or greater than the critical value.

These are also called "riddled basins" because each basin is riddled with holes. Which attractor a point is eventually pulled into is extremely sensitive to its initial position. A very slight change in any direction may cause it to end up on a different attractor. As a result, the basins are thoroughly intermingled. The effect appears to be a frothy mixture that has been subjected to lots of stirring and folding.

Pixel color is determined by which attractor captures the orbit. The shade of color is determined by the number of iterations required to capture the orbit. In Id, the actual shade of color used depends on how many colors are available in the video mode being used. If 256 colors are available, the default coloring scheme is determined by the number of iterations that were required to capture the orbit. An alternative coloring scheme can be used where the shade is determined by the iterations required divided by the maximum iterations. This method is especially useful on deeply zoomed images. If only 16 colors are available, then only the alternative coloring scheme is used. If fewer than 16 colors are available, then Id just colors the basins without any shading.

(type=volterra-lotka)

In the book "The Beauty of Fractals", these images are offered as an example of "how an apparently innocent system of differential equations gives rise to unimaginably rich and complex behavior after discretization." The Volterra-Lotka equations are a refinement of attempts to model predator-prey systems.

If x represents the prey population and y represents the predator population, their relationship can be expressed as:

According to Peitgen and Richter, "Hence, x grows at a constant rate in the absence of y, and y decays at a constant rate in the absence of x. The prey is consumed in proportion to y, and the predators expand in proportion to x." They proceed to "discretize" this system, by "mating" the Euler and Heun methods. For purposes of image computation, their formula (equation 8.3 on page 125) can be interpreted as:

This formula can be used to plot or connect single points, starting with arbitrary values of x(0) and y(0), to produce typical "strange attractor" images such as the ones commonly derived from the Henon or Lorenz formulae. But to produce an escape-time fractal, we iterate this formula for all (x, y) pairs that we can associate with pixels on our monitor screen. The standard window is: 0.0 < x < 6.0; 0.0 < y < 4.5. Since the "unimaginably rich and complex behavior" occurs with the points that do not escape, the inside coloring method assumes considerable importance.

The parameters h and p can be selected between 0.0 and 1.0, and this determines the types of attractors that will result. Infinity and (1, 1) are predictable attractors. For certain combinations, an "invariant circle" (which is not strictly circular) and/or an orbit of period 9 also are attractive.

The invariant circle and periodic orbit change with each (h, p) pair, and they must be determined empirically. That process would be thoroughly impractical to implement through any kind of fixed formula. This is especially true because even when these attractors are chosen, the threshold for determining when a point is "close enough" is quite arbitrary, and yet it affects the image considerably. The best compromise in the context of a generalized formula is to use either the "zmag" or "bof60" inside coloring options. See Inside=bof60|bof61|zmag|fmod|period|atan for details. This formula performs best with a relatively high bailout value; the default is set at 256, rather than the standard default of 4. Reference: Peitgen, H.-O. and Richter, P.H. The Beauty of Fractals, Springer-Verlag, 1986; Section 8, pp. 125-7.

(type=escher_julia)

These unique variations on the Julia set theme, presented in "The Science of Fractal Images", challenge us to expand our pre-conceived notions of how fractals should be iterated. We start with a very basic Julia formula:

The standard algorithm would test each iterated point to see if it "escapes to infinity". If its size or "modulus" (its distance from the origin) exceeds a preselected Bailout Test value, it is outside the Julia set, and it is banished to the world of multicolored level sets which color-cycle spectacularly. But another way of describing an escaped point is to say that it is "attracted" to infinity. We make this decision by calculating whether the point falls within the "target set" of all points closer to infinity than the boundary created by the bailout value. In this way, the "disk around infinity" is conceptually no different from the disks around Finite Attractors such as those used for Newton fractals.

In the above formula, with c = (0, 0i), this standard algorithm yields a rather unexciting circle. But along comes Peitgen to tell us that "since T [the target set] can essentially be anything, this method has tremendous artistic potential. For example, T could be a so-called p- norm disk …​ or a scaled filled-in Julia set or something designed by hand. This method opens a simple [beware when he uses words like that] and systematic approach to Escher-like tilings."

So, what we do is iterate the above formula, scale each iteration, and plug it into a second Julia formula. This formula has a value of c selected by the user. If the point converges to this non-circular target set:

we color it in proportion to the overall iteration count. If not, it will be attracted to infinity and can be colored with the usual outside coloring options. This formula uses an Id programming feature which allows the use of a customized coloring option for the points which converge to the target Julia set, yet allows the other points to be handled by the standard fractal engine with all of its options.

With the proper palette and parameters for c, and using the Inversion option and a solid outside color from the Color Parameters, you can create a solar eclipse, with the corona composed of Julia-shaped flames radiating from the sun’s surface. If you question the relevance of these images to Escher, check out his Circle Limit series (especially III and IV). In his own words: "It is to be doubted whether there exist today many …​ artists of any kind, to whom the desire has come to penetrate to the depths of infinity…​. There is only one possible way of …​ obtaining an "infinity" entirely enclosed within a logical boundary line…​. The largest …​ shapes are now found in the center and the limit of infinite number and infinite smallness is reached at the circumference…​. Not one single component ever reaches the edge. For beyond that there is "absolute nothingness." And yet this round world cannot exist without the emptiness around it, not simply because "within" presupposes "without", but also because it is out there in the "nothingness" that the center points of the arcs that go to build up the framework are fixed with such geometric exactitude."

References: Ernst, B. The Magic Mirror of M. C. Escher, Barnes & Noble, 1994, pp. 102-11. Peitgen, H.-O. and Saupe, D. The Science of Fractal Images, Springer- Verlag, 1988; pp. 185, 187.

(type=latoocarfian)

This fractal type first appeared in the book "Chaos in Wonderland" by Clifford Pickover (ISBN 0-312-10743-9 St. Martin’s Press).

The Latoocarfians are beings that inhabit the moon Ganymede (of Jupiter) and have their forms generated by these formulas.

The initial points plotted are the more chaotic initial orbits, but as you wait, delicate webs will begin to form as the orbits settle into a more periodic pattern. Since pixels are colored by the number of times they are hit, the more periodic paths will become clarified with time.

There are 4 parameters: a, b, c, d and we recomend: a > -3, b < 3, c > 0.5, d < 1.5

(type=mandelbrotmix4)

Jim Muth published a "Fractal of the Day" on the Fractint mailing list for many years. As often as not Jim picks the formula Mandelbrotmix4 as the fractal continent to explore. To honor Jim, the Id authors have provided this fractal as a built-in type.

The formula is:

Note that Jim uses l=imag(p3)+100, which is to say, the sixth scalar parameter, as the bailout. Our implementation follows Jim if the user requests the default bailout.

(type=dividebrot5) This is Jim Muth’s fifth version of the DivideBrot formula.

The formula is:

The "passes option" (X options screen or "passes=" parameter) selects one of the single-pass, dual-pass, triple-pass, solid-guessing (default), solid-guessing after pass n, boundary tracing, tesseral, synchronous orbits, or orbits modes.

This option applies to most fractal types.

Single-pass mode ("1") draws the screen pixel by pixel.

Dual-pass ("2") generates a half-resolution screen first as a preview using 2x2-pixel boxes, and then generates the rest of the dots with a second pass. Dual-pass uses no more time than single-pass.

Triple-pass ("3") generates the coarse first pass of the solidguessing mode (see "g" below), then switches to either "1" (with low resolution video modes) or "2" (with higher resolution video modes). The advantage of '3' vs '2' is that when using high resolution modes, the first pass has a much lower resolution (about 160x120) and is therefore much quicker than the first pass of the passes=2 mode. However, with the '2' mode, the first pass does not represent wasted time. The '3' mode wastes the effort of generating the coarse first screen.

The single, dual, and triple pass modes all result in identical images. These modes are for those who desire the highest possible accuracy. Most people will want to use the guessing mode, described next.

Solid-guessing ("g") is the default. It performs from two to four visible passes - more in higher resolution video modes. Its first visible pass is actually two passes - one pixel per 4x4, 8x8, or 16x16 pixel box is generated, and the guessing logic is applied to fill in the blocks at the next level (2x2, 4x4, or 8x8). Subsequent passes fill in the display at the next finer resolution, skipping blocks which are surrounded by the same color. Solid-guessing can guess wrong, but it sure guesses quickly!

Solid-guessing stop after pass n ("g1" through "g6") are a variation on the guessing mode in which the algorithm stops after the nth pass. This facility is for exploring in low resolution when you’d rather see a low resolution image with large blocky pixels filling the whole screen than a small low resolution image such as you get with the V (View Windows) command. Note that on the X screen you can’t directly type g1 or g2. Press g repeatedly until you get the option you want, or else use the left or right arrow keys.

Boundary Tracing ("b"), which only works accurately with fractal types (such as the Mandelbrot set, but not the Newton type) that do not contain "islands" of colors, finds a color boundary, traces it around the screen, and then "blits" in the color over the enclosed area. Tesseral ("t") is a sort of "super-solid-guessing" option that successively divides the image into subsections and colors in rectangles that have a boundary of a solid color. It’s actually slower than the solid-guessing algorithm, but it looks neat, so we left it in. This mode is also subject to errors when islands of color appear inside the rectangles.

Diffusion Scan ("d") is a drawing type based on dithering techniques. It scans the image spreading the points evenly and to each point it paints a square of the appropriate size so that the image will be incrementally enhanced. This method calculates all the points in the image being a good substitute for single/double/triple pass and presents a quick visualization even in the slowest fractals. With "fillcolor=0" (below) the squares are not painted and the points are spread over the image until all have being calculated (sort of a "fade in").

The "fillcolor=" option in the X screen or on the command line sets a fixed color to be used by the boundary tracing and tesseral calculations for filling in defined regions. The effect of this is to show off the boundaries of the areas delimited by these two methods.

Orbits ("o") draws an image by plotting the orbits of the escape time fractals. This technique uses the same coordinates to draw an image as the other passes options, sets "passes=1" and no symmetry, and then plots the orbits for each pixel. Zooming into a "passes=o" image is in fact zooming into the "passes=1" image, and the resulting image may not be what is expected. To find interesting places to investigate, press O after an image has completed and watch the behaviour of the orbits as the cursor is moved around the screen. See Orbits Window.

The "outside=summ" option causes orbits to increment a pixel’s color number every time an orbit touchs it; the resulting display is a 2-d histogram. If "outside=" is some other value, then the "inside=" color determines the color of the plotted orbits. If "inside=0", then the color number is incremented at the start of each pixel of the passes=1 image.

The "orbitdelay=" option controls how many orbits are computed before the orbits are displayed on the screen. This allows the orbits to settle down. The "orbitinterval=" option causes Orbits to plot every nth orbit point. A non-zero value of the "periodicity=" option causes orbits to not plot orbits that have reached the bailout conditions or where an orbit goes off the visible area of the image. A zero value of periodicity will plot all orbits except as modified by orbitdelay and orbitinterval.

Synchronous orbits ("s") is an experimental mode using the "fractal witchcraft" algorithm based on the Almondbread implementation by Michael Ganss. This algorithm optimizes deep zooms by calculating parallel orbits starting at different points, and subdividing when the orbits break formation.

Synchronous orbits (also known as SOI) has some limitations. SOI is loosely coupled with Id and most options don’t work with it. Only types mandel and julia are implemented. SOI is only useful for very deep zooms, but only up to the limit of double precision. Within this narrow magnification range, SOI can result in tremndous speedups. If you invoke Id with "debug=3444" on the command line, a long double (rather than double) version will be used, which allows zooming about 1000 times deeper. SOI really needs to be ported to Id’s arbitary precision.

You can save and restore color palettes for use with any image. To load a palette onto an existing image, use the L command in color-cycling or palette-editing mode. To save a palette, use the S command in those modes. To change the default palette for an entire run, use the command line "map=" parameter.

The default filename extension for color-map files is ".map".

These color-maps are ASCII text files set up as a series of RGB triplet values (one triplet per line, encoded as the red, green, and blue [RGB] components of the color). Map file color values are integers - values go from 0 (low) to 255 (high).

Id is distributed with some sample .map files: altern.map the famous "Peterson-Vigneau Pseudo-Grey Scale" blues.map for rainy days, by Daniel Egnor chroma.map general purpose, chromatic default.map the default start-up values firestrm.map general purpose, muted fire colors gamma1.map, Lee Crocker’s response gamma2.map to altern.map glasses1.map used with 3D glasses modes glasses2.map used with 3D glasses modes green.map shaded green grey.map another grey variant grid.map for stereo surface grid images headache.map major stripes, by D. Egnor (try cycling and hitting 2) landscap.map Guruka Singh Khalsa’s favorite map for plasma "landscapes" neon.map a flashy map, by Daniel Egnor royal.map the royal purple, by Daniel Egnor topo.map Monte Davis’s contribution to full color terrain volcano.map an explosion of lava, by Daniel Egnor

The autokey feature allows you to set up beautiful self-running demo "loops". You can set up hypnotic sequences to attract people to a booth, to generate sequences for special effects, to teach how fractal exploring is done, etc.

A sample autokey file (demo.key) and a script to run it (demo.bat) is included with Id. Type "demo" at a command prompt to run it.

Autokey record mode is enabled with the command line parameter "autokey=record". Keystrokes are saved in an intelligible text format in a file called auto.key. You can change the file name with the "autokeyname=" parameter.

Playback is enabled with the parameter "autokey=play". Playback can be terminated by pressing the Esc key.

After using record mode to capture an autokey file, you’ll probably want to touch it up using your editor before playing it back.

Separate lines are not necessary but you’ll probably find it easier to understand an autokey file if you put each command on a separate line. Autokey files can contain the following:

Making Id demos can be tricky. Here are some suggestions which may help:

Warning: an autokey file built for this version of Id will probably require some retouching before it works with future releases of Id. We have no intention of making sure that the same sequence of keystrokes will have exactly the same effect from one version of Id to the next. That would require pretty much freezing Id development, and we just love to keep enhancing it!

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 Y 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 displayed 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. Negative values are now allowed and give a fraction of a percent of the pixel width. For example: -71 gives 1/71 % of the pixel width.

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.

Enabling the distance estimator method automatically toggles to floating point mode. When you reset distest back to zero, remember to also turn off floating point mode if you want it off.

Unfortunately, images using the distance estimator method can take a long time 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 B to save the current image information in a parameter file (see Parameter Save/Restore Commands). Use an editor to change the parameter file entry, adding "distest=1", "video=something" to select a high-resolution monochrome disk-video mode, "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?).

To obtain the finest strands it is necessary to set the "width factor" to a large negative value, such as -32000.

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; Id 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 Y 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?

You’ll remember that most fractal types are calculated by iterating a simple function of a complex number, producing another complex number, until either the number exceeds some pre-defined "bailout" value, or the iteration limit is reached. The pixel corresponding to the starting point is then colored based on the result of that calculation.

The decomposition option ("decomp=", on the X screen) toggles to another coloring protocol. Here the points are colored according to which quadrant of the complex plane (negative real/positive imaginary, positive real/positive imaginary, etc.) the final value is in. If you use 4 as the parameter, points ending up in each quadrant are given their own color; if 2 (binary decomposition), points in alternating quadrants are given 2 alternating colors.

The result is a kind of warped checkerboard coloring, even in areas that would ordinarily be part of a single contour. Remember, for the M-set all points whose final values exceed 2 (by any amount) after, say, 80 iterations are normally the same color; under decomposition, Id runs 80 iterations and then colors according to where the actual final value falls on the complex plane.

When using decomposition, a higher bailout value will give a more accurate plot, at some expense in speed. You might want to set the bailout value (in the parameters prompt following selection of a new fractal type; present for most but not all types) to a higher value than the default. A value of about 50 is a good compromise for M/J sets.

By default, Id maps iterations to colors 1:1. For example, if the calculation for a fractal "escapes" (exceeds the bailout value) after N iterations, the pixel is colored as color number N. If N is greater than the number of colors available, it wraps around. So, if you are using a 16-color video mode, and you are using the default maximum iteration count of 150, your image will run through the 16-color palette 150/16 = 9.375 times.

When you use Logarithmic palettes, the entire range of iteration values is compressed to map to one span of the color range. This results in spectacularly different images if you are using a high iteration limit and are zooming in on an area near a "lakelet".

When using a compressed palette in a 256 color mode, we suggest changing your colors from the usual defaults. The last few colors in the default color map are black. This results in points nearest the "lake" smearing into a single dark band, with little contrast from the blue (by default) lake.

Id has a number of types of compressed palettes, selected by the "Log Palette" line on the X screen, or by the "logmap=" command line parameter:

Another way to change the 1:1 mapping of iteration counts to colors is to use the "ranges=" parameter. It has the format: ranges=aa/bb/cc/dd/…​

Iteration counts up to and including the first value are mapped to color number 0, up to and including the second value to color number 1, and so on. The values must be in ascending order.

A negative value can be specified for "striping". The negative value specifies a stripe width, the value following it specifies the limit of the striped range. Two alternating colors are used within the striped range. Example: ranges=0/10/30/-5/65/79/32000 This example maps iteration counts to colors as follows:

Related to Decomposition are the "biomorphs" invented by Clifford Pickover, and discussed by A. K. Dewdney in the July 1989 "Scientific American", page 110. These are so-named because this coloring scheme makes many fractals look like one-celled animals. The idea is simple. The escape-time algorithm terminates an iterating formula when the size of the orbit value exceeds a predetermined bailout value. Normally the pixel corresponding to that orbit is colored according to the iteration when bailout happened. To create biomorphs, this is modified so that if EITHER the real OR the imaginary component is LESS than the bailout, then the pixel is set to the "biomorph" color. The effect is a bit better with higher bailout values: the bailout is automatically set to 100 when this option is in effect. You can try other values with the "bailout=" option.

The biomorph option is turned on via the "biomorph=nnn" command-line option (where "nnn" is the color to use on the affected pixels). When toggling to Julia sets, the default corners are three times bigger than normal to allow seeing the biomorph appendages. Does not work with all types - in particular it fails with any of the mandelsine family. However, it works great in two-color modes. Try it with the marksmandel and marksjulia types.

Note: This option can only be used with 256 color video modes.

Id’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 (see "3D" Images), 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

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, Id’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 bad news is that the integer math which makes the "mandel" and "julia" types so fast imposes a hard-wired maximum value of 127. You can still make interesting images from those types, though, so don’t avoid them. You will see "ridges" in the "hillsides." Some folks like the effect.

The good news is that the other fractal types, particularly the floating point algorithms, have no such limitation. The even better news is that there is a floating-point algorithm for the "mandel" and "julia" types. To force the use of a floating-point algorithm, use Id with the "float=yes" command-line parameter or the X options screen. Only a few fractal types like plasma clouds, the Barnsley IFS type, and "test" are unaffected by this option.

The parameters for continuous potential are: potential=maxcolor[/slope[/modulus[/16bit]]] These parameters are present on the Y 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. Remember that the last few colors of the default palette are black, so you won’t see what you are really getting unless you change to a different palette.

"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. As noted, this value must be < 128 for the integer fractal types (if you select a higher number, they will use 127).

"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. Id’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: * The saved file is a fair bit larger. * Id names the file with a .pot extension instead of .gif, if you didn’t specify an extension in "savename". * The image can be used as input to a subsequent 3 command to get the promised smoother effect. * If you happen to view the saved image with a GIF viewer other than Id, 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 Restoring it, changing "16bit" to "no" on the Y options screen, and Saving.

You might find with 16bit continuous potential that there’s a long delay at the start of an image, and disk activity during calculation. Id uses its disk-video cache area to store the extra 8 bits per pixel - if there isn’t sufficient memory available, the cache will page to disk.

The following commands can be used to recreate the image that Mark Peterson first prototyped for us, and named "MtMand":

Once you have generated your favorite fractal image, you can convert it into a fractal starfield with the A transformation (for 'astronomy'? - once again, all of the good letters were gone already). Stars are generated on a pixel-by-pixel basis - the odds that a particular pixel will coalesce into a star are based (partially) on the color index of that pixel.

(The following was supplied by Mark Peterson, the starfield author.)

If the screen were entirely black and the "Star Density per Pixel" were set to 30 then a starfield transformation would create an evenly distributed starfield with an average of one star for every 30 pixels.

If you’re on a 320x200 screen then you have 64000 pixels and would end up with about 2100 stars. By introducing the variable of "Clumpiness" we can create more stars in areas that have higher color values. At 100% clumpiness a color value of 255 will change the average of finding a star at that location to 50:50. A lower clumpiness values will lower the amount of probability weighting. To create a spiral galaxy draw your favorite spiral fractal (IFS, Julia, or Mandelbrot) and perform a starfield transformation. For general starfields I’d recommend transforming a plasma fractal.

Real starfields have many more dim stars than bright ones because very few stars are close enough to appear bright. To achieve this effect the program will create a bell curve based on the value of ratio of dim stars to bright stars. After calculating the bell curve the curve is folded in half and the peak used to represent the number of dim stars.

Starfields can only be shown in 256 colors. Id will automatically try to load altern.map and abort if the map file cannot be found.

The bailout test is used to determine if we should stop iterating before the maximum iteration count is reached. This test compares the value determined by the test to the "bailout" value set via the Z screen. The default bailout test compares the magnitude or modulus of a complex variable to some bailout value:

bailout test = |z| = sqrt(x^2 + y^2) >= 2

As a computational speedup, we square both sides of this equation and the bailout test used by Id is:

bailout test = |z|^2 = x^2 + y^2 >= 4

Using a bailout other than 4 allows us to change when the bailout will occur.

The following bailout tests have been implemented on the Z screen:

The bailout test feature has not been implemented for all applicable fractal types. This is due to the speedups used for these types. Some of these bailout tests show the limitations of the integer math routines by clipping the spiked ends off of the protrusions.

Since Id is such a wonderfully complex program it has more than a few parameters to tweak and options to select. To the inexperienced user the choice is bewildering. Even for the experts the chaotic nature of the mathematical processes involved make it difficult to know what to change in order to achieve the desired effect.

In order to help with this situation the Id parameter evolver has been developed. It varies those parameters for you and puts the results on screen as a grid of small images. You can then choose the one which you like best and regenerate it full screen, or if you don’t like any of the variations, you can try again to see if anything better turns up!

Enough explanations for now, lets see how easy it is to use:

With the default Mandlebrot set on the screen simply hold down the Alt+1 key on the top row (DON’T use the numeric keypad to the right, it won’t work). You’ll see a screen full of images generated starting from the middle and spiraling outwards. The perfect Mandlebrot set will be in the middle and the others will be warped and distorted by having had the initial value of Z perturbed at random…​ but you don’t need to know that (which is the whole point really!).

Alt+1 produces a low level of mutation of the fractal, only 'mild' parameters are changed, those which have a more subtle effect. For much wilder variations try pressing Alt+7 now. This give the maximum available mutation with just about everything being twiddled and fiddled to rather dramatic effect as you should now be seeing.

To select an image for full screen display simply bring up a zoombox by pressing 'Page-up' once. The center image will now have a white box around it. Hold down the Ctrl+Arrow keys to move this box around until it’s outlining an image you like. Pressing B will now exit from evolver mode and redraw the selected image full size. If, rather than exiting from evolver mode, you just press Enter, then a whole new set of images is generated, all based around the one you selected (which is now the middle image of the new set).

From a basic point of view that’s it! Just press Alt+1 …​ Alt+7 to scramble things when you’re out of inspiration, it works for any of the fractal types in Id including formulae…​ easy! (chaotic, but easy :-) )

As this is an Id feature, there is, of course, a lot more to it than the basics described above…​

For a start, there are some handy hotkeys to use, F2 and F3 are used to alter the amount of mutation or the amount by which the selected parameters can be varied. F2 halves the amount of mutation, F3 doubles it. So if things on-screen are looking a bit samey just press F3 a few times to crank up the mutation level.

Using F2 to decrease mutation levels is a way of moving towards a goal image. Say that a set of images contained one that looked a little like, maybe, a cats face and you wished to try and get something more cat like. To achieve this simply select the desired image and press F2. The newly generated images should be more alike, though probably still quite widely varied. With luck, one of the new images will be even more cat like. Select this one and press F2 again. Continue like this, selecting the center image again if there are no improvements in the current generation, until eventually all the images are alike and you’ve arrived at your goal (or at least you’re probably as close as it’s possible to get with that fractal type).

As you look for more details in the images it is useful to reduce the number of images per generation, thus producing larger sub images. Pressing F4 will reduce the number of images per side on the grid by two and pressing F5 increments the gridsize similarly.

F6 will switch between normal random mutation and 'spread' random mutation. In 'spread' mode the amount of mutation allowed in an image is varied according to each images position in the grid. Those images near the center are allowed a lesser degree of freedom of mutation than those around the outside. This produces a sea of images, stable at the center with wilder variations around the edges. This mode is best used with larger gridsizes and becomes completely silly at a gridsize of three!

Ctrl+E brings up the evolver control screen on which you have manual access to the evolution parameters varied by the hotkeys described above. These are:

Pressing F6 brings up a screen from which you can control what parameters get varied and in what manner. You’ll notice that as well as the mutation modes 'random' and 'spread' there are other ways of stirring things around, read on…​…​

As well as randomly mutating parameter values (referred to as 'evolver mode' or just 'evolving') a chosen set of parameters can be varied steadily across the screen thus allowing the user to explore what happens as a parameter is slowly changed ('explorer mode' or 'exploring'). For example, to get acquainted with parameter exploring and produce a map of the Julia sets, try this:

In the example shown above, you were just exploring the variation in two 'real' parameters, i.e. they can take fractional values, and the idea of being able to create an image half way between two others is valid. However, many of the parameters in Id are discrete, i.e. can be only one of a set of specific values. Examples of discrete parameters are inside colouring method or decomposition values and the way in which these are explored is different in that parameter zooming has no meaning for discrete parameters.

When a discrete parameter is set to vary with x or y it is simply cycled through all possible values and round again. Words are getting clumsy so it’s time for another example methinks!

First press 'Insert' to restart Id and get everything back to its default values for a fresh start. Set the fractal type to 'fn*fn' this type requires the user to choose two trig functions and this choice is made on the 'Z' screen. There are around thirty different functions to choose from and checking out all the different combinations is a not inconsiderable task manually. With the explorer, however, it’s a piece of cake!

Set the screen resolution to the highest you can view and press Ctrl+E to bring up the control panel and enable evolving mode. Set the gridsize to 29 and leave the parameters at their defaults. Now, press F6 to enter 'variable tweak central' and set trig function 1 to 'x' and trig function 2 to 'y', and all the others to 'no'. Exit the two screens and you’ll see generated all of the different combinations possible even if they are rather small examples!

To find out what particular combination of trig functions an image is using, just select the image using the zoombox and bring up the 'z' screen. You don’t have to press Enter, simply highlighting the appropriate image with the Ctrl+arrow keys will do.

And that just about sums up the evolver! Much more could be written but it’s better experienced, try writing your formulae with more variable parameters and trig functions so that their behavior can be investigated.

Try using it with any fractal type, if in doubt just see what happens!

It should be noted here that some of the fractal types such as the IFS do not terminate, they run on forever and as such aren’t usable with the evolver as the first sub image would never finish to allow the next one to generate. These fractal types are detected and you won’t be allowed to start the evolver with these. There now only remains to mention that you can save image sets and restore them later to carry on exploring from a different seed image: S saves and R restores as in normal Id operation and the screenfull is saved as a single GIF file.

Have fun! See Evolver Commands.

Random dot stereograms (RDS) are a way of encoding stereo images on a flat screen. Id can convert any image to a RDS using either the color number in the current palette or the grayscale value as depth. Try these steps. Generate a plasma fractal using the 256 color video mode. When the image on the screen is complete, press Ctrl+S ("S" for "Stereo"), and press Enter at the "RDS Parameters" screen prompt to accept the defaults. (More on the parameters in a moment.) The screen will be converted into a seemingly random collection of colored dots. Relax your eyes, looking through the screen rather than at the screen surface. The image will (hopefully) resolve itself into the hills and valleys of the 3D Plasma fractal.

Because pressing the two-keyed Ctrl+S gets tiresome after a while, we have made K key a synonym for Ctrl+S for convenience. Don’t get too attached to K though; we reserve the right to reuse it for another purpose later.

The RDS feature has five and sometimes six parameters. Pressing Ctrl+S always takes you to the parameter screen.

The first parameter allows you to control the depth effect. A larger value (positive or negative) exaggerates the sense of depth. If you make the depth negative, the high and low areas of the image are reversed. If your RDS image is streaky try either a lower depth factor or a higher resolution.

The second parameter indicates the overall width in inches of the image on your monitor. The default value is 10 inches. If you’re having trouble seeing the image, enter the image width in inches. The issue here is that if the widest separation of left and right pixels is greater than the physical separation of your eyes, you will not be able to fuse the images. Conversely, a too-small separation may cause your eyes to hyper-converge (fuse the wrong pixels together). A larger width value reduces the width between left and right pixels. You can use the calibration feature to help set the width parameter - see below. Once you have found a good width setting, you can place the value in your sstools.ini file with the command stereowidth=<nnn>.

The third parameter allows you to control the method use to extract depth information from the original image. If your answer "no" at the "Use Grayscale value for Depth" prompt, then the color number of each pixel will be used. This value is independent of active color palette. If you answer "yes" and the prompt, then the depth values are keyed to the brightness of the color, which will change if you change palettes. The fourth parameter allows you to set the position of vertical stereo calibration bars to the middle or the top of the image, or have the bars initially turned off. Use this feature to help you adjust your eye’s convergence to see the image. You will see two vertical bars on the screen. You can turn off and on these bars with the Enter or Space keys after generating the RDS image. If you save an RDS image by pressing S, if the bars are turned on at the time, they become a permanent part of the image.

As you relax your eyes and look past the screen, these bars will appear as four bars. When you adjust your eyes so that the two middle bars merge into one bar, the 3D image should appear. The bars are set for the average depth in the area near the bars. They should always be closer together than the physical separation of your eyes, but not much less than about 1.5 inches. About 1.75 inches is ideal for many images. The depth and screen width controls affect the width of the bars.

At the RDS Parameters screen, you can select bars at the middle of the screen or the top. If you select "none", the bars will initially be off, but immediately after generation of the image you can still turn on the bars with Enter or Space before you press any other keys. If the initial setting of the calibration bars is "none", then if the bars are turned on later they will appear in the middle. Hint: if you cycle the colors and find you can’t see the calibration bar, press Enter or Space twice, and the bars will turn to a more visible color.

The fifth parameter asks if you want to use an image map GIF file instead of using random dots. An image map can give your RDS image a more interesting background texture than the random dots. If you answer "yes" at the "Use image map?" prompt, Id will present you with a file selection list of GIF images. Id will then go ahead and transform your original image to RDS using the selected image map to provide the "random" dots.

After you have selected an image map file, the next time you reach the RDS Parameters screen you will see an additional prompt asking if you want to use the same image map file again. Answering "yes" avoids the file selection menu.

The best images to use as image maps are detailed textures with no solid spots. The default type=circle fractal works well, as do the barnsley fractals if you zoom in a little way. If the image map is smaller than your RDS image, the image map will repeated to fill the space. If the image map is larger, just the upper left corner of the image map will be used.

The original image you are using for your stereogram is saved, so if you want to modify the stereogram parameters and try again, just press Ctrl+S (or K) to get the parameter screen, changes the parameters, and press Enter. The original image is restored and an RDS transform with the revised parameters is performed. If you press S when viewing an RDS image, after the RDS image is saved, the original is restored.

Try the RDS feature with continuous potential Mandelbrots as well as plasma fractals. For a summary of keystrokes in RDS mode, see RDS Commands

It can be confusing working out what’s going on in freestyle mode so here’s a quick walk through…​

Freestyle palette editing is intended to be a way of colouring an image in an intuitive fashion with the minimum of keyboard usage. In fact everything is controllable with the mouse, as the following shows:

To start with, generate a plasma type fractal as it has all 256 colours on screen at once. Now bring up the palette editor and press W to set up a greyscale palette as a blank canvas on which to splash some colour. Pressing F puts us in freestyle mode…​ crosshairs appear on the screen and a colour band is applied, centred on the cursor. Although, at the moment, the colour of this band is grey and you won’t see much!

In order to change the colour of the band, hold down the left mouse button and drag up and down. This changes the amount of red in the band. You’ll see the values change in the status box above the palette grid. Double clicking the right mouse button changes the colour component that’s varied in an r-g-b-r-cycle…​. try it out and conjure up any shade you like!

To vary the width of the band, drag up and down with the right button held down. Slower machines may show some 'lag' during this operation, so watch out as the mouse movements get buffered.

Once you’ve got the band in a satisfactory position then double click the left button to fix it in place.

Continue like this for as long as you like, adding different colours to the grey palette.

You’ll notice how the band relates to the existing colour, the RGB values give the middle colour which are then smoothly shaded out to the colours at the ends of the band. This can lead to some sudden jumps in the shading as the band is moved about the screen and the edges come to overlap different areas of colour.

For really violent jumps in shading try starting with an image that has areas that change chaotically, such as a Mandlbrot set. You’ll see what I mean when you move the cross hairs into an area close to the 'lake' where the change in value from one pixel to the next is sudden, chaotic and large. Watch out! — the strobing effect can be somewhat disturbing. This is nothing to worry about but just a consequence of the manipulation of the palette and the way in which the colour bands are calculated.

I hope that you’ll find this a useful tool in colouring an image. Remember that the H key can be used to hide the palette box and expose the whole image.

Id can restore images in "3D". Important: we use quotation marks because it does not create images of 3D fractal objects (there are such, but we’re not there yet.) Instead, it restores .GIF images as a 3D projection or stereo image pair. The iteration values you’ve come to know and love, the ones that determine pixel colors, are translated into "height" so that your saved screen becomes a landscape viewed in perspective. You can even wrap the landscape onto a sphere for realistic-looking planets and moons that never existed outside your PC!

We suggest starting with a saved plasma-cloud screen. Hit 3 in main command mode to begin the process. Next, select the file to be transformed, and the video mode. (Usually you want the same video mode the file was generated in; other choices may or may not work.)

After hitting 3, you’ll be bombarded with a long series of options. Not to worry: all of them have defaults chosen to yield an acceptable starting image, so the first time out just pump your way through with the Enter key. When you enter a different value for any option, that becomes the default value the next time you hit 3, so you can change one option at a time until you get what you want. Generally Esc will take you back to the previous screen.

Once you’re familiar with the effects of the 3D option values you have a variety of options on how to specify them. You can specify them all on the command line, with an sstools.ini file, or with a parameter file.

Here’s an example for you power Iterated Dynamicists, the command

would make Id load myfile.gif, re-plot it as a 3D landscape (taking all of the defaults), save the result as my3d.gif, and exit. By the time you’ve come back with that cup of coffee, you’ll have a new world to view, if not conquer.

Note that the image created by 3D transformation is treated as if it were a plasma cloud - We have no idea how to retain the ability to zoom and pan around a 3D image that has been twisted, stretched, perspective- ized, and water-leveled. (Actually, we do, but it remains to be implemented in a future version of Id…​)

After hitting 3 and getting past the filename prompt and video mode selection, you’re presented with a "3D Mode Selection" screen. If you wish to change the default for any of the following parameters, use the arrow keys to move through the menu. When you’re satisfied press Enter.

When you are satisfied with your selections press enter to go to the next parameter screen.

This option exists because in the course of the 3D projection, portions of the original image may be stretched to fit the new surface. Points of an image that formerly were right next to each other, now may have a space between them. This option generally determines what to do with the space between the mapped dots. It is not used if you have selected a value for ray other than 0.

For an illustration, pick the second option "just draw the points", which just maps points to corresponding points. Generally this will leave empty space between many of the points. Therefore you can choose various algorithms that "fill in" the space between the points in various ways.

Next, try the first option "make a surface grid." This option will make a grid of the surface which is as many divisions in the original "y" direction as was set in "coarse" in the first screen. It is very fast, and can give you a good idea what the final relationship of parts of your picture will look like. Next, try the second option "connect the dots (wire frame)", then "surface fills" - "colors interpolated" and "colors not interpolated", the general favorites of the authors. Solid fill, while it reveals the pseudo-geology under your pseudo-landscape, inevitably takes longer.

Next, try the light source fill types. These two algorithms allow you to position the "sun" over your "landscape." Each pixel is colored according to the angle the surface makes with an imaginary light source. You will be asked to enter the three coordinates of the vector pointing toward the light in a following parameter screen - see Light Source Parameters.

"Light source before transformation" uses the illumination direction without transforming it. The light source is fixed relative to your computer screen. If you generate a sequence of images with progressive rotation, the effect is as if you and the light source are fixed and the object is rotating. Therefore, as the object rotates features of the object move in and out of the light.

"Light source after transformation" applies the same transformation to both the light direction and the object. Since both the light direction and the object are transformed, if you generate a sequence of images with the rotation progressively changed, the effect is as if the image and the light source are fixed in relation to each other and you orbit around the image. The illumination of features on the object is constant, but you see the object from different angles.

For ease of discussion we will refer to the following fill types by these numbers: 1 - surface grid 2 - (default) - no fill at all - just draw the dots 3 - wire frame - joins points with lines 4 - surface fill - (colors interpolated) 5 - surface fill - (interpolation turned off) 6 - solid fill - draws lines from the "ground" up to the point 7 - surface fill with light model - calculated before 3D transforms 8 - surface fill with light model - calculated after 3D transforms

Types 4, 7, and 8 interpolate colors when filling, making a very smooth fill if the palette is continuous. This may not be desirable if the palette is not continuous. Type 5 is the same as type 4 with interpolation turned off. You might want to use fill type 5, for example, to project a .gif photograph onto a sphere. With type 4, you might see the filled-in points, since chances are the palette is not continuous; type 5 fills those same points in with the colors of adjacent pixels. However, for most fractal images, fill type 4 works better.

This screen is not available if you have selected a ray tracing option.

The "Funny Glasses Parameters" (stereo 3D) screen is presented only if you select a non-zero stereo option in the prior 3D parameters. (See 3D Mode Selection.) We suggest you definitely use defaults at first on this screen.

When you look at an image with both eyes, each eye sees the image in slightly different perspective because they see it from different places.

The first selection you must make is ocular separation, the distance the between the viewers eyes. This is measured as a % of screen and is an important factor in setting the position of the final stereo image in front of or behind the CRT Screen.

The second selection is convergence, also as a % of screen. This tends to move the image forward and back to set where it floats. More positive values move the image towards the viewer. The value of this parameter needs to be set in conjunction with the setting of ocular separation and the perspective distance. It directly adjusts the overall separation of the two stereo images. Beginning anaglyphers love to create images floating mystically in front of the screen, but grizzled old 3D veterans look upon such antics with disdain, and believe the image should be safely inside the monitor where it belongs!

Left and Right Red and Blue image crop (% of screen also) help keep the visible part of the right image the same as the visible part of the left by cropping them. If there is too much in the field of either eye that the other doesn’t see, the stereo effect can be ruined.

Red and Blue brightness factor: the generally available red/blue-green glasses, made for viewing on ink on paper and not the light from a CRT, let in more red light in the blue-green lens than we would like. This leaves a ghost of the red image on the blue-green image (definitely not desired in stereo images). We have countered this by adjusting the intensity of the red and blue values on the CRT. In general you should not have to adjust this.

The final entry is the map file name (present only if stereo=1 or stereo=2 was selected). If you have a special map file you want to use for stereo 3D this is the place to enter its name. Generally glasses1.map is for type 1 (alternating pixels), and glasses2.map is for type 2 (superimposed pixels). Grid.map is great for wire-frame images using 16 color modes.

This screen is not available if you have selected a ray tracing option.

The first entries are rotation values around the X, Y, and Z axes. Think of your starting image as a flat map: the X value tilts the bottom of your monitor towards you by X degrees, the Y value pulls the left side of the monitor towards you, and the Z value spins it counter- clockwise. Note that these are NOT independent rotations: the image is rotated first along the X-axis, then along the Y-axis, and finally along the Z-axis. Those are your axes, not those of your (by now hopelessly skewed) monitor. All rotations actually occur through the center of the original image. Rotation parameters are not used when a ray tracing option has been selected.

Then there are three scaling factors in percent. Initially, leave the X and Y axes alone and play with Z, now the vertical axis, which translates into surface "roughness." High values of Z make spiky, on- beyond-Alpine mountains and improbably deep valleys; low values make gentle, rolling terrain. Negative roughness is legal: if you’re doing an M-set image and want Mandelbrot Lake to be below the ground, instead of eerily floating above, try a roughness of about -30%.

Next we need a water level — really a minimum-color value that performs the function "if (color < waterlevel) color = waterlevel". So it plots all colors "below" the one you choose at the level of that color, with the effect of filling in "valleys" and converting them to "lakes."

Now we enter a perspective distance, which you can think of as the "distance" from your eye to the image. A zero value (the default) means no perspective calculations, which allows use of a faster algorithm. Perspective distance is not available if you have selected a ray tracing option.

For non-zero values, picture a box with the original X-Y plane of your flat fractal on the bottom, and your 3D fractal inside. A perspective value of 100% places your eye right at the edge of the box and yields fairly severe distortion, like a close view through a wide-angle lens. 200% puts your eye as far from the front of the box as the back is behind. 300% puts your eye twice as far from the front of the box as the back is, etc. Try about 150% for reasonable results. Much larger values put you far away for even less distortion, while values smaller than 100% put you "inside" the box. Try larger values first, and work your way in.

Next, you are prompted for two types of X and Y shifts (now back in the plane of your screen) that let you move the final image around if you’d like to re-center it. The first set, x and y shift with perspective, move the image and the effect changes the perspective you see. The second set, "x and y adjust without perspective", move the image but do not change perspective. They are used just for positioning the final image on the screen. Shifting of any type is not available if you have selected a ray tracing option.

You are asked for a range of "transparent" colors, if any. This option is most useful when using the 3D Overlay Mode. Enter the color range (minimum and maximum value) for which you do not want to overwrite whatever may already be on the screen. The default is no transparency (overwrite everything). Now, for the final option. This one will smooth the transition between colors by randomizing them and reduce the banding that occurs with some maps. Select the value of randomize to between 0 (for no effect) and 7 (to randomize your colors almost beyond use). 3 is a good starting point.

That’s all for this screen. Press Enter for these parameters and the next and final screen will appear (honestly!).

This one deals with all the aspects of light source and Targa files.

You must choose the direction of the light from the light source. This will be scaled in the x, y, and z directions the same as the image. For example, 1,1,3 positions the light to come from the lower right front of the screen in relation to the untransformed image. It is important to remember that these coordinates are scaled the same as your image. Thus, "1,1,1" positions the light to come from a direction of equal distances to the right, below and in front of each pixel on the original image. However, if the x,y,z scale is set to 90,90,30 the result will be from equal distances to the right and below each pixel but from only 1/3 the distance in front of the screen i.e.. it will be low in the sky, say, afternoon or morning.

Then you are asked for a smoothing factor. Unless you used Continuous Potential when generating the starting image, the illumination when using light source fills may appear "sparkly", like a sandy beach in bright sun. A smoothing factor of 2 or 3 will allow you to see the large-scale shapes better.

Smoothing is primarily useful when doing light source fill types with plasma clouds. If your fractal is not a plasma cloud and has features with sharply defined boundaries (e.g. Mandelbrot Lake), smoothing may cause the colors to run. This is a feature, not a bug. (A copyrighted response of [your favorite commercial software company here], used by permission.)

The ambient option sets the minimum light value a surface has if it has no direct lighting at all. All light values are scaled from this value to white. This effectively adjusts the depth of the shadows and sets the overall contrast of the image.

If you selected the full color option, you have a few more choices. The next is the haze factor. Set this to make distant objects more hazy. Close up objects will have little effect, distant objects will have most. 0 disables the function. 100 is the maximum effect, the farthest objects will be lost in the mist. Currently, this does not really use distance from the viewer, we cheat and use the y value of the original image. So the effect really only works if the y-rotation (set earlier) is between +/- 30.

Next, you can choose the name under which to save your Targa file. If you have not set "overwrite=yes" then the file name will be incremented to avoid over-writing previous files. If you are going to overlay an existing Targa file, enter its name here.

Next, you may select the background color for the Targa file. The default background on the Targa file is sky blue. Enter the Red, Green, and Blue component for the background color you wish.

Finally, absolutely the last option (this time we mean it): you can now choose to overlay an existing Targa-24, type 2, non mapped, top-to- bottom file, such as created by Id or PVRay. The Targa file specified above will be overlayed with new info just as a GIF is overlayed on screen. Note: it is not necessary to use the O overlay command to overlay Targa files. The targa_overlay parameter must be set to yes, however.

You’ll probably want to adjust the final colors for monochrome fill types using light source via color cycling. Try one of the more continuous palettes (F8 through F10), or load the gray palette with the Alternate-map command.

Now, lie down for a while in a quiet room with a damp washcloth on your forehead. Feeling better? Good — because it’s time to go back almost to the top of the 3D options and just say yes to:

Picture a globe lying on its side, "north" pole to the right. (It’s our planet, and we’ll position it the way we like.) You will be mapping the X and Y axes of the starting image to latitude and longitude on the globe, so that what was a horizontal row of pixels follows a line of longitude. The defaults exactly cover the hemisphere facing you, from longitude 180 degrees (top) to 0 degrees (bottom) and latitude -90 (left) to latitude 90 (right). By changing them you can map the image to a piece of the hemisphere or wrap it clear around the globe.

The next entry is for a radius factor that controls the over-all size of the globe. All the rest of the entries are the same as in the landscape projection. You may want less surface roughness for a plausible look, unless you prefer small worlds with big topography, a la "The Little Prince."

While the 3 command (see "3D" Images) creates its image on a blank screen, the # (or Shift+3) command draws a second image over an existing displayed image. This image can be any restored image from a R command or the result of a just executed 3 command. So you can do a landscape, then press # and choose spherical projection to re-plot that image or another as a moon in the sky above the landscape. # can be repeated as many times as you like.

It’s worth noting that not all that many years ago, one of us watched Benoit Mandelbrot and fractal-graphics wizard Dick Voss creating just such a moon-over-landscape image at IBM’s research center in Yorktown Heights, NY. The system was a large and impressive mainframe with floating-point facilities, running LBLGRAPH — what Mandelbrot calls "an independent-minded and often very ill-mannered heap of graphics programs that originated in work by Alex Hurwitz and Jack Wright of IBM Los Angeles."

We’d like to salute LBLGRAPH, its successors, and their creators, because it was their graphic output (like "Planetrise over Labelgraph Hill", plate C9 in Mandelbrot’s "Fractal Geometry of Nature") that helped turn fractal geometry from a mathematical curiosity into a phenomenon. We’d also like to point out that it wasn’t as fast, flexible or pretty as Id. Now, a lot of the difference has to do with the incredible progress of micro-processor power since then, so a lot of the credit should go to Intel rather than to our highly tuned code. OK, twist our arms — it is awfully good code.

If you enjoy using Id for making landscapes, we have several features for you to work with. When doing 3D transformations, banding tends to occur because all pixels of a given height end up the same color. Now, colors can be randomized to make the transitions between different colors at different altitudes smoother. Use the "randomize=n" parameter to accomplish this. If your light source images all look like lunar landscapes since they are all monochrome and have very dark shadows, we now allow you to set the ambient light for adjusting the contrast of the final image. Use the "ambient=n" parameter. In addition to being able to create scenes with light sources in monochrome, you can now do it in full color as well. Setting the parameter "fullcolor=1" will generate a Targa-24 file with a full color image which will be a combination of the original colors of the source image (or map file if you select map=something) and the amount of light which reflects off a given point on the surface. Since there can be 256 different colors in the original image and 256 levels of light, you can now generate an image with lots of colors.

Using the full color option allows you to also set a haze factor with the "haze=n" parameter to make more distant objects more hazy.

As a default, full color files also have the background set to sky blue. The file is always created on disk. Try the following settings of the new parameters in sequence to get a feel for the effect of each one: ; use this with any filltype map=topo randomize=3 ; adjusting this smooths color transitions

When full color is being used, the image you see on the screen will represent the amount of light being reflected, not the colors in the final image. Don’t be disturbed if the colors look weird, they are an artifact of the process being used. The image being created in the lightfile won’t look like the screen.

However, if you are worried, hit Esc several times and when Id gets to the end of the current line it will abort. Your partial image will be there as light001.tga or with whatever file name you selected with the lightname option. Examine it and adjust any parameters you are not happy with. Its a little awkward, but we haven’t figured out a better way — yet.

Bruce Goren, a stereoscopic maven, contributed these tips on what to do with your 3D images. (Bruce inspired and prodded us so much we automated much of what follows, allowing both this and actual on screen stereo viewing, but we included it here for reference and a brief tutorial.)

"I move the viewport or imaginary camera left and right to create two separate views of the stationary object in x,y,z, space. The distance between the two views, known as the inter-ocular distance, toe-in or convergence angle, is critical. It makes the difference between good 3- D and headache-generating bad 3-D.

"For a 3D fractal landscape, I created and photographed the left and right eye views as if flying by in an imaginary airplane and mounted the film chips for stereo viewing. To make my image, first I generated a plasma cloud based on a color map I calculated to resemble a geological survey map. In the 3D reconstruction, I used a perspective value of 150 and shifted the camera -15 and +15 on the X-axis for the left and right views. All other values were left to the defaults.

"The images are captured on a Matrix 3000 film recorder — basically a box with a high-resolution black and white TV and a 35mm film camera (Konica FS-1) looking at the TV screen through a filter wheel. I glass mount the film chips myself. "Each frame is exposed three times, once through each of the red, blue, and green filters to create a color image from computer video without the scan-lines which normally result from photographing television screens. The aspect ratio of the resulting images led me to mount the chips using the 7-sprocket Busch-European Emde masks."

(Also see "Ray Tracing Output", "Brief", and "Output File Name" in 3D Mode Selection.)

Id allows you to save your 3D transforms in files which may be fed to a ray tracer (or to "Acrospin"). However, they are not ready to be traced by themselves. For one thing, no light source is included. They are actually meant to be included within other ray tracing files.

Since the intent is to produce an object which may be included in a larger ray tracing scene, it is expected that all rotations, shifts, and final scaling will be done by the ray tracer. Thus, in creating the images, no facilities for rotations or shifting is provided. Scaling is provided to achieve the correct aspect ratio.

WARNING! The files created using the ray tracing options can be large. Setting coarse to 40 will result in over 2000 triangles. Each triangle can utilize from 50 to 200 bytes each to describe, so your ray tracing files can rapidly approach or exceed 1 MB.

Each file starts with a comment identifying the version of Id by which it was created. The file ends with a comment giving the number of triangles in the file.

The files consist of long strips of adjacent triangles. Triangles vertices are listed in clockwise or counter clockwise order depending on the target ray tracer. Currently, MTV and Rayshade are the only ones which use counter clockwise order. The size of the triangles is set by the coarse setting in the main 3D menu. Color information about each individual triangle is included for all files unless in the brief mode.

To keep the poor ray tracer from working too hard, if waterline is set to a non zero value, no triangle which lies entirely at or below the current setting of waterline is written to the ray tracing file. These may be replaced by a simple plane in the syntax of the ray tracer you are using.

Id’s coordinate system has the origin of the x-y plane at the upper left hand corner of the screen, with positive x to the right and positive y down. The ray tracing files have the origin of the x-y plane moved to the center of the screen with positive x to the right and positive y up. Increasing values of the color index are out of the screen and in the +z direction. The color index 0 will be found in the xy plane at z=-1.

When x, y and z scale are set to 100, the surface created by the triangles will fall within a box of +/- 1.0 in all 3 directions. Changing scale will change the size and/or aspect ratio of the enclosed object. We will only describe the structure of the raw format here. If you want to understand any of the ray tracing file formats besides raw, please see your favorite ray tracer docs.

The raw format simply consists of a series of clockwise triangles. If brief=yes, Each line is a vertex with coordinates x, y, and z. Each triangle is separated by a couple of CR’s from the next. If brief=no, the first line in each triangle description if the r,g,b value of the triangle.

Setting brief=yes produces shorter files with the color of each triangle removed - all triangles will be the same color. These files are otherwise identical to normal files but will run faster than the non brief files. Also, with brief=yes, you may be able to get files with more triangles to run than with brief=no.

The DKB format is now obsolete. POV-Ray users should use the raw output and convert to POV-Ray using the POV Group’s RAW2POV utility. POV-Ray users can also do all 3D transformations within POV-Ray using height fields.

Id accepts command-line parameters that allow you to start it with a particular video mode, fractal type, starting coordinates, and just about every other parameter and option.

These parameters can also be specified in a sstools.ini file, to set them every time you run Id.

They can also be specified as named groups in a .par (parameter) file which you can then call up while running Id by using the @ command.

In all three cases (command line, sstools.ini, and parameter file) the parameters use the same syntax, usually a series of keyword=value commands like sound=off. Each parameter is described in detail in subsequent sections.

You can specify parameters when you start Id by using a command like:

The individual parameters are separated by one or more spaces (an parameter itself may not include spaces). Upper or lower case may be used, and parameters can be in any order.

Id has a special command you can use when you have a lot of startup parameters (or have a set of parameters you use frequently):

When @filename is specified on the command line, Id reads parameters from the specified file as if they were keyed on the command line. You can create the file with a text editor, putting one "keyword=value" parameter on each line.

Every time Id runs, it searches the current directory, and then the directories in your PATH, for a file named sstools.ini. If it finds this file, it begins by reading parameters from it. This file is useful for setting parameters you always want.

The file sstools.ini is divided into sections belonging to particular programs. Each section begins with a label in brackets. Id looks for the label [id], and ignores any lines it finds in the file belonging to any other label. If an sstools.ini file looks like this:

You can change parameters on-the-fly while running Id by using the @ or 2 command and a parameter file. Parameter files contain named groups of parameters, looking something like this:

If you use the @ or 2 command and select a parameter file containing the above example, Id will show two choices: quickdraw and slowdraw. You move the cursor to highlight one of the choices and press Enter to set the parameters specified in the file by that choice.

The default parameter file name is id.par. A different file can be selected with the "parmfile=" option, or by using @ or 2 and then hitting F6.

You can create parameter files with a text editor, or for some uses, by using the B command. Parameter files can be used in a number of ways, some examples:

Formulas, ifs, and lsystem entries referred to in a parameter entry can be included in a .par file by adding the prefix frm:, ifs:, or lsys: respectively, for example frm:myformula {rest of that formula}. Note that the prefix is a label, not part of the formula name, so the reference in the image entry would be formulaname=myformula. The formula, ifs, and lsystem entries added to a parfile are accessed only when the image entry in the parfile is run. To make these formulas generally accessible, they must be added to a .frm, .ifs or .l file (without the identifying prefix, of course). See Parameter Save/Restore Commands for details about the @ and B commands.

Parameters must be separated by one or more spaces.

Upper and lower case can be used in keywords and values. In the parameter reference that follows, the name is shown in upper case. When mentioned in other contexts the name is generally shown in lower case.

Anything on a line following a ; (semi-colon) is ignored, i.e. is a comment.

In parameter files and sstools.ini: * Individual parameters can be entered on separate lines. * Long values can be split onto multiple lines by ending a line with a \ (backslash) - leading spaces on the following line are ignored, the information on the next line from the first non-blank character onward is appended to the prior line.

Some terminology: KEYWORD=nnn enter a number in place of "nnn" KEYWORD=[filename] you supply filename KEYWORD=yes|no|whatever choose one of "yes", "no", or "whatever" KEYWORD=1st[/2nd[/3rd]] the slash-separated parameters "2nd" and "3rd" are optional

@FILENAME Causes Id to read "filename" for parameters. When it finishes, it resumes reading its own command line — i.e., "id maxiter=250 @myfile passes=1" is legal. This option is only valid on the command line, as Id is not clever enough to deal with multiple indirection.

@FILENAME/groupname Like @FILENAME, but reads a named group of parameters from a parameter file. See Parameter Files and the @ Command.

TEMPDIR=[directory] This command allows to specify the directory where Id writes temporary files.

WORKDIR=[directory] This command sets the directory where miscellaneous Id files get written, including makemig.bat and debugging files.

FILENAME=[name] Causes Id to read the named file, which must either have been saved from an earlier Id session or be a generic GIF file, and use that as the starting point, bypassing the initial information screens. The filetype is optional and defaults to .gif. Non-Id GIF files are restored as fractal type "plasma".

On the command line you may omit filename= and just give the file name.

CURDIR=yes Id uses directories set by various commands, possibly in the sstools.ini file. If you want to try out some files in the current directory, such as a modified copy of id.frm, you won’t Id to read the copy in your official FRM directory. Setting curdir=yes at the command line will cause Id to look in the current directory for requested files first before looking in the default directory set by the other commands. Warning: Tab screen may not reflect actual file opened in cases where the file was opened in the current directory.

MAKEPAR=parfile/entryname This command invokes a batch facility to copy fractal and color information stored in GIF files to par format. The syntax is: id filename.gif makepar=parfile.par/entryname The entryname is optional and defaults to the name of the GIF filename if absent. Other parameters can appear before the makepar= command, but anything after will ignored. If the parfile and entryname exist, the entry will replace the previous entry. If the entry doesn’t exist, it will be added. If the parfile doesn’t exist it will be created.

If you leave the GIF filename out of the command lime but add a map= command, then the makepar command will write a par named for the color map with only the colors in the par entry. This is a handy tool for converting maps into compressed par colors entry. For example, you could type: id map=lyapunov.map makepar=mycolors This adds a colors-only par entry called lyapunov.map to mycolors.par.

MAXLINELENGTH=nnn This command sets the maximum width of lines in a par entry.

COMMENT=[comment1]/[comment2]/[comment3]/[comment4] Inserts comments into par files. These comments can include variables that are expanded at the time the par file is created. Variables are indicated by $varname$. Underscore characters are expanded to blanks. If you want to include the special characters '$', '_', or '\' in a comment, precede the character with '\'. Supported variables are:

The variable $cpu$ expands to information about your CPU, such as "Intel Core i7-6600U CPU @ 2.60GHz".

You can leave any of the four comment fields unchanged by leaving that position blank. For example, the command comment=//Created_$date$ inserts the text "Created Mar 17, 2024" into the third comment.

BATCH=yes See Batch Mode.

AUTOKEY=play|record Specifying "play" runs Id in playback mode - keystrokes are read from the autokey file (see next parameter) and interpreted as if they’re being entered from the keyboard.

Specifying "record" runs Id in recording mode - all keystrokes are recorded in the autokey file. Unless overwrite=yes is specified, the autokey filename will be incremented to avoid overwriting existing files.

See also Autokey Mode.

AUTOKEYNAME=[filename] Specifies the file name to be used in autokey mode. The default file name is auto.key.

MAKEDOC[=filename] Create Id documentation file (for printing or viewing with a text editor) and then exit. Filename defaults to id.txt. There’s also a function in Id’s online help which can be used to produce the documentation file - use "Printing Id Documentation" from the main help index.

MAXHISTORY=<nnn> Id maintains a list of parameters of the past 10 images that you generated in the current Id session. You can revisit these images using the H and Ctrl+H commands. The maxhistory parameter allows you to set the number of image parameter sets stored in memory. Keep in mind that every time you color cycle or change from integer to float or back, another image parameter set is saved, so the default ten images are used up quickly.

PASSES=1|2|3|g|g1|g2|g3|g4|g5|g6|b|t|s|o Selects single-pass, dual-pass, triple-pass, solid-guessing mode, solid- guessing stop after pass n, boundary tracing, tesseral, synchronous orbits, or the orbits algorithm. See Drawing Method and Passes Parameters.

FILLCOLOR=normal|<nnn> Sets a color to be used for block fill by boundary tracing and tesseral algorithms. See Drawing Method.

FLOAT=yes Most fractal types have both a fast integer math and a floating point version. The faster, but possibly less accurate, integer version is the default. The default is to use integer math, but in this age of powerful CPUS we now recommend your making float=yes the default by adding this line to your sstools.ini file. This sstools.ini file distributed with Iterated Dynamics has this setting. Also see Limitations of Integer Math (and How We Cope).

SYMMETRY=xxx Forces symmetry to none, X axis, Y axis, XY axis, origin, or pi symmetry. Useful as a speedup for symmetrical fractals. This is not a kaleidoscope feature for imposing symmetry where it doesn’t exist. Use only when the fractal actual exhibits the symmetry, or else results may not be satisfactory.

BFDIGITS=<nnn> Forces nnn digits if arbitrary precision used. You can use this if Id’s precision detection changes to arbitrary precision too late and regular double precision is used with poor results.

MATHTOLERANCE=<nnn>/<nnn> This commands controls the logic that automatically selects one of integer/float/arbitrary precision based on precision requirements of the current zoom depth. The first number controls the integer/float transition, and the second number controls the float/arbitrary precision transition. The default value of .05 for both means that the ratio between the exact and calculated width and height is between .95 and 1.05. A larger value than .05 (say .10) makes the test looser so that the lower precision math is used longer. A value ⇐ 0 means the test is always failed and the higher precision math type is used. A value >= 1 means that the test is always passed and the lower precision math type is used.

MINSTACK=<nnn> This sets the minimum number of stack bytes required for passes=s in order to do another SOI recursion. If you get bad results, try setting this to a value above the default value of 1100. If the value is too large, the image will be OK but generation will be slower.

TYPE=[name] Selects the fractal type to calculate. The default is type "mandel".

PARAMS=n/n/n/n…​ Set optional (required, for some fractal types) values used in the calculations. These numbers typically represent the real and imaginary portions of some startup value, and are described in detail as needed in Fractal Types. (Example: "id type=julia params=-0.48/0.626" would wait at the opening screen for you to select a video mode, but then proceed straight to the Julia set for the stated x (real) and y (imaginary) coordinates.)

FUNCTION=[fn1[/fn2[/fn3[/fn4]]]] Allows setting variable functions found in some fractal type formulae. Possible values are sin, cos, tan, cotan, sinh, cosh, tanh, cotanh, exp, log, sqr, recip (i.e. 1/z), ident (i.e. identity), cosxx (cos with a bug), flip, zero, one, asin, asinh, acos, acosh, atan, atanh, sqrt, abs (abs(x)+i*abs(y)), cabs (sqrt(x*x+y*y)), and the various rounding-to- integer functions: floor (round down), ceil (round up), trunc (round toward zero), and round (round to nearest).

FORMULANAME=[formulaname] Specifies the default formula name for type=formula fractals. (That is, the name of a formula defined in the formulafile.) Required if you want to generate one of these fractal types in batch mode, as this is the only way to specify a formula name in that case.

LNAME=[lsystemname] Specifies the default L-system name. (That is, the name of an entry in the lfile.) Required if you want to generate one of these fractal types in batch mode, as this is the only way to specify an L-system name in that case.

IFS=[ifsname] Specifies the default IFS name. (That is, the name of an entry in the ifsfile.) Required if you want to generate one of these fractal types in batch mode, as this is the only way to specify an IFS name in that case.

MAXITER=nnn Reset the iteration maximum — the number of iterations at which the program gives up and says "OK, this point seems to be part of the set in question and should be colored with the inside color." — from the default 150. Values range from 2 to 2,147,483,647 (super-high iteration limits like 200000000 are useful when using logarithmic palettes). See The Mandelbrot Set for a description of the iteration method of calculating fractals. This parameter can also be used to adjust the number of orbits plotted for 3D "attractor" fractal types such as lorenz3d and kamtorus. CORNERS=[xmin/xmax/ymin/ymax[/x3rd/y3rd]] Example: corners=-0.739/-0.736/0.288/0.291 Begin with these coordinates as the range of x and y coordinates, rather than the default values of (for type=mandel) -2.0/2.0/-1.5/1.5. When you specify four values (the usual case), this defines a rectangle: x coordinates are mapped to the screen, left to right, from xmin to xmax, y coordinates are mapped to the screen, bottom to top, from ymin to ymax. Six parameters can be used to describe any rotated or stretched parallelogram: (xmin,ymax) are used for the top-left corner of the screen, (xmax,ymin) are used for the bottom-right corner, and (x3rd,y3rd) are used for the bottom-left corner. Entering just "corners=" tells Id to use this form rather than "center- mag" (see below) when saving parameters with the B command.

CENTER-MAG=[Xctr/Yctr/Mag[/Xmagfactor/rotation/skew]] This is an alternative way to enter corners as a center point and a magnification that is popular with some fractal programs and publications. Entering just "center-mag=" tells Id to use this form (the default mode) rather than "corners=" (see above) when saving parameters with the B command. The Tab status display shows the "corners" in both forms. When you specify three values (the usual case), this defines a rectangle: (Xctr, Yctr) specifies the coordinates of the center of the image while Mag indicates the amount of magnification to use. Six parameters can be used to describe any rotated or stretched parallelogram: Xmagfactor tells how many times bigger the x-magnification is than the y-magnification, rotation indicates how many degrees the image has been turned, and skew tells how many degrees the image is leaning over. Positive angles will rotate and skew the image counter-clockwise.

BAILOUT=nnn Overrides the default bailout criterion for escape-time fractals. Can also be set from the parameters screen after selecting a fractal type. See description of bailout in The Mandelbrot Set.

BAILOUTEST=mod|real|imag|or|and|manh|manr Specifies the Bailout Test used to determine when the fractal calculation has exceeded the bailout value. The default is mod and not all fractal types can utilize the additional tests.

RESET Causes Id to reset all calculation related parameters to their default values. Non-calculation parameters such as "sound=", and "savename=" are not affected. Reset should be specified at the start of each parameter file entry (used with the @ command) which defines an image, so that the entry need not describe every possible parameter - when invoked, all parameters not specifically set by the entry will have predictable values (the defaults).

INITORBIT=pixel INITORBIT=nnn/nnn Allows control over the value used to begin each Mandelbrot-type orbit. "initorbit=pixel" is the default for most types; this command initializes the orbit to the complex number corresponding to the screen pixel. The command "initorbit=nnn/nnn" uses the entered value as the initializer. See the discussion of the Mandellambda Sets for more on this topic.

RSEED=nnnn The initial random-number "seed" for plasma clouds is taken from your computer’s internal clock-timer. This argument forces a value (which you can see in the Tab display), and allows you to reproduce plasma clouds. A detailed discussion of why a truly random number may be impossible to define, let alone generate, will have to wait for "Iterated Dynamics: The 3-MB Doc File."

SHOWDOT=[auto|bright|medium|dark|<nnn>[/<size>]] Colors the current dot being calculated color <nnn> or an automatically calculated color taken from the current palette. The second parameter is the size of the traveling pointer in units of pixels of 1/1024th of a screen.

The travelling pointer may strobe or flicker with fast fractals because of interaction with the monitor’s vertical refresh. The orbitdelay parameter can be used to introduce a per-pixel delay when showdot is turned on. Try orbitdelay=1000 with "showdot=b/20" to get a feel for how the showdot triangle works.

ASPECTDRIFT=<nn> When zooming in or out, the aspect ratio (the width to height ratio) can change slightly due to rounding and the noncontinuous nature of pixels. If the aspect changes by a factor less than <nn>, then the aspect is set to it’s normal value, making the center-mag Xmagfactor parameter equal to 1. (see CENTER-MAG above.) The default is 0.01. A larger value adjusts more often. A value of 0 does no adjustment at all.

INSIDE=nnn|maxiter|bof60|bof61|zmag|epscross|startrail|period|atan|fmod Set the color of the interior: for example, "inside=0" makes the M-set "lake" a stylish basic black with the default color map. The option "maxiter" makes the inside color the same as the value of maxiter.

Eight more options reveal hidden structure inside the lake. The options "bof60" and "bof61", are named after the figures on pages 60 and 61 of "The Beauty of Fractals". The option "zmag" is a method of coloring based on the magnitude of Z after the maximum iterations have been reached. The affect along the edges of the Mandelbrot is like thin- metal welded sculpture. The option "fmod" is a method of coloring based on the magnitude of the last orbit within a set distance from the origin. The option "period" colors pixels according to the period of their eventual orbit. The option "atan" colors by determining the angle in degrees the last iterated value has with respect to the real axis, and using the absolute value. See Inside=bof60|bof61|zmag|fmod|period|atan for a brilliant explanation of what these do!

The option "epscross" colors pixels green or yellow according to whether their orbits swing close to the Y-axis or X-axis, respectively. The option "startrail" has a coloring scheme based on clusters of points in the orbits. Best with outside=<nnn>. For more information, see Inside=epscross|startrail.

Note that the "Look for finite attractor" option on the Y options screen will override the selected inside option if an attractor is found - see Finite Attractors.

OUTSIDE=nnn|iter|real|imag|summ|mult|atan|fmod|tdis The classic method of coloring outside the fractal is to color according to how many iterations were required before Z reached the bailout value, usually 4. This is the method used with the option "iter".

However, when Z reaches bailout the real and imaginary components can be at very diferent values. The options "real" and "imag" color using the iteration value plus the real or imaginary values. The option "summ" uses the sum of all these values. These options can give a startling 3D quality to otherwise flat images and can change some boring images to wonderful ones. The option "mult" colors by multiplying the iteration by real divided by imaginary. There was no mathematical reason for this, it just seemed like a good idea. The option "atan" colors by determining the angle in degrees the last iterated value has with respect to the real axis, and using the absolute value.

The option "fmod" colors pixels according to the magnitude of the last orbit point which is within a set distance from the origin. Then: color = magnitude * colors / closeprox The magnitude used for the comparison is now based on the same calculation as is used for the bailout test. The value of closeprox can be varied interactively. This feature was contributed by Iain Stirling. There is a problem with the mandel fractal type when "outside=fmod" is used with "inside=bof6x" and bailoutest set to "real", "imag", or "manr". This is likely due to changes made in the code so that bof images could be reproduced. Select a different fractal type that produces the default mandel image to explore using these parameters.

The option "tdis" colors the pixels according to the total distance traveled by the orbit. This feature was suggested by Steve Robinson.

The option "nnn" sets the color of the exterior to some number of your choosing: for example, "outside=1" makes all points not inside the fractal set to color 1 (blue in the default color map). Note that defining an outside color forces any image to be a two-color one: either a point is inside the set, or it’s outside it.

MAP=filename Reads in a replacement color map from filename. This map replaces the default color map. The difference between this argument and an alternate map read in via L in color-command mode is that this one applies to the entire run. See Color Maps.

COLORS=@filename|colorspecification Sets colors for the current image, like the L function in color cycling and palette editing modes. Unlike the "map=" parameter, colors set with "colors=" do not replace the default - when you next select a new fractal type, colors will revert to their defaults. The option "@filename" tells Id to use a color map file named "filename". See Color Maps.

The option "colorspecification" specifies the colors directly. The value of "colorspecification" is rather long (768 characters for 256 color modes), and its syntax is not documented here. This form of the "colors=" parameter is not intended for manual use - it exists for use by the B command when saving the description of a nice image.

RECORDCOLORS=auto|comment|yes Controls the method of writing colors in par files. The option "auto" causes the colors to be written in the "colors=@mapfile" form if the colors were loaded from a map. Use this mode if you manage your colors using map files. If you share par files with others, and have trouble remembering to send them the map file, use the option "comment" or "yes". These modes force the writing of compressed color maps in the par file in all cases. The only difference is that the comment option also writes the map filename in a comment so you can remember where the colors came from.

CYCLERANGE=nnn/nnn Sets the range of color numbers to be animated during color cycling. The default is 1/255, i.e. just color number 0 (usually black) is not cycled.

CYCLELIMIT=nnn Sets the speed of color cycling. Technically, the number of color values updated during a single update. Legal values are 1 - 256; the default is 55.

TEXTCOLORS=mono Set text screen colors to simple black and white.

TEXTCOLORS=aa/bb/cc/…​ Set text screen colors. Omit any value to use the default (e.g. textcolors=////50 to set just the 5th value). Each value is a 2 digit hexadecimal value; 1st digit is background color (from 0 to 7), 2nd digit is foreground color (from 0 to F). Color values are: 0 black 8 gray 1 blue 9 light blue 2 green A light green 3 cyan B light cyan 4 red C light red 5 magenta D light magenta 6 brown E yellow 7 white F bright white

31 colors can be specified, their meanings are as follows: Heading: 1 Iterated Dynamics version info 2 heading line development info (not used in released version) Help: 3 sub-heading 4 main text 5 instructions at bottom of screen 6 hotlink field 7 highlighted (current) hotlink Menu, Selection Boxes, Parameter Input Boxes: 8 background around box and instructions at bottom 9 emphasized text outside box 10 low intensity information in box 11 medium intensity information in box 12 high intensity information in box (e.g. heading) 13 current keyin field 14 current keyin field when it is limited to one of n values 15 current choice in multiple choice list 16 speed key prompt in multiple choice list 17 speed key keyin in multiple choice list General (Tab Key Display, IFS parameters, "Thinking" Display): 18 high intensity information 19 medium intensity information 20 low intensity information 21 current keyin field Disk Video: 22 background around box 23 high intensity information 24 low intensity information Diagnostic Messages: 25 error 26 information Credits Screen: 27 bottom lines 28 high intensity divider line 29 low intensity divider line 30 primary authors 31 contributing authors The default is textcolors=1F/1A/2E/70/28/71/31/78/70/17/1F/1E/2F/3F/5F/07/ 0D/71/70/78/0F/70/0E/0F/4F/20/17/20/28/0F/07 (In a real command file, all values must be on one line.)

OLDDEMMCOLORS=yes|no Sets the old coloring scheme used with the distance estimator method.

TRUECOLOR=yes You can save either the default color scheme or the iteration escape value to a file called fract001.tga. The number is incremented each time a file is saved unless the parameter overwrite is set to yes. This will allow experimentation with truecolor algorithms. Someday we’ll have real truecolor support…​

TRUEMODE=def|iter Determines whether the fract001.tga file produced when "truecolor=yes" contains the iteration value or the default coloring scheme.

NOBOF=yes|no Setting this parameter to yes causes the bof60 and bof61 inside options to function the same as the other inside options by making the per pixel initialization the same. The per pixel initialization is normally different for the bof60 and bof61 options to reproduce the images in the book, "The Beauty of Fractals". The default is no.

LOGMAP=yes|old|n Selects a compressed relationship between escape-time iterations and palette colors. See Logarithmic Palettes and Color Ranges for details.

LOGMODE=fly/table|auto Forces the use of the on-the-fly routine or the logarithm table for the calculation of log palettes. Not normally needed. The auto option cannot be used at the same time as the other two. Auto causes the logmap value to be automatically recalculated when zooming. Changing almost anything will turn this feature off. Set logmode=auto from the G screen prompt.

RANGES=nn/nn/nn/…​ Specifies ranges of escape-time iteration counts to be mapped to each color number. See Logarithmic Palettes and Color Ranges for details.

DISTEST=nnn/nnn A nonzero value in the first parameter enables the distance estimator method. The second parameter specifies the "width factor" and defaults to 71. See Distance Estimator Method for details.

DECOMP=2|4|8|16|32|64|128|256 Invokes the corresponding decomposition coloring scheme. See Decomposition for details.

BIOMORPH=nnn Turn on biomorph option; set affected pixels to color nnn. See Biomorphs for details.

POTENTIAL=maxcolor[/slope[/modulus[/16bit]]] Enables the continuous potential coloring mode for all fractal types except plasma clouds, attractor types such as lorenz, and IFS. The four arguments define the maximum color value, the slope of the potential curve, the modulus bailout value, and whether 16 bit values are to be calculated. Example: "potential=240/2000/40/16bit". The Mandelbrot and Julia types ignore the modulus bailout value and use their own hardwired value of 4.0 instead. See Continuous Potential for details.

INVERT=nn/nn/nn Turns on inversion. The parameters are radius of inversion, x- coordinate of center, and y-coordinate of center. -1 as the first parameter sets the radius to 1/6 the smaller screen dimension; no x/y parameters defaults to center of screen. The values are displayed with the Tab command. See Inversion for details.

FINATTRACT=no|yes Another option to show coloring inside some Julia "lakes" to show escape time to finite attractors. Works with lambda, magnet types, and possibly others. See Finite Attractors for more information.

EXITNOASK=yes This option forces Id to bypass the final "are you sure?" exit screen when the Esc key is pressed from the main image-generation screen. Added at the request of Ward Christensen. It’s his funeral <grin>.

In Id you can use various filename variables to specify files, set default directories, or both. For example, in the savename description below, [name] can be a filename, a directory name, or a fully qualified pathname plus filename. You can specify default directories using these variables in your sstools.ini file.

SAVEDIR=<path> Sets the directory used when writing output files. The "savename" parameter may use a relative path to the value of the "savedir" parameter if savedir is specified first.

SAVENAME=[<path>\][name] Set the path and/or filename to use when you Save a screen. The default filename is fract001. The .gif extension is optional (Example: "savename=myfile")

OVERWRITE=no|yes Sets the savename overwrite flag (default is no). If yes, saved files will over-write existing files from previous sessions; otherwise the automatic incrementing of fract001.gif will find the first unused filename.

SAVETIME=nnn Tells Id to automatically do a save every nnn minutes while a calculation is in progress. This is mainly useful with long batches - see Batch Mode.

DITHER=yes Dither a color file into two colors for monochrome display. This gives a poor-quality display of gray levels.

PARMFILE=[<path>\][parmfilename] Specifies the default parameter path and/or file to be used by the @ (or 2) and B commands. If not specified, the default is id.par.

FORMULAFILE=[<path>\][formulafilename] Specifies the formula path and/or file for type=formula fractals (default is id.frm). Handy if you want to generate one of these fractal types in batch mode.

LFILE=[<path>\][lsystemfile] Specifies the default L-system path and/or file for type=lsystem fractals (default is id.l).

IFSFILE=[<path>\][ifsfilename] Specifies the default path and/or file for type=ifs fractals (default is id.ifs).

FILENAME=[.suffix] Sets the default file extension used for the R command. When this parameter is omitted, the default file mask shows .gif and .pot files. You might want to specify this parameter and the SAVENAME= parameter in your sstools.ini file if you keep your fractal images separate from other .gif files by using a different suffix for them.

ORBITSAVE=yes Causes the orbits file to be opened and the points generated by orbit fractals or IFS fractals to be saved in a raw format. The file will be overwritten if "overwrite=yes". Otherwise, each time a new fractal is generated a new file is written with this option. (see Barnsley IFS Fractals Orbit Fractals).

ORBITSAVENAME=[filename] Sets the name of the orbit file to be written when "orbitsave=yes" is used. Defaults to orbits.raw.

VIDEO=xxx Set the initial video mode (and bypass the informational screens). Handy for batch runs. (Example: "video=f4") You can obtain the current video values (key assignments) from the "Select Video Mode" screen inside Id. If you want to do a batch run with a video mode which isn’t currently assigned to a key, you’ll have to modify the key assignments - see Video Mode Function Keys.

ASKVIDEO=yes|no If "no", this eliminates the prompt asking you if a file to be restored is OK for your current video hardware. VIEWWINDOWS=xx[/xx[/yes|no[/nn[/nn]]]] Set the reduction factor, final media aspect ratio, crop starting coordinates (y/n), explicit x size, and explicit y size, see View Window .

FASTRESTORE=yes|no If "yes", resets viewwindow to "no" prior to restoring a GIF file. Otherwise, images saved in full view will be drawn in reduced view if viewwindows has been set to "yes" previously. Also, when "yes", bypasses the warning when restoring a GIF in a video mode other than the one in which the GIF was saved. Default is "no". This feature is useful when cycling through a group of GIFs in autokey mode. When combined with "askvideo=no", allows loading images with the last successfully used video mode. This is handy when viewing 1600x1200 images when you only have 1024x768 available.

VIRTUAL=yes|no With a suitable video mode it is possible to set virtual screen modes using the View Window options. With certain video modes it may be necessary to disable the check for virtual screen modes if this check prevents Id from loading correctly. The default is "yes". Setting this to "no" disables the check for and the ability to use virtual screen sizes.

SOUND=off|beep|x|y|z/pc|fm/quant We’re all much too busy to waste time with Id at work, and no doubt you are too, so "sound=off" is included only for use at home, to avoid waking the kids or your significant other, late at night. (By the way, didn’t you tell yourself "just one more zoom on LambdaSine" an hour ago?) Suggestions for a "boss" hot-key will be cheerfully ignored, as this sucker is getting big enough without including a spreadsheet screen too. The "sound=x|y|x" options are for the attractor fractals, like the Lorenz fractals - they play with the sound as they are generating an image, based on the X or Y or Z co-ordinate they are displaying at the moment.

You can now hear the sound of fractal orbits—​just turn on sound from the command line, the X menu, or the Ctrl+F menu, fire up a fractal, and try the Orbits command (or set "showorbit=yes"). Use the "orbitdelay=<nnn>" parameter (also on the Ctrl+F menu) to dramatically alter the effect, which ranges from an unearthly scream to a series of discrete tones. Not recommended when people you have to live with are nearby! Remember, we don’t promise that it will sound beautiful! There is also an option to quantize the notes generated by Id. See Sound Controls.

You can also "hear" any image that Id can decode; turn on sound before using R to read in a GIF file. We have no idea if this feature is useful. It was inspired by the comments of an on-line friend who is blind. We solicit feedback and suggestions from anyone who finds these sound features interesting or useful. The orbitdelay parameter also affects the sound of decoding images. HERTZ=<nnn> Adjusts the sound produced by the "sound=x|y|z" option. The actual sounds produced are limited to the range of 20-5000 Hz. Setting a negative Hertz value allows shifting the range of sounds produced down into the bass range. This also eliminates some of the notes since anything under 20 Hz or over 5000 Hz will not be played.

ORBITDELAY=<nn> Slows up the display of orbits using the O command for folks with hot new computers. Units are in 1/10000 seconds per orbit point. ORBITDELAY=10 therefore allows you to see each pixel’s orbit point for about one millisecond. For best display of orbits, try "passes=1" and a moderate resolution such as 900x600. Note that the first time you press the O key with the orbitdelay function active, your computer will pause for a half-second or so to calibrate a high-resolution timer.

SHOWORBIT=yes|no Causes the during-generation orbits feature, toggled by the O command, to start off in the "on" position each time a new fractal calculation starts.

ORBITSAVE=sound This option causes the hertz value played with sound=x|y|z option to be written to a file "sound.txt" in the current directory. Bill Jemison has made some intriguing music with this option.

To stay out of trouble, specify all the 3D parameters, even if you want to use what you think are the default values. It takes a little practice to learn what the default values really are. The best way to create a set of parameters is to use the B command on an image you like and then use an editor to modify the resulting parameter file.

3D=Yes 3D=Overlay Resets all 3D parameters to default values. If "filename=" is given, forces a restore to be performed in 3D mode (handy when used with "batch=yes" for batch-mode 3D images). If specified, "3d=yes" should come before any other 3D parameters on the command line or in a parameter file entry. The form "3d=overlay" is identical except that the previous graphics screen is not cleared, as with the # (Shift+3) overlay command. Useful for building parameter files that use the 3D overlay feature.

The parameters below override the 3D defaults: PREVIEW=yes Turns on 3D preview default mode SHOWBOX=yes Turns on 3D showbox default mode COARSE=nn Sets Preview coarseness default value SPHERE=yes Turns on spherical projection mode STEREO=n Selects the type of stereo image creation RAY=nnn selects raytrace output file format BRIEF=yes selects brief or verbose file for DKB output USEGRAYSCALE=yes use grayscale as depth instead of color number

INTEROCULAR=nn Sets the interocular distance for stereo CONVERGE=nn Determines the overall image separation CROP=nn/nn/nn/nn Trims the edges off stereo pairs BRIGHT=nn/nn Compensates funny glasses filter parameters LONGITUDE=nn/nn Longitude minimum and maximum LATITUDE=nn/nn Latitude minimum and maximum RADIUS=nn Radius scale factor ROTATION=nn[/nn[/nn]] Rotation about x, y and z axes SCALEZYZ=nn/nn/nn X, y and z scale factors ROUGHNESS=nn Same as z scale factor WATERLINE=nn Colors nn and below will be "inside" color FILLTYPE=nn 3D filltype PERSPECTIVE=nn Perspective distance XYSHIFT=nn/nn Shift image in x and y directions with perspective LIGHTSOURCE=nn/nn/nn Coordinates for light-source vector SMOOTHING=nn Smooths images in light-source fill modes TRANSPARENT=min/max Defines a range of colors to be treated as transparent when # overlaying 3D images. XYADJUST=nn/nn This shifts the image in the x/y dir without perspective

Below are commands that support Marc Reinig’s terrain features.

RANDOMIZE=nnn (0 - 100) This feature randomly varies the color of a pixel to near by colors. Useful to minimize map banding in 3D transformations. Usable with all filltypes. "0" disables, the maximum value is 7. Try 3 - 5.

AMBIENT=nnn (0 - 100) Set the depth of the shadows when using full color and light source filltypes. "0" disables the function, higher values lower the contrast.

FULLCOLOR=yes Valid with any light source filltype. Allows you to create a Targa-24 file which uses the color of the image being transformed or the map you select and shades it as you would see it in real life. Well, its better than B&W. A good map file to use is topo.map.

HAZE=nnn (0 - 100) Gives more realistic terrains by setting the amount of haze for distant objects when using full color in light source FILLTYPES. Works only in the "y" direction currently, so don’t use it with much y rotation. Try "rotation=85/0/0". 0 disables.

BACKGROUND=nn/nn/nn Sets the background color of the Targa-24 file by setting the red, green, and blue values (rr/gg/bb).

LIGHTNAME=<filename> The name of the Targa-24 file to be created when using full color with light source. Default is light001.tga. If "overwrite=no" (the default), the file name will be incremented until an unused filename is found. Background in this file will be the color set by background=r/g/b, the default is sky blue.

STEREOWIDTH=<nnn> This parameter allows you to specify the width in inches of the image for the purpose of getting the correct stereo effect when viewing RDS images. See Random Dot Stereograms (RDS).

It is possible, believe it or not, to become so jaded with the screen drawing process, so familiar with the types and options, that you just want to hit a key and do something else until the final images are safe on disk. To do this, start Id with the "batch=yes" parameter. To set up a batch run with the parameters required for a particular image you might: * Find an interesting area. Note the parameters from the Tab display. Then use an editor to write a batch file. * Find an interesting area. Set all the options you’ll want in the batch run. Use the B command to store the parameters in a file. Then use an editor to add the additional required batch mode parameters (such as "video=") to the generated parameter file entry. Then run the batch using "id @myname.par/myentry" (if you told the B command to use file "myname" and to name the entry "myentry").

Another approach to batch mode calculations, using "filename=" and resume, is described later.

When modifying a parameter file entry generated by the B command, the only parameters you must add for a batch mode run are "batch=yes", and "video=xxx" to select a video mode. You might want to also add "savename=[name]" to name the result as something other than the default fract001.gif. Or, you might find it easier to leave the generated parameter file unchanged and add these parameters by using a command like:

The parameter "batch=yes" tells Id to run in batch mode — that is, Id draws the image using whatever other parameters you specified, then acts as if you had hit S to save the image, then exits.

The parameter "filename=" can be used with "batch=yes" to resume calculation of an incomplete image. For instance, you might interactively find an image you like; then select some slow options (a high resolution disk video mode, distance estimator method, high maxiter, or whatever); start the calculation; then interrupt immediately with a Save. Rename the save file (fract001.gif if it is the first in the session and you didn’t name it with the X options or "savename=") to xxx.gif. Later you can run Id in batch mode to finish the job:

The parameter "savetime=nnn" is useful with long batch calculations, to store a checkpoint every nnn minutes. If you start a many hour calculation with say "savetime=60", and a power failure occurs during the calculation, you’ll have lost at most an hour of work on the image. You can resume calculation from the save file as above. Automatic saves triggered by savetime do not increment the save file name. The same file is overwritten by each auto save until the image completes. But note that Id does not directly over-write save files. Instead, each save operation writes a temporary file id.tmp, then deletes the prior save file, then renames id.tmp to be the new save file. This protects against power failures which occur during a save operation - if such a power failure occurs, the prior save file is intact and there’s a harmless incomplete id.tmp on your disk.

If you want to spread a many-hour image over multiple bits of free machine time you could use a command like:

When the savetime parameter is negative, Id will save the image after the requested time and exit. This is useful in batch files where you want to generate several images with a time limit on each image.

While running a batch file, pressing any key will cause Id to exit with a status code of 2. Any error that interrupts an image save to disk will cause an exit with status code 2. Any error that prevents an image from being generated will cause an exit with status code 1.

The savetime= parameter, and batch resumes of partial calculations, only work with fractal types which can be resumed. See Interrupting and Resuming for information about non-resumable types.

This Screen enables you to control Id’s built in file browsing utility. If you don’t know what that is see Browse Commands. This screen is selected with Ctrl+B from just about anywhere.

"Autobrowsing" Select yes if you want the loaded image to be scanned for sub images immediately without pressing 'L' every time.

"Ask about GIF video mode" Allows turning on and off the display of the video mode table when loading GIFs. This has the same effect as the askvideo= command.

"Type/Parm check" Select whether the browser tests for fractal type or parms when deciding whether a file is a sub image of the current screen or not. DISABLE WITH CAUTION! or things could get confusing. These tests can be switched off to allow such situations as wishing to display old images that were generated using a formula type which is now implemented as a built in fractal type. "Confirm deletes" Set this to No if you get fed up with the double prompting that the browser gives when deleting a file. It won’t get rid of the first prompt however.

"Smallest window" This parameter determines how small the image would have to be onscreen before the browser decides not to include it in the selection of files. The size is entered in decimal pixels so, for instance, this could be set to 0.2 to allow images that are up to around three maximum zooms away (depending on the current video resolution) to be loaded instantly. Set this to 0 to enable all sub images to be detected. This can lead to a very cluttered screen! The primary use is in conjunction with the search file mask (see below) to allow location of high magnification images within an overall view (like the whole Mandelbrot set).

"Smallest box" This determines when the image location is shown as crosshairs rather than a rather small box. Set this according to how good your eyesight is (probably worse than before you started staring at fractals all the time :-)) or the resolution of your screen. WARNING the crosshairs routine centers the cursor on one corner of the image box at the moment so this looks misleading if set too large. "Search Mask" Sets the file name pattern which the browser searches, this can be used to search out the location of a file by setting this to the filename and setting smallest image to 0 (see above).

PERIODICITY=no|show|nnn Controls periodicity checking (see Periodicity Logic). "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. Note: "type=lambdafn" with "function=exp" needs periodicity turned off to be accurate — there may be other cases.

A non-zero value of the "periodicity=" option causes "passes=o" to not plot orbits that have reached the bailout conditions or where an orbit goes off the visible area of the image. A zero value of periodicity will plot all orbits except as modified by orbitdelay and orbitinterval.

ORBITDELAY=<nn> This option controls how many orbits are computed before the orbits are displayed on the screen when using the "passes=o" option, or the fractal types mandelcloud and dynamic. This allows the orbits to settle down before plotting starts.

This option also slows down the display of orbits using the O command for folks with hot new computers. Units are in 1/10000 seconds per orbit point. "orbitdelay=10" therefore allows you to see each pixel’s orbit point for about one millisecond. For best display of orbits, try "passes=1" and a moderate resolution such as 800x600. Note that the first time you press the O key with the orbitdelay function active, your computer will pause for a half-second or so to calibrate a high- resolution timer.

ORBITINTERVAL=<nn> This parameter causes "passes=o" to plot every nth orbit point ranging from 1, which plots every orbit, to 255, which plots every 255th orbit. This value must be lower than the value of maxit to make any sense.

SCREENCOORDS=yes|no This parameter maintains the screen coordinates and lets you zoom into an image changing the coordinates of the line or rectangle used to generate the image, but keeps the display coordinates the same. The screen coordinates can be zoomed, rotated, and skewed using the F2 Screen Coordinates Screen. If set to no, the screen and image coordinates are maintained the same when an image is zoomed.

ORBITDRAWMODE=rect|line The rect(angle) method plots the orbits in a rectangle that can be zoomed, rotated, and skewed using the F6 Image Coordinates Screen, and the straight line method plots the orbits between two points specified on the F6 image coordinates screen.

You can directly enter corner coordinates on this screen for use with the passes='o' option. You can also use F4 to reset the coordinates to the defaults for the current fractal type.

There are two formats for the display: corners or center-mag. You can toggle between the two by using F7.

In corners mode, corner coordinate values are entered directly. Usually only the top-left and bottom-right corners need be specified - the bottom left corner can be entered as zeros to default to an ordinary unrotated rectangular area. For rotated or skewed images, the bottom left corner must also be specified.

In center-mag mode the screen area is described by entering the coordinates for the center of the rectangle, and its magnification factor. Usually only these three values are needed, but the user can also specify the amount that the image is stretched, rotated and skewed.

You can directly enter corner coordinates on this screen instead of using the zoom box to move around. You can also use F4 to reset the coordinates to the defaults for the current fractal type.

There are two formats for the display: corners or center-mag. You can toggle between the two by using F7.

In corners mode, corner coordinate values are entered directly. Usually only the top-left and bottom-right corners need be specified - the bottom left corner can be entered as zeros to default to an ordinary unrotated rectangular area. For rotated or skewed images, the bottom left corner must also be specified.

In center-mag mode the image area is described by entering the coordinates for the center of the rectangle, and its magnification factor. Usually only these three values are needed, but the user can also specify the amount that the image is stretched, rotated and skewed.

These "video modes" do not involve a graphic display at all. They use memory or your disk drive (as file id.$$$) to store the fractal image. These modes are useful for creating images beyond the size of your screen, right up to the current internal limit of 32767 x 32767 x 256, e.g. for subsequent printing. They’re also useful for background processing - create an image in a disk-video mode, save it, then restore it in a real video mode.

While you are using a disk-video mode, your screen will display text information indicating whether memory or your disk drive is being used, and what portion of the "screen" is being read from or written to. A "Cache size" figure is also displayed. 64K is the maximum cache size. With a very low cache size such as 4 or 6k, performance gets considerably worse in cases using solid guessing, boundary tracing, plasma, or anything else which paints the screen non-linearly.

The zoom box is disabled during disk-video modes (you couldn’t see where it is anyway). So is the orbit display feature. Color Cycling can be used during disk-video modes, but only to load or save a color palette.

When using real disk for your disk-video, for some "attractor" types (e.g. Lorenz) or IFS images, Id gives you a warning message but lets you proceed. You can end the calculation with Esc if you think your hard disk is getting too strenuous a workout.

If you have a favorite video mode that you would like to add to Id…​ if you want some new sizes of disk-video modes…​ if you want to remove table entries that you do not use…​ relief is here, and without even learning "C++"!

You can do these things by modifying the id.cfg file with your text editor. Saving a backup copy of id.cfg first is of course highly recommended!

Id uses a video mode table to describe available video modes that you can use. The table is loaded from the file id.cfg each time Id is run. It can contain information for up to 300 video modes. The table entries, and the function keys they are tied to, are displayed in the "select video mode" screen.

Since the saved image size is determined by the video mode, customizing this table is the only way to introduce new image sizes at this time. The default video modes listed in this file as distributed with Iterated Dynamics are arbitrary, but chosen to reflect common file dimensions. Lines in id.cfg which begin with a semi-colon are treated as comments. The rest of the lines must have seven fields separated by commas. The fields are defined as:

ant Generalized Ant Automaton as described in the July, 1994 Scientific American. Some ants wander around the screen. A rule string (the first parameter) determines the ant’s direction. When the type 1 ant leaves a cell of color k, it turns right if the kth symbol in the first parameter is a 1, or left otherwise. Then the color in the old cell is incremented. The 2nd parameter is a maximum iteration to guarantee that the fractal will terminate. The 3rd parameter is the number of ants. The 4th is the ant type 1 or 2. The 5th parameter determines if the ants wrap the screen or stop at the edge. The 6th parameter is a random seed. You can slow down the ants to see them better using the P screen Orbit Delay.

barnsleyj1 z(0) = pixel; if real(z) >= 0 z(n+1) = (z-1)*c else z(n+1) = (z+1)*c Two parameters: real and imaginary parts of c.

barnsleyj2 z(0) = pixel; if real(z(n)) * imag(c) + real(c) * imag(zn >= 0 z(n+1) = (z(n)-1)*c else z(n+1) = (z(n)+1)*c Two parameters: real and imaginary parts of c.

barnsleyj3 z(0) = pixel; if real(z(n) > 0 then z(n+1) = (real(z(n))^2 - imag(z(n))^2 - 1) + i * (2*real(zn * imag(zn) else z(n+1) = (real(z(n))^2 - imag(z(n))^2 - 1 + real(c) * real(z(n)) + i * (2*real(zn * imag(zn + imag(c) * real(z(n)) Two parameters: real and imaginary parts of c.

barnsleym1 z(0) = c = pixel; if real(z) >= 0 then z(n+1) = (z-1)*c else z(n+1) = (z+1)*c. Parameters are perturbations of z(0).

barnsleym2 z(0) = c = pixel; if real(z)*imag(c) + real(c)*imag(z) >= 0 z(n+1) = (z-1)*c else z(n+1) = (z+1)*c Parameters are perturbations of z(0).

barnsleym3 z(0) = c = pixel; if real(z(n) > 0 then z(n+1) = (real(z(n))^2 - imag(z(n))^2 - 1) + i * (2*real(zn * imag(zn) else z(n+1) = (real(z(n))^2 - imag(z(n))^2 - 1 + real(c) * real(z(n)) + i * (2*real(zn * imag(zn + imag(c) * real(z(n)) Parameters are perturbations of z(0).

bifurcation Pictorial representation of a population growth model. Let P = new population, p = oldpopulation, r = growth rate The model is: P = p + r*fn(p)*(1-fn(p)). Three parameters: Filter Cycles, Seed Population, and Function.

bif+sinpi Bifurcation variation: model is: P = p + r*fn(PI*p). Three parameters: Filter Cycles, Seed Population, and Function.

bif=sinpi Bifurcation variation: model is: P = r*fn(PI*p). Three parameters: Filter Cycles, Seed Population, and Function.

biflambda Bifurcation variation: model is: P = r*fn(p)*(1-fn(p)). Three parameters: Filter Cycles, Seed Population, and Function.

bifstewart Bifurcation variation: model is: P = (r*fn(p)*fn(p)) - 1. Three parameters: Filter Cycles, Seed Population, and Function.

bifmay Bifurcation variation: model is: P = r*p / ((1+p)^beta). Three parameters: Filter Cycles, Seed Population, and Beta.

cellular One-dimensional cellular automata or line automata. The type of CA is given by kr, where k is the number of different states of the automata and r is the radius of the neighborhood. The next generation is determined by the sum of the neighborhood and the specified rule. Four parameters: Initial String, Rule, Type, and Starting Row Number. For Type = 21, 31, 41, 51, 61, 22, 32, 42, 23, 33, 24, 25, 26, 27 Rule = 4, 7, 10, 13, 16, 6, 11, 16, 8, 15, 10, 12, 14, 16 digits

chip Chip attractor from Michael Peters - orbit in two dimensions. z(0) = y(0) = 0; x(n+1) = y(n) - sign(x(n)) * cos(sqr(ln(abs(b*x(n)-c)))) * arctan(sqr(ln(abs(c*x(n)-b)))) y(n+1) = a - x(n) Parameters are a, b, and c.

circle Circle pattern by John Connett x + iy = pixel z = a*(x^2 + y^2) c = integer part of z color = c modulo(number of colors)

cmplxmarksjul A generalization of the marksjulia fractal. z(0) = pixel; z(n+1) = c^(exp-1)*z(n)2 + c. Four parameters: real and imaginary parts of c, and real and imaginary parts of exponent.

cmplxmarksmand A generalization of the marksmandel fractal. z(0) = c = pixel; z(n+1) = c^(exp-1)*z(n)2 + c. Four parameters: real and imaginary parts of perturbation of z(0), and real and imaginary parts of exponent.

complexnewton, complexbasin Newton fractal types extended to complex degrees. Complexnewton colors pixels according to the number of iterations required to escape to a root. Complexbasin colors pixels according to which root captures the orbit. The equation is based on the newton formula for solving the equation z^p = r z(0) = pixel; z(n+1) = p - 1) * z(n)^p + r)/(p * z(n)^(p - 1. Four parameters: real & imaginary parts of degree p and root r.

diffusion Diffusion Limited Aggregation. Randomly moving points accumulate. Three parameters: border width (default 10), type, and color change rate.

dividebrot5 DivideBrot5 formula by Jim Muth. z(0) = 0; z(n+1) = sqr(z(n)) / (z(n)^(-(a-2)) + (b+10^(-20))) + pixel Two parameters: a and b

dynamic Time-discrete dynamic system. x(0) = y(0) = start position. y(n+1) = y(n) + f( x(n) ) x(n+1) = x(n) - f( y(n) ) f(k) = sin(k + a*fn1(b*k)) For implicit Euler approximation: x(n+1) = x(n) - f( y(n+1) ) Five parameters: start position step, dt, a, b, and the function fn1.

escher_julia Escher-like tiling of Julia sets from The Science of Fractal Images z(0) = pixel z(n+1) = z(n)^2 + (0, 0i) The target set is a second, scaled, Julia set: T = [ z: | (z * 15.0)^2 + c | < BAILOUT ] Two parameters: real and imaginary parts of c Iteration count and bailout size apply to both Julia sets.

fn(z)+fn(pix) c = z(0) = pixel; z(n+1) = fn1(z) + p*fn2(c) Six parameters: real and imaginary parts of the perturbation of z(0) and factor p, and the functions fn1, and fn2.

fn(z*z) z(0) = pixel; z(n+1) = fn(z(n)*z(n)) One parameter: the function fn.

fn*fn z(0) = pixel; z(n+1) = fn1(n)*fn2(n) Two parameters: the functions fn1 and fn2.

fn*z+z z(0) = pixel; z(n+1) = p1*fn(z(n))*z(n) + p2*z(n) Five parameters: the real and imaginary components of p1 and p2, and the function fn.

fn+fn z(0) = pixel; z(n+1) = p1*fn1(z(n))+p2*fn2(z(n)) Six parameters: The real and imaginary components of p1 and p2, and the functions fn1 and fn2.

formula Formula interpreter - write your own formulas as text files!

frothybasin Pixel color is determined by which attractor captures the orbit. The shade of color is determined by the number of iterations required to capture the orbit. Z(0) = pixel; Z(n+1) = Z(n)^2 - C*conj(Z(n)) where C = 1 + A*i, critical value of A = 1.028713768218725…​

gingerbread Orbit in two dimensions defined by: x(n+1) = 1 - y(n) + |x(n)| y(n+1) = x(n) Two parameters: initial values of x(0) and y(0).

halley Halley map for the function: F = z(z^a - 1) = 0 z(0) = pixel; z(n+1) = z(n) - R * F / [F' - (F" * F / 2 * F')] bailout when: abs(mod(z(n+1)) - mod(z(n)) < epsilon Four parameters: order a, real part of R, epsilon, and imaginary part of R.

henon Orbit in two dimensions defined by: x(n+1) = 1 + y(n) - a*x(n)*x(n) y(n+1) = b*x(n) Two parameters: a and b.

hopalong Hopalong attractor by Barry Martin - orbit in two dimensions. z(0) = y(0) = 0; x(n+1) = y(n) - sign(x(n))*sqrt(abs(b*x(n)-c)) y(n+1) = a - x(n) Parameters are a, b, and c.

hypercomplex HyperComplex Mandelbrot set. h(0) = (0,0,0,0) h(n+1) = fn(h(n)) + C. where "fn" is sin, cos, log, sqr etc. Two parameters: cj, ck C = (xpixel,ypixel,cj,ck)

hypercomplexj HyperComplex Julia set. h(0) = (xpixel,ypixel,zj,zk) h(n+1) = fn(h(n)) + C. where "fn" is sin, cos, log, sqr etc. Six parameters: c1, ci, cj, ck C = (c1,ci,cj,ck)

icon, icon3d Orbit in three dimensions defined by: p = lambda + alpha * magnitude + beta * (x(n)*zreal - y(n)*zimag) x(n+1) = p * x(n) + gamma * zreal - omega * y(n) y(n+1) = p * y(n) - gamma * zimag + omega * x(n) (3D version uses magnitude for z) Parameters: Lambda, Alpha, Beta, Gamma, Omega, and Degree.

IFS Barnsley IFS (Iterated Function System) fractals. Apply contractive affine mappings.

julfn+exp A generalized Clifford Pickover fractal. z(0) = pixel; z(n+1) = fn(z(n)) + e^z(n) + c. Three parameters: real & imaginary parts of c, and fn.

julfn+zsqrd z(0) = pixel; z(n+1) = fn(z(n)) + z(n)^2 + c Three parameters: real & imaginary parts of c, and fn.

julia Classic Julia set fractal. z(0) = pixel; z(n+1) = z(n)^2 + c. Two parameters: real and imaginary parts of c.

julia_inverse Inverse Julia function - "orbit" traces Julia set in two dimensions. z(0) = a point on the Julia Set boundary; z(n+1) = +- sqrt(z(n) - c) Parameters: Real and Imaginary parts of c Maximum Hits per Pixel (similar to max iters) Breadth First, Depth First or Random Walk Tree Traversal Left or Right First Branching (in Depth First mode only) Try each traversal method, keeping everything else the same. Notice the differences in the way the image evolves. Start with a fairly low Maximum Hit limit, then increase it. The hit limit cannot be higher than the maximum colors in your video mode.

julia(fn||fn) z(0) = pixel; if modulus(z(n)) < shift value, then z(n+1) = fn1(z(n)) + c, else z(n+1) = fn2(z(n)) + c. Five parameters: real, imag portions of c, shift value, fn1, fn2.

julia4 Fourth-power Julia set fractals, a special case of julzpower kept for speed. z(0) = pixel; z(n+1) = z(n)^4 + c. Two parameters: real and imaginary parts of c.

julibrot 'Julibrot' 4-dimensional fractals.

julzpower z(0) = pixel; z(n+1) = z(n)^m + c. Three parameters: real & imaginary parts of c, exponent m.

julzzpwr z(0) = pixel; z(n+1) = z(n)^z(n) + z(n)^m + c. Three parameters: real & imaginary parts of c, exponent m.

kamtorus, kamtorus3d Series of orbits superimposed. 3D version has 'orbit' the z dimension. x(0) = y(0) = orbit/3; x(n+1) = x(n)*cos(a) + (x(n)*x(n)-y(n))*sin(a) y(n+1) = x(n)*sin(a) - (x(n)*x(n)-y(n))*cos(a) After each orbit, 'orbit' is incremented by a step size. Parameters: a, step size, stop value for 'orbit', and points per orbit.

lambda Classic Lambda fractal. 'Julia' variant of Mandellambda. z(0) = pixel; z(n+1) = lambda*z(n)*(1 - z(n)). Two parameters: real and imaginary parts of lambda.

lambdafn z(0) = pixel; z(n+1) = lambda * fn(z(n)). Three parameters: real, imag portions of lambda, and fn.

lambda(fn||fn) z(0) = pixel; if modulus(z(n)) < shift value, then z(n+1) = lambda * fn1(z(n)), else z(n+1) = lambda * fn2(z(n)). Five parameters: real, imag portions of lambda, shift value, fn1, fn2. latoocarfian Orbit in two dimensions defined by: x(n+1) = fn1 (y(n) * b) + c * fn2(x(n) * b) y(n+1) = fn3 (x(n) * a) + d * fn4(y(n) * a) Parameters: a, b, c, d fn1..4 (all sin=original).

lorenz, lorenz3d Lorenz two lobe attractor - orbit in three dimensions. In 2d the x and y components are projected to form the image. z(0) = y(0) = z(0) = 1; x(n+1) = x(n) + (-a*x(n)*dt) + ( a*y(n)*dt) y(n+1) = y(n) + ( b*x(n)*dt) - ( y(n)*dt) - (z(n)*x(n)*dt) z(n+1) = z(n) + (-c*z(n)*dt) + (x(n)*y(n)*dt) Parameters are dt, a, b, and c.

lorenz3d1 Lorenz one lobe attractor, 3D orbit (Rick Miranda and Emily Stone) z(0) = y(0) = z(0) = 1; norm = sqrt(x(n)^2 + y(n)^2) x(n+1) = x(n) + (-a*dt-dt)*x(n) + (a*dt-b*dt)*y(n) + (dt-a*dt)*norm + y(n)*dt*z(n) y(n+1) = y(n) + (b*dt-a*dt)*x(n) - (a*dt+dt)*y(n) + (b*dt+a*dt)*norm - x(n)*dt*z(n) - norm*z(n)*dt z(n+1) = z(n) +(y(n)*dt/2) - c*dt*z(n) Parameters are dt, a, b, and c.

lorenz3d3 Lorenz three lobe attractor, 3D orbit (Rick Miranda and Emily Stone) z(0) = y(0) = z(0) = 1; norm = sqrt(x(n)^2 + y(n)^2) x(n+1) = x(n) +(-(a*dt+dt)x(n) + (a*dt-b*dt+z(n)*dt)*y(n))/3 + dt-a*dt)(x(n)^2-y(n)2) + 2*(b*dt+a*dt-z(n)dt)*x(n)*y(n/(3*norm) y(n+1) = y(n) +b*dt-a*dt-z(n)*dt)*x(n) - (a*dt+dt)*y(n/3 + (2(a*dt-dt)x(n)*y(n) + (b*dt+a*dt-z(n)*dt)(x(n)^2-y(n)2))/(3*norm) z(n+1) = z(n) +(3*x(n)*dt*x(n)*y(n)-y(n)*dt*y(n)^2)/2 - c*dt*z(n) Parameters are dt, a, b, and c.

lorenz3d4 Lorenz four lobe attractor, 3D orbit (Rick Miranda and Emily Stone) z(0) = y(0) = z(0) = 1; x(n+1) = x(n) +(-a*dt*x(n)^3 + (2*a*dt+b*dt-z(n)*dt)*x(n)^2*y(n) + (a*dt-2*dt)*x(n)*y(n)^2 + (z(n)*dt-b*dt)*y(n)^3) / (2 * (x(n)^2+y(n)2)) y(n+1) = y(n) +b*dt-z(n)*dt)*x(n)^3 + (a*dt-2*dt)*x(n)^2*y(n) + (-2*a*dt-b*dt+z(n)*dt)*x(n)*y(n)^2 - a*dt*y(n)^3) / (2 * (x(n)^2+y(n)2 z(n+1) = z(n) +(2*x(n)*dt*x(n)^2*y(n) - 2*x(n)*dt*y(n)^3 - c*dt*z(n)) Parameters are dt, a, b, and c.

lsystem Using a turtle-graphics control language and starting with an initial axiom string, carries out string substitutions the specified number of times (the order), and plots the result.

lyapunov Derived from the Bifurcation fractal, the Lyapunov plots the Lyapunov Exponent for a population model where the Growth parameter varies between two values in a periodic manner.

magnet1j z(0) = pixel; [ z(n)^2 + (c-1) ] 2 z(n+1) = | ---------------- | [ 2*z(n) + (c-2) ] Parameters: the real and imaginary parts of c.

magnet1m z(0) = 0; c = pixel; [ z(n)^2 + (c-1) ] 2 z(n+1) = | ---------------- | [ 2*z(n) + (c-2) ] Parameters: the real & imaginary parts of perturbation of z(0).

magnet2j z(0) = pixel; [ z(n)^3 + 3*(C-1)z(n) + (C-1)(C-2) ] 2 z(n+1) = | -------------------------------------------- | [ 3*(z(n)^2) + 3*(C-2)z(n) + (C-1)(C-2) + 1 ] Parameters: the real and imaginary parts of c.

magnet2m z(0) = 0; c = pixel; [ z(n)^3 + 3*(C-1)z(n) + (C-1)(C-2) ] 2 z(n+1) = | -------------------------------------------- | [ 3*(z(n)^2) + 3*(C-2)z(n) + (C-1)(C-2) + 1 ] Parameters: the real and imaginary parts of perturbation of z(0).

mandel Classic Mandelbrot set fractal. z(0) = c = pixel; z(n+1) = z(n)^2 + c. Two parameters: real & imaginary perturbations of z(0).

mandel(fn||fn) c = pixel; z(0) = p1 if modulus(z(n)) < shift value, then z(n+1) = fn1(z(n)) + c, else z(n+1) = fn2(z(n)) + c. Five parameters: real, imaginary portions of p1, shift value, fn1 and fn2.

mandelbrotmix4 From a Jim Muth favorite FOTD formula a=real(p1), b=imag(p1), d=real(p2), f=imag(p2), g=1/f, h=1/d, j=1/(f-b), z=(-a*b*g*h)^j, k=real(p3)1, l=imag(p3)+100, c=fn1(pixel): z=k*((a*(z^b))(d*(z^f)))+c Parameters: see above, sixth parameter used for bailout.

mandelcloud Displays orbits of Mandelbrot set: z(0) = c = pixel; z(n+1) = z(n)^2 + c. One parameter: number of intervals.

mandel4 Special case of mandelzpower kept for speed. z(0) = c = pixel; z(n+1) = z(n)^4 + c. Parameters: real & imaginary perturbations of z(0).

mandelfn z(0) = c = pixel; z(n+1) = c*fn(z(n)). Parameters: real & imaginary perturbations of z(0), and fn.

manlam(fn||fn) c = pixel; z(0) = p1 if modulus(z(n)) < shift value, then z(n+1) = fn1(z(n)) * c, else z(n+1) = fn2(z(n)) * c. Five parameters: real, imaginary parts of p1, shift value, fn1, fn2.

Martin Attractor fractal by Barry Martin - orbit in two dimensions. z(0) = y(0) = 0; x(n+1) = y(n) - sin(x(n)) y(n+1) = a - x(n) Parameter is a (try a value near pi).

mandellambda z(0) = .5; lambda = pixel; z(n+1) = lambda*z(n)*(1 - z(n)). Parameters: real & imaginary perturbations of z(0).

mandphoenix z(0) = c = pixel, y(0) = 0; For degree = 0: z(n+1) = z(n)^2 + c.x + c.y*y(n), y(n+1) = z(n) For degree >= 2: z(n+1) = z(n)^degree + c.x*z(n)^(degree-1) + c.y*y(n) y(n+1) = z(n) For degree ⇐ -3: z(n+1) = z(n)^|degree| + c.x*z(n)^(|degree|-2) + c.y*y(n) y(n+1) = z(n) Three parameters: real & imaginary perturbations of z(0), and degree.

mandphoenixclx z(0) = c = pixel, y(0) = 0; For degree = 0: z(n+1) = z(n)^2 + c + p2*y(n), y(n+1) = z(n) For degree >= 2: z(n+1) = z(n)^degree + c*z(n)^(degree-1) + p2*y(n), y(n+1) = z(n) For degree ⇐ -3: z(n+1) = z(n)^|degree| + c*z(n)^(|degree|-2) + p2*y(n), y(n+1) = z(n) Five parameters: real & imaginary perturbations of z(0), real & imaginary parts of p2, and degree.

manfn+exp 'Mandelbrot-Equivalent' for the julfn+exp fractal. z(0) = c = pixel; z(n+1) = fn(z(n)) + e^z(n) + C. Parameters: real & imaginary perturbations of z(0), and fn.

manfn+zsqrd 'Mandelbrot-Equivalent' for the Julfn+zsqrd fractal. z(0) = c = pixel; z(n+1) = fn(z(n)) + z(n)^2 + c. Parameters: real & imaginary perturbations of z(0), and fn.

manowar c = z1(0) = z(0) = pixel; z(n+1) = z(n)^2 + z1(n) + c; z1(n+1) = z(n); Parameters: real & imaginary perturbations of z(0).

manowarj z1(0) = z(0) = pixel; z(n+1) = z(n)^2 + z1(n) + c; z1(n+1) = z(n); Parameters: real & imaginary parts of c.

manzpower 'Mandelbrot-Equivalent' for julzpower. z(0) = c = pixel; z(n+1) = z(n)^exp + c; try exp = e = 2.71828…​ Parameters: real & imaginary perturbations of z(0), real & imaginary parts of exponent exp.

manzzpwr 'Mandelbrot-Equivalent' for the julzzpwr fractal. z(0) = c = pixel z(n+1) = z(n)^z(n) + z(n)^exp + C. Parameters: real & imaginary perturbations of z(0), and exponent.

marksjulia A variant of the julia-lambda fractal. z(0) = pixel; z(n+1) = c^(exp-1)*z(n)2 + c. Parameters: real & imaginary parts of c, and exponent.

marksmandel A variant of the mandel-lambda fractal. z(0) = c = pixel; z(n+1) = c^(exp-1)*z(n)2 + c. Parameters: real & imaginary parts of perturbations of z(0), and exponent.

marksmandelpwr The marksmandelpwr formula type generalized (it previously had fn=sqr hard coded). z(0) = pixel, c = z(0) ^ (z(0) - 1): z(n+1) = c * fn(z(n)) + pixel, Parameters: real and imaginary perturbations of z(0), and fn.

newtbasin Based on the Newton formula for finding the roots of z^p - 1. Pixels are colored according to which root captures the orbit. z(0) = pixel; z(n+1) = p-1)*z(n)^p + 1)/(p*z(n)^(p - 1. Two parameters: the polynomial degree p, and a flag to turn on color stripes to show alternate iterations.

newton Based on the Newton formula for finding the roots of z^p - 1. Pixels are colored according to the iteration when the orbit is captured by a root. z(0) = pixel; z(n+1) = p-1)*z(n)^p + 1)/(p*z(n)^(p - 1. One parameter: the polynomial degree p.

phoenix z(0) = pixel, y(0) = 0; For degree = 0: z(n+1) = z(n)^2 + p1.x + p2.x*y(n), y(n+1) = z(n) For degree >= 2: z(n+1) = z(n)^degree + p1.x*z(n)^(degree-1) + p2.x*y(n), y(n+1) = z(n) For degree ⇐ -3: z(n+1) = z(n)^|degree| + p1.x*z(n)^(|degree|-2) + p2.x*y(n), y(n+1) = z(n) Three parameters: real parts of p1 & p2, and degree.

phoenixcplx z(0) = pixel, y(0) = 0; For degree = 0: z(n+1) = z(n)^2 + p1 + p2*y(n), y(n+1) = z(n) For degree >= 2: z(n+1) = z(n)^degree + p1*z(n)^(degree-1) + p2*y(n), y(n+1) = z(n) For degree ⇐ -3: z(n+1) = z(n)^|degree| + p1*z(n)^(|degree|-2) + p2*y(n), y(n+1) = z(n) Five parameters: real & imaginary parts of p1 & p2, and degree.

pickover Orbit in three dimensions defined by: x(n+1) = sin(a*y(n)) - z(n)*cos(b*x(n)) y(n+1) = z(n)*sin(c*x(n)) - cos(d*y(n)) z(n+1) = sin(x(n)) Parameters: a, b, c, and d.

plasma Random, cloud-like formations. Requires 4 or more colors. A recursive algorithm repeatedly subdivides the screen and colors pixels according to an average of surrounding pixels and a random color, less random as the grid size decreases. Four parameters: 'graininess' (0, 0.125 to 100, default = 2), old/new algorithm, seed value used, 16-bit out output selection.

popcorn The orbits in 2D are plotted superimposed: x(0) = xpixel, y(0) = ypixel; x(n+1) = x(n) - real(h * fn1( y(n) + fn2(C * y(n) )) - imag(h * fn3( x(n) + fn4(C * x(n) )) y(n+1) = y(n) - real(h * fn3( x(n) + fn4(C * x(n) )) - imag(h * fn1( y(n) + fn2(C * y(n) )) Parameters: step size h, C, functions fn1..4 (original: sin,tan,sin,tan).

popcornjul Julia using the generalized Pickover Popcorn formula: x(0) = xpixel, y(0) = ypixel; x(n+1) = x(n) - real(h * fn1( y(n) + fn2(C * y(n) )) - imag(h * fn3( x(n) + fn4(C * x(n) )) y(n+1) = y(n) - real(h * fn3( x(n) + fn4(C * x(n) )) - imag(h * fn1( y(n) + fn2(C * y(n) )) Parameters: step size h, C, functions fn1..4 (original: sin,tan,sin,tan).

quadruptwo Quadruptwo attractor from Michael Peters - orbit in two dimensions. z(0) = y(0) = 0; x(n+1) = y(n) - sign(x(n)) * sin(ln(abs(b*x(n)-c))) * arctan(sqr(ln(abs(c*x(n)-b)))) y(n+1) = a - x(n) Parameters are a, b, and c.

quatjul Quaternion Julia set. q(0) = (xpixel,ypixel,zj,zk) q(n+1) = q(n)*q(n) + c. Four parameters: c, ci, cj, ck c = (c1,ci,cj,ck)

quat Quaternion Mandelbrot set. q(0) = (0,0,0,0) q(n+1) = q(n)*q(n) + c. Two parameters: cj,ck c = (xpixel,ypixel,cj,ck)

rossler3D Orbit in three dimensions defined by: x(0) = y(0) = z(0) = 1; x(n+1) = x(n) - y(n)*dt - z(n)*dt y(n+1) = y(n) + x(n)*dt + a*y(n)*dt z(n+1) = z(n) + b*dt + x(n)*z(n)*dt - c*z(n)*dt Parameters are dt, a, b, and c.

sierpinski Sierpinski gasket - Julia set producing a 'Swiss cheese triangle' z(n+1) = (2*x,2*y-1) if y > .5; else (2*x-1,2*y) if x > .5; else (2*x,2*y) No parameters.

spider c(0) = z(0) = pixel; z(n+1) = z(n)^2 + c(n); c(n+1) = c(n)/2 + z(n+1) Parameters: real & imaginary perturbation of z(0).

sqr(1/fn) z(0) = pixel; z(n+1) = (1/fn(z(n))^2 One parameter: the function fn.

sqr(fn) z(0) = pixel; z(n+1) = fn(z(n))^2 One parameter: the function fn.

test 'test' point letting us (and you!) easily add fractal types via the source file testpt.cpp. Default set up is a mandelbrot fractal. Four parameters: user hooks (not used by default testpt.cpp).

tetrate z(0) = c = pixel; z(n+1) = c^z(n) Parameters: real & imaginary perturbation of z(0).

threeply Threeply attractor by Michael Peters - orbit in two dimensions. z(0) = y(0) = 0; x(n+1) = y(n) - sign(x(n)) * (abs(sin(x(n))*cos(b) +c-x(n)*sin(a+b+c))) y(n+1) = a - x(n) Parameters are a, b, and c.

tim’s_error A serendipitous coding error in marksmandelpwr brings to life an ancient pterodactyl! (Try setting fn to sqr.) z(0) = pixel, c = z(0) ^ (z(0) - 1): tmp = fn(z(n)) real(tmp) = real(tmp) * real(c) - imag(tmp) * imag(c); imag(tmp) = real(tmp) * imag(c) - imag(tmp) * real(c); z(n+1) = tmp + pixel; Parameters: real & imaginary perturbations of z(0) and function fn.

unity z(0) = pixel; x = real(z(n)), y = imag(z(n)) One = x^2 + y^2; y = (2 - One) * x; x = (2 - One) * y; z(n+1) = x + i*y No parameters.

volterra-lotka Volterra-Lotka fractal from The Beauty of Fractals x(0) = xpixel, y(0) = ypixel; dx/dt = x - xy = f(x,y) dy/dt = -y + xy = g(x,y) x(new) = x + h/2 * [ f(x,y) + f[x + pf(x,y), y + pg(x,y)] ] y(new) = y + h/2 * [ g(x,y) + g[x + pf(x,y), y + pg(x,y)] ] Two parameters: h and p. Recommended: zmag or bof60 inside coloring options.

Here is an attempted explanation of what the "inside=bof60" and "inside=bof61" options do. This explanation is hereby dedicated to Adrian Mariano, who badgered it out of us! For the real explanation, see "Beauty of Fractals", page 62.

Let p(z) be the function that is repeatedly iterated to generate a fractal using the escape-time algorithm. For example, p(z) = z^2+c in the case of a Julia set. Then let pk(z) be the result of iterating the function p for k iterations. (The "k" should be shown as a superscript.) We could also use the notation pkc(z) when the function p has a parameter c, as it does in our example. Now hold your breath and get your thinking cap on. Define a(c) = inf{|pkc(0)|:k=1,2,3,…​}. In English - a(c) is the greatest lower bound of the images of zero of as many iterations as you like. Put another way, a(c) is the closest to the origin any point in the orbit starting with 0 gets. Then the index (c) is the value of k (the iteration) when that closest point was achieved. Since there may be more than one, index(c) is the least such. Got it? Good, because the "Beauty of Fractals" explanation of this, is, ahhhh, terse! Now for the punch line. "Inside=bof60" colors the lake alternating shades according to the level sets of a(c). Each band represents solid areas of the fractal where the closest value of the orbit to the origin is the same. "Inside=bof61" show domains where index(c) is constant. That is, areas where the iteration when the orbit swooped closest to the origin has the same value. Well, folks, that’s the best we can do! Improved explanations will be accepted for the next edition!

In response to this request for lucidity, Herb Savage offers this explanation the bof60 and bof61 options:

"Inside=fmod" colors inside pixels according to the magnitude of the last orbit point which is within a set distance from the origin. Then: color = magnitude * colors / closeprox The magnitude used for the comparison is now based on the same calculation as is used for the bailout test. The value of closeprox can be varied interactively. This feature was contributed by Iain Stirling.

"Inside=period" colors pixels according to the length of their eventual cycle. For example, points that approach a fixed point have color=1. Points that approach a 2-cycle have color=2. Points that do not approach a cycle during the iterations performed have color=maxit. This option works best with a fairly large number of iterations.

"Inside=atan" colors by determining the angle in degrees the last iterated value has with respect to the real axis, and using the absolute value. This feature should be used with periodicity=0.

Kenneth Hooper has written a paper entitled "A Note On Some Internal Structures of the Mandelbrot Set" published in "Computers and Graphics", Vol 15, No.2, pp. 295-297. In that article he describes Clifford Pickover’s epsilon cross method which creates some mysterious plant-like tendrils in the Mandelbrot set. The algorithm is this. In the escape- time calculation of a fractal, if the orbit comes within .01 of the Y- axis, the orbit is terminated and the pixel is colored green. Similarly, the pixel is colored yellow if it approaches the X-axis. Strictly speaking, this is not an "inside" option because a point destined to escape could be caught by this bailout criterion.

The test distance, 0.01, can now be changed interactively on the X screen and via the "proximity=<nnn>" command line parameter. A negative value of the test distance triggers an alternative variation of epsilon cross that colors the epsilon bands with the iteration; otherwise they are colored normally to maintain compatibility.

Hooper has another coloring scheme called star trails that involves detecting clusters of points being traversed by the orbit. A table of tangents of each orbit point is built, and the pixel colored according to how many orbit points are near the first one before the orbit flies out of the cluster. This option looks fine with maxiter=16, which greatly speeds the calculation.

Both of these options should be tried with the outside color fixed ("outside=<nnn>") so that the lake structure revealed by the algorithms can be more clearly seen. Epsilon cross is fun to watch with boundary tracing turned on - even though the result is incorrect it is interesting! Shucks - what does "incorrect" mean in chaos theory anyway?!

Many of Id’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, Id 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 Id’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, Id 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 Y 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 Y options screen) instructs Id 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 Orbits display on to see where it is - the orbits of all initial points that are in the lake converge there.

Id 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, 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.

Second, 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 technospeak, 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.

Third, the initial implementation only works for Julia-types that use the standard fractal engine in Id. 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.

The following trig identities are invaluable for coding fractals that use complex-valued transcendental functions of a complex variable in terms of real-valued functions of a real variable, which are usually found in compiler math libraries. In what follows, we sometimes use "*" for multiplication, but leave it out when clarity is not lost. We use "^" for exponentiation; x^y is x to the y power.

Id’s definitions of abs(x+iy) and |x+iy| below are non-standard. Math texts define both absolute value and modulus of a complex number to be the same thing. They are both equal to cabs(x+iy) as defined above.

Quaternions are four dimensional generalizations of complex numbers. They almost obey the familiar field properties of real numbers, but fail the commutative law of multiplication, since x*y is not generally equal to y*x.

Quaternion algebra is most compactly described by specifying the rules for multiplying the basis vectors 1, i, j, and k. Quaternions form a superset of the complex numbers, and the basis vectors 1 and i are the familiar basis vectors for the complex algebra. Any quaternion q can be represented as a linear combination q = x + yi + zj + wk of the basis vectors just as any complex number can be written in the form z = a
bi.

Multiplication rules for quaternion basis vectors: ij = k jk = i ki = j ji = -k kj = -i ik = -j ii = jj = kk = -1 ijk = -1

Note that ij = k but ji = -k, showing the failure of the commutative law. The rules for multiplying any two quaternions follow from the behavior of the basis vectors just described. However, for your convenience, the following formula works out the details. Let q1 = x1 + y1i + z1j + w1k and q2 = x2 + y2i + z2j + w2k. Then q1q2 = 1(x1x2 - y1y2 - z1z2 - w1w2)
i(y1x2 + x1y2 - w1z2 + z1w2)
j(z1x2 + w1y2 + x1z2 - y1w2)
k(w1x2 + z1y2 - y1z2 + x1w2)

Quaternions are not the only possible four dimensional supersets of the complex numbers. William Rowan Hamilton, who discovered quaternions in 1843, considered the alternative called the hypercomplex number system. Unlike quaternions, the hypercomplex numbers satisfy the commutative law of multiplication. The law which fails is the field property that states that all non-zero elements of a field have a multiplicative inverse. For a non-zero hypercomplex number h, the multiplicative inverse 1/h does not always exist.

As with quaternions, we will define multiplication in terms of the basis vectors 1, i, j, and k, but with subtly different rules.

Multiplication rules for hypercomplex basis vectors: ij = k jk = -i ki = -j ji = k kj = -i ik = -j ii = jj = -kk = -1 ijk = 1

Note that now ij = k and ji = k, and similarly for other products of pairs of basis vectors, so the commutative law holds.

Hypercomplex multiplication formula: Let h1 = x1 + y1i + z1j + w1k and h2 = x2 + y2i + z2j + w2k. Then h1h2 = 1(x1x2 - y1y2 - z1z2 + w1w2)
i(y1x2 + x1y2 - w1z2 - z1w2)
j(z1x2 - w1y2 + x1z2 - y1w2)
k(w1x2 + z1y2 + y1z2 + x1w2)

As an added bonus, we’ll give you the formula for the reciprocal.

Let det = [((x-w)^2+(y+z)2)((x+w)^2+(y-z)2)] Then 1/h = 1[ x(x^2+y2+z^2+w2)-2w(xw-yz)]/det
i[-y(x^2+y2+z^2+w2)-2z(xw-yz)]/det
j[-z(x^2+y2+z^2+w2)-2y(xw-yz)]/det
k[ w(x^2+y2+z^2+w2)-2x(xw-yz)]/det

A look at this formula shows the difficulty with hypercomplex numbers. In order to calculate 1/h, you have to divide by the quantity det = [((x-w)^2+(y+z)2)((x+w)^2+(y-z)2)]. So when this quantity is zero, the multiplicative inverse will not exist.

Hypercomplex numbers have an elegant generalization of any unary complex valued function defined on the complex numbers. First, note that hypercomplex numbers can be represented as a pair of complex numbers in the following way. Let h = x + yi + zj + wk. a = (x-w) + i(y+z) b = (x+w) + i(y-z) The numbers a and b are complex numbers. We can represent h as the pair of complex numbers (a,b). Conversely, if we have a hypercomplex number given to us in the form (a,b), we can solve for x, y, z, and w. The solution to c = (x-w) + i(y+z) d = (x+w) + i(y-z) is x = (real(c) + real(d))/2 y = (imag(c) + imag(d))/2 z = (imag(c) - imag(d))/2 w = (real(d) - real(c))/2 We can now, for example, compute sin(h). First compute the two complex numbers a and b as above, then set c = sin(a) and d = sin(b) where sin() is the complex version of the sin function. Now use the equations above to solve for x, y, z, and w in terms of c and d. The hypercomplex number (x,y,z,w) thus obtained is sin(h).

The beauty of this is that it really doesn’t make any difference what function we use. Instead of sin, we could have used cos, sinh, ln, or z^2. Using this technique, Id can create 3D fractals using the formula h' = fn(h) + c, where "fn" is any of the built-in functions. Where fn is sqr(), this is the famous mandelbrot formula, generalized to four dimensions.

For more information, see Fractal Creations, Second Edition by Tim Wegner and Bert Tyler, Waite Group Press, 1993.

Once upon a time, somewhere in Eastern Europe, there was a great famine. People jealously hoarded whatever food they could find, hiding it even from their friends and neighbors. One day a peddler drove his wagon into a village, sold a few of his wares, and began asking questions as if he planned to stay for the night.

"There’s not a bite to eat in the whole province", he was told. "Better keep moving on."

"Oh, I have everything I need", he said. "In fact, I was thinking of making some stone soup to share with all of you." He pulled an iron cauldron from his wagon, filled it with water, and built a fire under it. Then, with great ceremony, he drew an ordinary-looking stone from a velvet bag and dropped it into the water.

By now, hearing the rumor of food, most of the villagers had come to the square or watched from their windows. As the peddler sniffed the "broth" and licked his lips in anticipation, hunger began to overcome their skepticism.

"Ahh", the peddler said to himself rather loudly, "I do like a tasty stone soup. Of course, stone soup with cabbage — that’s hard to beat."

Soon a villager approached hesitantly, holding a cabbage he’d retrieved from its hiding place, and added it to the pot. "Capital!" cried the peddler. "You know, I once had stone soup with cabbage and a bit of salt beef as well, and it was fit for a king."

The village butcher managed to find some salt beef…​and so it went, through potatoes, onions, carrots, mushrooms, and so on, until there was indeed a delicious meal for all. The villagers offered the peddler a great deal of money for the magic stone, but he refused to sell and traveled on the next day. And from that time on, long after the famine had ended, they reminisced about the finest soup they’d ever had.

That’s the way Id has grown, with quite a bit of magic, although without the element of deception. (You don’t have to deceive programmers to make them think that hours of painstaking, often frustrating work is fun…​ they do it to themselves.)

It wouldn’t have happened, of course, without Benoit Mandelbrot and the explosion of interest in fractal graphics that has grown from his work at IBM. Or without the example of other Mandelplotters for the PC. Or without those wizards who first realized you could perform Mandelbrot calculations using integer math (it wasn’t us - we just recognize good algorithms when we steal—​uhh—​see them). Or those graphics experts who hang around the CompuServe PICS forum and keep adding video modes to the program. Or…​

Id’s ancestor, Fractint 20.04, is the result of a synergy between the main authors, many contributors, and published sources. All of the main authors have had a hand in many aspects of the code. However, each author has certain areas of greater contribution and creativity. Since there is not room in the credits screen for the contributions of the main authors, we list them here to further elaborate on their contributions.

Richard Thomson is the main author of Id. The Fractint code had languished for many years, struggling to leave its DOS nest. This has resulted other fractal renderers passing it by as they adopted SIMD parallelism, GPU computation and fancy perturbation methods to eclipse its computational speed. Richard felt the investment in so many fractal types, and the extensive online help, couldn’t just be left to rot and the code needed to move forward to a modern environment. Particularly the IFS, L-system and cellular automata types deserve to have a modern home as they are often omitted by other fractal rendering programs.

Richard forked the code from Subversion to the github repository. There are barely any lines of code that weren’t touched by him after the fork from Fractint.

Richard decoupled the DOS and assembly language code from the rest of the code and created a driver abstraction that could be used to connect the code to modern environments. He implemented the disk and gdi drivers for Win32 used to provide their correspnding video modes. The CGA text window is emulated in order to have the user interface and help system. He converted the entirety of the code to C++ to allow object oriented programming paradigms to be used.

Many magic numbers throughout the code were replaced with enums or other symbolic names to make it easier to understand how these values and flags are used throughout. Many times an integer quantity was being used as a boolean on/off switch and those integer variables were replaced with boolean variables to make the intent more clear.

Over the years, the code has accumulated a large number of global variables through which the various functions communicate. Global variables have been renamed to start with a g_ prefix and variables with a file scope, e.g. static variables, were renamed to start with an s_ prefix. This makes it easier to understand the scope of variables when reading a particular piece of code.

Functions and variables were placed together into source files in order to suit the cramped memory limitations of DOS using overlays. Sometimes you have to break things down into isolated pieces before you can begin to see which ones are intimately connected to each other. For the largest source files containing multiple functions, the individual functions were split into their own source and header files. He implemented the CMake based build system from scratch. He used the vcpkg package manager for C++ to allow Id to easily consume third party libraries for new features. One of the first libraries used was Google Test, bringing unit testing to the code for the first time. Making changes to the code requires careful attention to detail in how all these variables interact with each other. Unit testing changes before applying them helps ensure that forward progress doesn’t come at the expense of bugs.

Github’s actions provide continuous integration (CI) builds on Windows and linux with every commit to the repository. The actions build all the code and run all the unit tests every time the repository is updated. Richard uses Windows as his primary development environment and the CI builds ensure that the code continues to build on linux. (This trips you up more often than you might think!)

Other libraries Richard has brought in are the boost.algorithm library for some string algorithms, the boost.endian library for marshalling the GIF extension blocks between little and big endian machines and the giflib library for reading and writing GIF files.

The 2017 version of the ISO C++ language standard is required to build Id. This is readily available through open source compilers on unix, such as gcc and clang, and on Windows through Visual Studio Community Edition. Visual Studio Community Edition is a full-featured compiler and development environment with no license restrictions. It can be downloaded from https://VisualStudio.com.

Every line of the help files were examined and updated to have a consistent style throughout. Discussion of old DOS related information was removed and, where appropriate, replaced with relevant discussion of operating in a Windowed environment. Stale links to web sites have been removed. The original help came from a more innocent time on the internet when people weren’t afraid to post their phone numbers and home addresses. That personal information has been removed from the help files and only Richard’s personal email address has been left.

Richard has a Bachelor of Science degree in Electrical Engineering from the University of Delaware and a Master of Philosophy degree in Computer Science from the University of Utah. From 2000 to 2010, he was a Microsoft MVP for Direct3D and wrote a book on the Direct3D APIs. The book, "The Direct3D Graphics Pipeline", is available free download at <https://legalizeadulthood.wordpress.com/the-direct3d-graphics- pipeline/>

He has worked as a software engineer for his entire career on embedded systems, 3D graphics workstations, 3D paint software, digital video editing software, system management software, home automation software, 3D content creation software, solid-state storage management software and currently works on hardware accelerated ray tracing.

Bert Tyler is the original author of Fractint. He wrote the "blindingly fast" 386-specific 32 bit integer math code and the original video mode logic. Bert made Stone Soup possible, and provides a sense of direction when we need it. His forte is writing fast 80x86 assembler, his knowledge of a variety of video hardware, and his skill at hacking up the code we send him!

Bert has a BA in mathematics from Cornell University. He has been in programming since he got a job at the computer center in his sophomore year at college - in other words, he hasn’t done an honest day’s work in his life. He has been known to pass himself off as a PC expert, a Unix expert, a statistician, and even a financial modeling expert. He is currently masquerading as an independent PC consultant, supporting the PC-to-Mainframe communications environment at NIH. If you sent mail from the Internet to an NIH staffer on his 3+Mail system, it was probably Bert’s code that mangled it during the Internet-to-3+Mail conversion. He also claims to support the MS-Kermit environment at NIH. Fractint is Bert’s first effort at building a graphics program.

Tim Wegner contributed the original implementation of palette animation, and is responsible for most of the 3D mechanisms. He provided the main outlines of the "Standard Fractal" engine and data structures, and is accused by his cohorts of being "obsessed with options". One of Tim’s main interests is the use of four dimensional algebras to produce fractals. Tim served as team coordinator for version 19, and integrated Wes Loewer’s arbitrary precision library into Fractint.

Tim has BA and MA degrees in mathematics from Carleton College and the University of California Berkeley. He worked for 7 years overseas as a volunteer, doing things like working with Egyptian villagers building water systems. Since returning to the US in 1982, he has written shuttle navigation software, a software support environment prototype, and supported strategic information planning, all at NASA’s Johnson Space Center. After a two-year stint at full-time writing, he’s back at NASA developing shuttle navigation software.

Jonathan Osuch started throwing pebbles into the soup around version 15.0 with a method for simulating an if-then-else structure using the formula parser. He has contributed the fn||fn fractal types, the built- in bailout tests, the increase in both the maximum iteration count and bailout value, and bug fixes too numerous to count. Jonathan worked closely with Robin Bussell to implement Robin’s browser mechanism in Fractint.

Jonathan has a B.S. in Physics from the University of Dubuque and a B.S. in Computer Science from Mount Mercy College, both in Iowa. He is currently working as a consultant in the nuclear power industry.

Wes Loewer first got his foot in the Stone Soup door by writing fast floating point assembler routines for Mandelbrot, Julia, and Lyapunov fractals. He also rewrote the boundary trace algorithms and added the frothybasin fractal. His most significant contribution is the addition of the arbitrary precision library which allows Fractint to perform incredibly deep zooms.

Wes has a B.S. in Physics from Wheaton College in Illinois. He also holds an M.S. in Physics and an M.Ed. in Education from Texas A&M University. Wes teaches physics and math at McCullough High School in The Woodlands, Texas where his pupils inspire him to keep that sense of amazement that students get when they understand a physical or mathematical principle for the first time. Since he uses Fractint to help teach certain mathematical principles, he’s one of the few folks who actually gets to use Fractint on the job. Besides his involvement with Fractint, Wes is the author of WL-Plot, an equation graphing program, and MatCalc, a matrix calculator program.

George Martin first became known to Fractint users when he brought a modicum of order to the chaotic world of formula postings with his release of the Orgform program and formula compilation. George added if..else to the formula parser language for version 19.6. Among his other contributions are the ability to include formula, ifs, and lsystem entries in .par files, the scrolling of text in the Z and F2 screens, and new autokey commands.

George received an A.B. in Economics from Dartmouth College and a J.D from the University of Michigan. When not playing with Fractint, he practices law in a small village about 40 miles northwest of Detroit.

Robin Bussell began contributing to Fractint in rudimentary fashion with the autologmap routine and has been producing more and more complex interface enhancements as he gets better at what he refers to as 'this C programming lark'. He is always grateful for the help the rest of the team have given in smoothing the rough edges of the ingredients he adds to the soup and regards the evolver feature as his greatest achievement to date.

Robin had far too much fun at college in London to actually get any qualifications there and has since worked his way up from a workshop job fixing computers back in the final days of CP/M, via some interesting work with Transputers (an innovative British cpu that was designed to run in massively parallel configurations, and made a very good Mandlebrot set calculating machine when a few dozen or more were set to the task), through to his position of senior engineer for a third party suppport company where he spends his time travelling the south west of Britain sorting out peoples IT problems.

When not playing with computers Robin likes to relax by experimenting with kite powered traction and can often be found hurtling around the local beaches on the end of a few square metres of fabric and carbon fibre in various configurations.

New versions of Iterated Dynamics are released through github, https://github.com/LegalizeAdulthood/iterated-dynamics, and make their way to other systems from that point. Id is available as a Windows MSI installer, a ZIP file containing binaries and as a source code ZIP file.

The latest version of the code can always be found on the github repository.

Communication with the author for development of the next version of Iterated Dynamics takes place through the github repository, https://github.com/LegalizeAdulthood/iterated-dynamics. From there you can file bugs, feature requests and so-on. The current main author is Richard Thomson, who is the maintainer of the github repository. You can email him directly at legalize@xmission.com, but it is best to use github.