ChaosExplorer Wrapup

This is the final post in the ChaosExplorer series of posts. ChaosExplorer was created to explore a number of chaotic systems and to create the displays for these systems in fragment shaders using OpenGL and GLSL. Four different fractal formulae were used to generate fractals and their corresponding Julia Sets. From those standpoints, I would call ChaosExplorer a success. The program is not commercial grade; there are many changes that should be made to ChaosExplorer.

  1. There are many more fractal equations that could be used. In fact, Fractal Formulas Researched lists more than 1000 different fractal formulae. There are some duplicates in the list, but still more formulae that you are likely to investigate.When choosing a formula from that list, remember that z0 = 0, so make sure that z1 is not always also 0 or you will simply get a black display. Also, make sure that for formulae containing both a numerator and a denominator, that the denominator does not also calculate out to 0 or you will simply get a solid orange display.
  2. Additional fractals without Julia Sets include:

    Each of these can be generated using GLSL.

  3. ChaosExplorer currently displays different colours based solely on the number of iterations, so there is a step difference between each colour. The colour instead could be chosen based on the value of z after a constant number of iterations. This would potentially produce a much smoother transition between colours.
  4. ChaosExplorer could be refactored to place additional functionality in the panel base classes. It may be possible to entirely eliminate the individual derived panels in all cases except the MultibrotPanel.
  5. There are a few places in the code where magic numbers are used. These may be refactored to use defined constants.

Those are just a few ways that ChaosExplorer could be improved. Since my reasons for creating this program have been met, I will leave those modifications to you.

(z^3+1)/(1+cz^2)

The Fractal dropdown menu in the ChaosExplorer program contains 4 menu items:

  • z^p + c
  • (z^3+1)/(1+cz^2)
  • c*e^z, and
  • z^3-z^2+z+c

Each of these menu items displays the fractal (z0 = 0.0 + 0.0i, varying c over the complex plane). Selecting the first menu item displays the Mandelbrot Set; selecting any of the others displays the fractal for the indicated formula. This post specifically shows the fractal and Julia Sets for the second menu item, whose formula is:

zn+1 = (zn3 + 1) / (1 + czn2)

Here is the fractal display. This is for the region -10.0 ≤ x ≤ 10.0, -10.0 ≤ y ≤ 10.0:

Fractal2

And here are 4 Julia Set displays for points in this fractal:

Julia21

Julia22

Julia23

Julia24

As you can see, the fractal and Julia Sets are very different from the Mandelbrot/Multibrot fractals and Julia Sets.

Julia Sets

Julia Sets are another set of images that can be created by iterating a dynamic equation. If you want all of the ugly mathematics, see the Wikipedia entry on Julia Set. If you take the time to understand all of it, you are a better person than me. For a better explanation, I suggest seeing Julia and Mandelbrot Sets, and Understanding Julia and Mandelbrot Sets.

That’s all fine and good, but how do we create a Julia Set mathematically? Certainly not by attempting to follow the Wikipedia entry! For a Julia Set that corresponds to the Mandelbrot set, we use the same equation, but generate the plot for a different plane. Remember the equation:

zn+1 = znp + c

For the Mandelbrot Set, z0 = 0 + 0i and p = 2. We set c to be each point in the section of the complex plane that we were looking at. For the Julia Set, we set c to a single value in the complex plane, then set z0 to each point in the section of the complex plane we are looking at, and iterate. For every point, c, inside the Mandelbrot Set, there is a connected Julia Set; for each point outside of the Mandelbrot Set, the Julia Set is disconnected.

The most interesting images are generated from points outside the Mandelbrot Set or just inside it. This image is generated for a point near the centre of the secondary bulb:

MJulia1

and this is image is generated for a point inside one of the small bulbs off the main bulb:

MJulia2

This image is generated for a point just outside the Mandelbrot set and slightly about the x-axis:

MJulia3

Here are a couple of images created from the tendrils of the Mandelbrot Set:

MJulia4

MJulia5

and finally, an image from a short distance outside the Mandelbrot Set:

MJulia6

Each value, c, produces a different image. To generate an image for a point in the Mandelbrot Set using the ChaosExplorer program, place the mouse cursor over the point, click the right mouse button, and select the Julia Set menu item. The image is generated in a panel in a new notebook tab. You can also zoom in on the image by selecting an area to zoom, and then selecting the Draw From Selection menu item. The source code and a wiki are available on GitHub.

This is the fragment shader for generating these Julia Sets:

    std::string fragmentSource =
        "#version 330 core\n"
        "uniform vec2 c;"
        "uniform vec2 p;"
        "uniform vec2 ul;"
        "uniform vec2 lr;"
        "uniform vec2 viewDimensions;"
        "uniform vec4 color[50];"
        "out vec4 OutColor;"
        "vec2 iPower(vec2 vec, vec2 p)"
        "{"
        "    float r = sqrt(vec.x * vec.x + vec.y * vec.y);"
        "    if(r == 0.0f) {"
        "        return vec2(0.0f, 0.0f);"
        "    }"
        "    float theta = vec.y != 0 ? atan(vec.y, vec.x) : (vec.x < 0 ? 3.14159265f : 0.0f);"
        "    float imt = -p.y * theta;"
        "    float rpowr = pow(r, p.x);"
        "    float angle = p.x * theta + p.y * log(r);"
        "    vec2 powr;"
        "    powr.x = rpowr * exp(imt) * cos(angle);"
        "    powr.y = rpowr * exp(imt) * sin(angle);"
        "    return powr;"
        "}"
        ""
        "void main()"
        "{"
        "    float x = ul.x + (lr.x - ul.x) * gl_FragCoord.x / (viewDimensions.x - 1);"
        "    float y = lr.y + (ul.y - lr.y) * gl_FragCoord.y / (viewDimensions.y - 1);"
        "    vec2 z = vec2(x, y);"
        "    int i = 0;"
        "    while(z.x * z.x + z.y * z.y < 4.0f && i < 200) {"
        "        z = iPower(z, p) + c;"
        "        ++i;"
        "    }"
        "	 OutColor = i == 200 ? vec4(0.0f, 0.0f, 0.0f, 1.0f) : "
        "        color[i%50 - 1];"
        "}";

If you compare this to the fragment shader for the Multibrot Sets included in the post Mandelbrot Set, you will see few changes.

Summary

This post discussed Julia Sets and showed images of some Julia Sets generated from several points inside and outside the Mandelbrot Set. The fragment shader that is used to generate the images was also shown.

Mandelbrot Set

Complex Numbers and the Complex Plane

Before we discuss and generate the Mandelbrot set, we need to look at complex numbers, the complex plane, and Euler’s formula. If you are familiar with these concepts, then you can skip to the next section in this post. Or, if you can’t stand the math, just go look at the pretty pictures. 🙂

A complex number is of the form a + bi, where a and b are real numbers and i is defined such that i2 = -1. Note that i is defined only in terms of what the value of i2 is, and not by itself. You might quickly think that i = sqrt(-1), but this is only one of the roots of the equation. In fact, as my university algebra professor showed, by defining i this way, it is possible to prove that -1 = +1. That would certainly negate all of mathematics (and physics) as we know it.

Complex numbers are required to solve equations for which there is no real solution. Take for example:

(x + 1)2 = -9

There are no real number values for x that satisfy that equation. However, as shown here, there are two complex number values that do satisfy the equation:

x = -1 + 3i, and

x = -1 -3i.

A complex number can be viewed as a point or a position vector plotted in a two-dimensional Cartesian coordinate system. This is called the complex plane. Complex numbers are normally plotted such that the real portion of a complex number x + yi is plotted with the x value along the horizontal axis, and the y value plotted along the vertical axis.

Now that we have plotted a complex number in the two-dimensional Cartesian coordinate system, it is possible to specify the complex number using polar coordinates, and finally, using Euler’s formula.

See the Wikipedia page on Complex numbers for more information. Using Euler’s formula, it is even possible to calculate the complex power of a complex number. The Wolfram Mathworld website contains a web page that shows the formula for calculating these values. And finally, the Abecedarical Systems website contains a web page with the listing of a program that calculates the complex power of a complex number.

Now, why do we need all of this mathematics? C++ contains a templated complex number class, but GLSL does not support complex numbers. Therefore, to calculate the complex power of a complex number using GLSL, it will be necessary to use Euler’s formula. You will see this later when we look at the GLSL code for the fragment shader.

Mandelbrot Set

Now that we have covered some rather heavy mathematics, we can look at the Mandelbrot set. Assuming z0 = 0 and c is a point in the complex plane, then the Mandelbrot set is the set of all points c in the complex plane where the value zn+1 does not tend toward infinity as n approaches infinity in the following equation:

zn+1 = zn2 + c.

If we attempt to iterate this formula an infinite number of times for each point in the complex plane, the calculations will of course take an infinite amount of time. There are two pieces of information that we an use to limit the number of calculations:

  1. For all values of zn where |zn| ≥ 2, the value approaches infinity as n approaches infinity.
  2. As n increases, the set of points approaches the Mandelbrot set quite quickly. There is little difference between the points defined by z200 and z.

The program, ChaosExplorer, uses these two facts to limit the number of iterations that are required for each point. ChaosExplorer is a C++ program that uses wxWidgets for the windowing system, and GLSL to calculate and display the points that are inside and outside the Mandelbrot set. The majority of the code will not be shown or discussed in this post because similar or identical code has been covered in earlier posts. The program code is available on GitHub.

When ChaosExplorer starts, it displays the Mandelbrot set, shown below, in a tabbed window in the main window of the program.

Mandelbrot

 

This image shows the complex plane for -2.5 < x < 1.5 and -2.0 < y < 2.0. The portion in black is the Mandelbrot set. The colours change as the number of iterations (n) required for zn to exceed the value 2 increases. There are 50 colours used, with the full set repeated 4 times for a total of 200 iterations.

You can select an area to zoom in on by pressing the left mouse button and dragging towards the right and down. As you select an area, the area is highlighted by a white line around the selection. When you have chosen the area you want to select, release the left mouse button. A selection is shown in the image above. Now to zoom into that area, click the right mouse button anywhere in the image to display the context menu, and select the Draw From Selection menu item. The resulting display is shown in a second tabbed window. Here is the result for the region selected in the image above:

Mandelbrot2

Note the smaller version of the main Mandelbrot set. You can continue to zoom in on the tendrils, such as the next image, to see ever smaller versions of this set. This shows that the Mandelbrot set is a fractal.

You can also animate the zoom by placing the mouse cursor at the point you want to zoom, clicking the right mouse button, and selecting Animate Magnification from the context menu.

Here are some additional zoomed images:

Mandlebrot4

Mandelbrot3

Mandelbrot5

and a video of a zooming image:

To redisplay the full Mandelbrot set, select the Power=2 menu item in the MultibrotPower submenu.

Above, I stated that points selected by each iteration quickly approaches the Mandelbrot set as the number of iterations increases. You can see this by selecting the Animate Iterations menu item in the context menu. The image will change for each iteration, showing the pixels that are excluded by each iteration. You can run this animation at any zoom level.

I leave it to you as an exercise to investigate the various regions of the image at varying magnifications.

So, how are the images calculated and drawn? The calculations are done in the fragment shader:

    std::string fragmentSource =
        "#version 430 core\n"
        "uniform vec2 z0;"
        "uniform vec2 p;"
        "uniform vec2 ul;"
        "uniform vec2 lr;"
        "uniform vec2 viewDimensions;"
        "uniform int maxIterations;"
        "uniform vec4 color[50];"
        "out vec4 OutColor;"
        "vec2 iPower(vec2 vec, vec2 p)"
        "{"
        "    float r = sqrt(vec.x * vec.x + vec.y * vec.y);"
        "    if(r == 0.0f) {"
        "        return vec2(0.0f, 0.0f);"
        "    }"
        "    float theta = vec.y != 0 ? atan(vec.y, vec.x) : (vec.x < 0 ? 3.14159265f : 0.0f);"
        "    float imt = -p.y * theta;"
        "    float rpowr = pow(r, p.x);"
        "    float angle = p.x * theta + p.y * log(r);"
        "    vec2 powr;"
        "    powr.x = rpowr * exp(imt) * cos(angle);"
        "    powr.y = rpowr * exp(imt) * sin(angle);"
        "    return powr;"
        "}"
        ""
        "void main()"
        "{"
        "    vec2 z = z0;"
        "    float x = ul.x + (lr.x - ul.x) * gl_FragCoord.x / (viewDimensions.x - 1);"
        "    float y = lr.y + (ul.y - lr.y) * gl_FragCoord.y / (viewDimensions.y - 1);"
        "    vec2 c = vec2(x, y);"
        "    int i = 0;"
        "    while(z.x * z.x + z.y * z.y < 4.0f && i < maxIterations) {"
        "        z = iPower(z, p) + c;"
        "        ++i;"
        "    }"
        "	 OutColor = i == maxIterations ? vec4(0.0f, 0.0f, 0.0f, 1.0f) : "
        "        color[i%50 - 1];"
        "}";

GLSL does not contain a complex data type, so complex values are passed in as vec2 uniform values. The iPower function calculates the complex power of a complex number using Euler’s formula as mentioned in the first section of this post. For integer real powers of complex numbers, the mathematics could be simplified considerably, but the full calculation in iPower is included because it will be used in other functionality in this program.

Finally, the main function performs repeated iterations of the formula zn+1 = znp + c until the magnitude of zn+1 exceeds the escape value of 2. c is the complex number that specifies the coordinates of the point in the complex plane. The color for the fragment is then determined from the number of iterations (the value of i in the code). This video shows the full Mandelbrot set as the number of iterations increases. The number of iterations is shown in the status bar at the bottom of the window. Once the number of iterations exceeds about 40, the only place you will see any changes at this zoom level is at the junction between the main bulb and the bulb to its left.

Advantages and Disadvantages of Performing the Calculations in the Fragment Shader

Advantages

The main advantage is the speed at which the image is calculated and drawn. Using modern GPUs with hundreds or thousands of cores, the image can be updated at the rate of many frames per second as seen when animating the magnification. If the image was calculated in the CPU, the number of frames per second that could be generated is much less (around 1 frame per second) even if the code were multithreaded.

Disadvantages

  1. GLSL does not contain a complex data type, so Euler’s formula must be used to calculate a complex power of a complex number.
  2. Since version 4.0.0 of OpenGL, GLSL supports the double data type, but trigonometric functions are supplied only for floating point values. This means that the complex numbers can be specified only as two floating point numbers and not as two doubles. As the zoom factor of the image increases. the limitations on the values of floating point numbers become a factor, and pixelation of the image occurs much sooner than would be the case if doubles could have been used. Note the pixelation in the following image:

pixelated

Summary

This post discussed the Mandelbrot set and the ChaosExplorer program. Several images of the Mandelbrot set are shown, as are examples of the Animate Iterations and Animate Magnification functions of the program.

The Mandelbrot set is a specialization of the formula zn+1 = znp + c where p = 2. The next post will look at the more general Multibrot set, wherein p takes on other values, including complex values.

More information about ChaosExplorer and the Mandelbrot Set are included in the wiki for the ChaosExplorer program on GitHub.

CirclesAndRotators Design And Coding Decisions

The previous five posts, starting with Drawing Circles With OpenGL, and finishing with Adding a Moving Triangle, created an increasingly complex program that displayed two circles and a triangle moving about the drawing canvas. A number of design and coding decisions were made when the program was written. This post will discuss these decisions, and in so doing help describe some of the efficiencies and inefficiences that can result when using OpenGL.

OpenGL C++ Libraries?

The CirclesAndRotators program uses the OpenGL C API directly, well through GLEW. There are C++ wrapper libraries available, but they were not used, because I am starting to learn OpenGL, and introducing wrapper libraries at this stage would confuse the issue, and probably reduce the meager readership that I currently have.

There are at least three C++ wrapper libraries:

  1. OGLplus;
  2. OOGL; and,
  3. glbinding.

All of these are open source with source code on GitHub. OGLplus is actively maintained, while OOGL has not had any updates for two years and has bugs that have been outstanding for four years. glbinding uses C++11 features such as enum classes, lambdas and variadic templates rather than MACROs. It is both actively maintained, and comes with commercial support if needed. I leave it to you to decide if you want to use any of these, but before doing so, read this discussion from StackOverflow.

How A Circle is Defined

It is possible to define a circle in terms of many triangles with one vertex at the centre of the circle and the other two vertices on the edge of the circle. The more triangles you use, the more closely the drawn object looks like a circle rather than a polygon.

I chose instead to simply define the smallest square that completely encloses the circle, and, in the fragment shader, to discard pixels outside the circle. This method works for circles of any size; it also illustrates some of what it is possible to do in shaders.

glUseProgram

In the OnPaint method in CirclesAndRotatorsCanvas, glUseProgram is called to set the circle shader program, then the two circles are painted. glUseProgram is called again, this time to set the triangle shader program before the triangle is painted.

An alternative to this would be to place the glUseProgram calls in the glCircle and glEquilateralTriangle Paint methods. However, the glUseProgram is expensive in terms of the work that the GPU must perform to switch shader programs. Therefore, the fewer program switches, the better your program will perform. In general, if you can, code your program to limit the number of shader program switches. Now in the CirclesAndRotators program, you will not perceive any difference between having the glUseProgram calls in OnPaint and in the Paint methods for each object. However, once a program has many thousands of objects, there will be a noticeable difference in performance. In general, try to call glUseProgram once, paint all of the objects that use that shader program, then call glUseProgram for the next set of objects, and so forth.

Perform Transform in CPU or GPU?

Most graphics programs are designed such that objects are created to be centred on the origin of the display canvas, and then transformed to their final location; this is especially true for objects that are moved about the canvas whenever a frame is painted.

There are two places these transformations can be performed:

  1. By the CPU before moving the vertex data to the GPU; and,
  2. By the GPU.

The second is preferred for a number of reasons:

  1. CPU’s typically have between 2 and 16 logical cores. You could create multiple threads to calculate the final position of each vertex and pass the vertices using vertex buffers to the GPU each time the frame is painted, but how quickly you can perform the transformations on the vertices is limited by the number of logical cores in the CPU. Alternatively, you could pass the initial vertices in a vertex buffer once, and pass the transform via a uniform each time the frame is painted. Modern GPUs are optimized for parallel processing, and may contain hundreds or thousands of cores to perform the processing. For complex objects that contain many vertices, performing the transformation in the GPU is much more efficient.
  2. Transforming the vertices in the CPU performs work that can be performed in a vertex shader, but what happens if you need access to the transform elsewhere in the graphics pipeline. For example, in the circle fragment shader in the CirclesAndRotators program, the transform is required so that each fragment can be transformed to determine if it is inside or outside the circle. The transform information is not available to the fragment shader if the vertices are transformed by the CPU.
  3. For programs that display a large number of objects, each containing a large number of vertices, the vertex buffers that are transferred would be very large in comparison to the 16 values that are passed in a transformation matrix. Moving data to the GPU is a relatively time-consuming operation whose time is determined to some extent by the size of the data being moved. Transporting a large amount of data every time a frame is painted by the GPU takes more time than transporting a large amount of data once and smaller amounts of data each frame.

For the reasons given above, it is generally better to perform transformations in shaders (by the GPU) rather than in the program (by the CPU).

Where To Apply Multiple Transforms

In the CirclesAndRotators program, there are two transforms created for each circle that are then multiplied together to form a composite transform. For the triangle, there are four transforms created. These are then multiplied together to form a composite transform. The composite transforms are passed to the shaders where they are applied to the vertices in the vertex shader, and also in the fragment shader for circles.

An alternative would be to pass all of the individual transforms to the shaders and multiply them together there. However, the result of multiplying the individual transforms together is always the same each time a frame is drawn, so multiplying the transforms together for each vertex, and each fragment in the case of the circles, is performing a large amount of unnecessary work. Therefore, only the composite transforms should be passed as uniforms to the shaders.

Note also that in the circle fragment shader, the centre of the circle is calculated for every fragment, but this result is always the same when a circle is painted. Therefore, this calculation should have been done in the CPU, with the result being passed as a uniform.

Summary

This post has discussed some of the design and coding decisions that I made when writing the CirclesAndRotators program. A number of options were discussed, and the better or best choice as related to drawing efficiency were noted.