A very strange idea; vector to the Mandelbrot

[Timeroot]

Okay, yesterday I had a really weird idea, and I'm pretty sure no-one has ever done something like this before.

For each pixel, use Distance and Direction Estimation to find the vector to the nearest point in the Mandelbrot set (or outside the set, if the pixel starts out inside). Then, use this new vector (a complex number, really, not a vector) as your next pixel. Repeat the process, over and over. If you begin with a pixel in the set, it's "bailout" occurs as soon as some new iteration is outside the set; vice versa if your initial pixel is outside the set.

Note that this idea could be applied to any fractal; a Julia set, for example, where you estimate the distance to the border.

Simply doing this may not be very aesthetic; maybe something like (say) rotating the vector 90 degrees and multiplying the magnitude by sqrt(2) would produce more intereting results, or halving the radius of the pixel (keeping the angle the same) and then shifting it according to the vector. Or maybe instead of halving, taking the reciprocal of the logarithm of the pixel. I don't know what would produce interesting results.

The coloring would be done by the "iterations" it takes to bailout.

Sadly, there are several features here I wouldn't be able to code; for example, I don't know any formula (maybe there isn't one?) to approximate the direction to the border to the mandelbrot set; I also don't know of any way to do distance estimation from the interior of the Mandelbrot. I suppose those could be done with a nested loop, but in general I only program using FractInt format...I've never changed to any higher level language. Any help generating pictures like this would be greatly appreciated. 

[Tglad]

Easiest way to start might be to store a medium res mandelbrot as point data and do a brute force (or quad tree) search to find the nearest point on the border.
It would give a feel for its shape.

The resulting pattern would not be connected or continuous because the nearest point can change suddenly as you move the pixel around. In fact it would probably always be changing in a scattered-like way so the resulting shape would be very noisy and dusty I would predict.

[Timeroot]

Yes, maybe a small scale it would become very dusty, but at least from a distance (this is with the "offset" idea) I think it would take an interesting shape; for points very far, for instance, the iterations would be approximately proportional to the distance; then, as, iteration by iteration, it got closer to the mandelbrot, it would start to take interesting bifurcations. Also, I think the dust might eventually resolve itself into interesting shapes given enough zoom - Just like the Logistic map's chaotic parts look like pure white noise, but reveal a infinite series of windows if you zoom in. Of course, I hope this would be more interesting than the logistic map.

[jwm-art]

Yes, maybe a small scale it would become very dusty, but at least from a distance (this is with the "offset" idea) I think it would take an interesting shape; for points very far, for instance, the iterations would be approximately proportional to the distance; then, as, iteration by iteration, it got closer to the mandelbrot, it would start to take interesting bifurcations. Also, I think the dust might eventually resolve itself into interesting shapes given enough zoom - Just like the Logistic map's chaotic parts look like pure white noise, but reveal a infinite series of windows if you zoom in. Of course, I hope this would be more interesting than the logistic map.

But because the relationship you are rendering is between pixels it would be impossible to zoom! For every zoom the image would be utterly different. EDIT: Ie you computer your vector for a pixel and then doing something which seeds the computation for the next pixel. As soon as you zoom in, these two pixels could be a hundred pixels apart, so that the first pixel is no longer seeding the same pixel. That's what Tglad meant by saying it would not be continuous, but an ever-changing dusty and scattered noise.

[Timeroot]

But it wouldn't actually be in pixels, the vector (difference?) would be a complex number. 0.0+1.5i would give a difference of 0.5i no matter how much you zoomed in.

[jwm-art]

But it wouldn't actually be in pixels, the vector (difference?) would be a complex number. 0.0+1.5i would give a difference of 0.5i no matter how much you zoomed in.

Sorry my bad, I misread your original post   

so you're basically going to perform the iterative m-set calculations pixel by pixel... For each of these pixels, also calculate with distance/direction estimation, the coordinates of another pixel - which you then have to perform the iterative m-set calculations on to determine if this new pixel is inside or outside - which will tell you if the pixel you're attempting to render is to bail out or not. So a kind of iterative loop with recursion? Are you mad

[Timeroot]

But it wouldn't actually be in pixels, the vector (difference?) would be a complex number. 0.0+1.5i would give a difference of 0.5i no matter how much you zoomed in.

Sorry my bad, I misread your original post   

so you're basically going to perform the iterative m-set calculations pixel by pixel... For each of these pixels, also calculate with distance/direction estimation, the coordinates of another pixel - which you then have to perform the iterative m-set calculations on to determine if this new pixel is inside or outside - which will tell you if the pixel you're attempting to render is to bail out or not. So a kind of iterative loop with recursion? Are you mad

Yup, that's exactly what I want to do. And yes, I am mad. Insanity produces some pretty interest fractals, occasionally... isn't the very concept of a fractal somewhat insane? 

I'm not sure if I'd call it an "iterative loop with recursion", I just see it as two nested loops instead of single one. And, if there is no simple formula for direction estimation, then that would have to be calculated manually by another loop, a "sibling" in the loop structure to the actual squaring/adding loop. And if you think that I belong in a mental hospital: things like that have been one before. Take a look at the Supermandelbrot and Superjulia; they also use two nested loops.

[jwm-art]

I don't think you're really mad.  It's a mad sounding idea. I looked at the supermandel/superjulia threads on here. I've experimented with something a little like that. I used a system I called auto-layering where the bailout/perturbation values were ramped across the layers. Produced some interesting effects but far too slow for general use.

I hope you try your idea out, it could produce some interesting results.

[Timeroot]

Well, I've started playing round with how to do the formula... even very simple things to test parts of the code aren't working, though. In order to make the code easier to write, I defined several new functions. Here's some code to test them, which seems to deadlock every time it tries to compute a point within the set. Even if I only set iterations to two, and I haven't zoomed at all!
VectorToMandelbrot {
global:
init:
float func MandelbrotDistance(const complex c, const int MaxIter)
  DpDc=1
  t=0
  repeat
   t=t^2 + c
   Iter=Iter+1
   DpDc=2*DpDc*t + 1
  until (|t| > 4) || (Iter == MaxIter)
  return log(|t|)*sqrt(|t|/|DpDc|)
 endfunc
 bool func InMandelbrot(const complex c, const int MaxIter)
  t=0
  repeat
   t=t^2 + c
   Iter=Iter+1
  until (|t| > 4) || (Iter == MaxIter) ;@InnerIter)
  return (Iter == MaxIter) ;@InnerIter)
 endfunc
 int func MandelbrotEscapetime(const complex c, const int MaxIter)
  t=0
  Int Iter = 0
  repeat
   t=t^2 + c
   Iter=Iter+1
  until (|t| > 4) || (Iter == MaxIter)
  return Iter
 endfunc
loop:
bailout: InMandelbrot(#pixel,10)
}

Basically, this means that at the end of each iteration it runs the Mandelbrot forumla with 10 iterations. Obviously this doesn't do anything more than make a Mandelbrot set that takes longer to load, but it shouldn't deadlock each time it reaches a pixel inside. Help please?