Plotting field lines during iteration...

[Chris Thomasson]

Plotting field lines during iteration...

Hello everybody! My name is Chris M. Thomasson and I am very interested in gaining a deeper understanding of fractals. This is my first post...

When I first started plotting field lines on fractal points, I was literally plotting a charge per point, then running them through one of my vector field plotters in order to gain the fractals overall field, and associated perpendicular equipotential field. This required two steps. Also, I was using IFS because they more naturally support the dynamic generation of a fractal point, instead of checking to see if a given point is “valid” or not. However, during a late night of experimentation, I discovered a very simple, perhaps naive method for generating a field and equipotential plot without using an IFS.

So far, it seems to be compatible with basically any escape time fractal. Here is some quick and dirty pseudo-code of the basic algorithm, where Z is the current point; ZP is the previous point; C is the constant point; I is the iteration count; N is the threshold of I, and G is the “granularity level” of the resulting “field lines”:
_________________________________________________
Z = ZP = C;
G = 100.0;

for (I = 0; I < N; ++I)
{
    // Mutate Z, e.g. (Z = Z^2 + C)

    if (Z.real() / ZP.real() > G && Z.imag() / ZP.imag() > G)
    {
        // The point C escapes.
        // Color using traditional methods.

        return;
    }

    ZP = Z;
}

// We assume that C does not escape.
// Color using traditional methods.
_________________________________________________


Divide-by-zero conditions aside for a moment, this escape condition sure seems to end up producing plots that contain detailed field lines. Here are some simple examples:



https://plus.google.com/101799841244447089430/posts/YoktF5J94jb

https://plus.google.com/101799841244447089430/posts/KfEa5LR9tV3

https://plus.google.com/101799841244447089430/posts/7kvthiEkLTq


As I think this should not be anything new, I am wondering if anybody has seen this technique before? If so, could you please provide me with some references to further information?

Thank you everybody: this group is simply excellent!

:^)

[Adam Majewski]

Hi Chris,

Nice image. Thx for algorithm.

I was not used such algorithm, but similar image can be made using :
* external angle :
* * http://fraktal.republika.pl/cpp_argphi.html
* *  http://www.fractalforums.com/programming/smooth-external-angle-of-mandelbrot-set/msg80726/#msg80726
* triangle inequality : http://www.ultrafractal.com/help/index.html?/help/coloring/standard/triangleinequalityaverage.html
* decomposition of set's exterior  :
** http://fraktal.republika.pl/mset_decomposition.html
** https://eudml.org/doc/232574
** https://commons.wikimedia.org/wiki/File:Julia_IIM_6_basilica.png
** https://commons.wikimedia.org/wiki/File:Mandelbrot_d_9.png

 

[cKleinhuis]

hey, nice pic

i hope you find some inside browsing my iteration visualisations, check them out here (for the mandelbrot)
http://www.fractalforums.com/index.php?action=gallery;cat=104

[Chris Thomasson]

Thanks so much for the excellent information Adam and cKleinhuis!

I really do appreciate it.

:^)


IMVVVVHO:

Adam, finding the arguments per-turn does work great, however, keeping a previous point and performing division of the components that make up the current and previous points also seems to create a "valid" vector field. IMVVVHO, the algorithm I posted is a bit simpler than solving differential equations, something like Runge-Kutta.

What do you think? Is my statement here total crap?

Yikes!


:^o

[Chris Thomasson]

FWIW, here is a field of a Julia set using the posted algorithm:

[cKleinhuis]

it looks quite interesting that filling method the colors are a bit coder-colors like but the general layout is cool

[claude]

I tried it in Fragmentarium (just hacked the different escape criteria in to the Mandelbrot example).  Looks fine, until you zoom in:

[claude]

Instead I suggest tweaking binary decomposition to make smoothly narrowing lines, here's the rough outline:

Code:

float twopi = 6.283185307179586;
float escapeRadius = 1.0e8;  // larger makes longer thinner segments, but beware overflow
float escapeRadius2 = escapeRadius * escapeRadius;
float lineWidth = 0.05;  // freely adjustable
vec3 lineColour = vec3(0.0, 0.0, 0.0);
vec3 baseColour = vec3(0.0, 0.7, 1.0);
vec3 colour(vec2 c) {
  vec2 z = vec2(0.0, 0.0);
  for (int i = 0; i < maxIters; ++i) {
    z = cmul(z,z) + c;
    if (dot(z,z) > escapeRadius2) break;
  }

  // this is the key transformation function
  float fx= atan(z.y, z.x) / twopi;  // angle within cell
  float fy = log(length(z)) / log(escapeRadius);  // radius within cell
  float fz = pow(0.5, -fy);  // make wider on the outside
  float fieldLine = float(abs(fx) > lineWidth * fz);

  return mix(lineColour, baseColour, fieldLine);
}

[Adam Majewski]

... the algorithm I posted is a bit simpler than solving differential equations, something like Runge-Kutta.

Yes.

 I'm not a mathematician so I can only guess that your method is approximates external angle like atom domains :
http://mrob.com/pub/muency/atomdomain.html
helps find exact hyperbolic domains in short time.



 

[Chris Thomasson]

I tried it in Fragmentarium (just hacked the different escape criteria in to the Mandelbrot example).  Looks fine, until you zoom in:

Thank you for giving it a go. I get the exact same glitch when the value for G is too low. In the example algorithm I posted, G is set to 100. Could you try it again with a value of 10000 or so? Those glitches should go away. I will render a couple of images, one with a glitch due to G being too small, and another with the glitches fixed because G is big enough.

[Chris Thomasson]

FWIW, here is a link to two renderings of the same location. One of them has G set to 100, which to too low for this level of zoom and ends up producing some rather unpleasant artifacts. The other rendering has G set much higher at 10000, and the glitches disappear...


Sorry about the crappy coloring here, I just quickly created these!

;^(

[Chris Thomasson]

FWIW, here is an older rendering of mine that plots a vector field using points generated by a Julia IFS. This takes longer to compute than the field line generating escape condition I posted here.

;^)

 

[cKleinhuis]

are you aware of line integral convolution vector field visualisation?
http://de.wikipedia.org/wiki/Line_Integral_Convolution

[Chris Thomasson]

are you aware of line integral convolution vector field visualisation?
http://de.wikipedia.org/wiki/Line_Integral_Convolution

> are you aware of line integral convolution vector field visualisation?

Not really. I know some brief aspects of the technique because I was trying to find a better way to color a high number of field lines per-point. This ends up creating a very dense plot, which could benefit from a better coloring algorithm indeed. The plot would sometimes be all pixels white, which ends up resembling a sheet of paper, not a graph. Yikes!

I am wondering if I could use the escape method I posted here to visualize an arbitrary user-defined set of points. It should end up coloring each point on the plane such that the flow of the field can be observed; humm...

Thank you.


BTW, I managed to find a fairly interesting paper on the method:

http://www.impa.br/opencms/pt/ensino/downloads/dissertacoes_de_mestrado/dissertacoes_2009/Ricardo_david_castaneda_marin.pdf

[cKleinhuis]

cool paper, yes, line integral convolution is very mighty, i love seeing them in motion ! snapshoting a vector field and seeing its motion distribution is just cool