Best Mandelbrot Bailout Methods

[Timeroot]

Antibuddhabrot is a certain variation the Mandelbrot Set - it plots the orbits of all points inside the Mandelbrot Set. By using bailout methods that eliminate different areas that aren't in the Antibuddhabrot, we can create more efficient algorithims. But in order to see where the Antibuddhabrot set goes, we need a render with a lot of sample points, so we can see the full fractal - otherwise might cut out parts of the Mandelbrot Set unintentionally.

Right now I have one going (the "Buddhabrot" coloring algorithm in lkm3.ucl) with random points from the region -2<=x<=1, -1.2<=y<=1.2, with a "Sampling factor" of 300. Each point is tested with 300 iterations to see if it is inside or outside. So far, it's been going for 10 minutes...

[Timeroot]

I've got one picture of the Antibuddhabrot to hopefully help get better bailouts... I overlayed a regular Mset for scale. It took 4:58:17 to render it. It has 1000 iterations to test, and a sampling factor of 1500.

[johandebock]

I can render one if you want. But I must exactly know what you want to see if it's possible to render with what I now have.

But don't see the point, in the end many cutting planes will make the calculation much slower than one radius test no?
Or is it just to limit the drawing plane?

[johandebock]

Here you have a 1000x1000, 200 bailout, Anti-Buddhabrot render, (edit:  forgot to adjust zoom  ):

[Timeroot]

Thank you! Your coloring also seems to have worked better than mine. Although it's true that may "cutting planes", as you call them, will slow the calculation down considerably, there may be some efficient methods. For example, there might be one area we discover where, once a point goes in, it has an unstable period-2 behavior until it escapes. Then we would use that bailout test once every 5 iterations, say. If several points spent a long time exiting that period-2 cycle, then it would save a lot of time. This is an example of a more complex example, but do you see my motivation here? Another one: Maybe some of the "Miniantibuddhabrots" (long name  ) only are entered from certain pixels/areas. If a point enters one of these, and we know it's not one of those areas, we could use much simpler bailout methods after that - maybe excluding the entire antenna or something.

Some of these might be too complex to actually ever be noticed, and some might indeed be outweighed by their computation time... but this thread's title is "Best", not "Most".

[Pauldelbrot]

I doubt most of these methods will do much more than shave 5-10 iterations off per pixel. The most intriguing suggestion here is to sample the image boundary, guess a lower bound on iterations, and do no bailout test at all until then.

Arbitrary precision multiplication can be reduced to n*log(n) or so in bits, but with a big enough constant factor that the naive n^2 algorithm is preferred for bit lengths much below several hundred.

SIMD seems most useful for doing multiple whole pixels in parallel -- particularly if there is no bailout possible for a while, i.e. the image's minimum iteration is high. Throw a GPU at one of those and it could make a BIG dent.

Finally, uglification of the image is avoidable if you find a serious (reduces per-pixel work by x%, not just by n iterations) speedup that alters the bailout contour, given you can efficiently (now you know a point escapes) determine on which iteration it crossed the traditional bailout contour and use that information in coloring. (For example, if additional iterations are needed to exit the traditional contour, those iterations can be performed without testing for cycles/other attractors being hit now that you know which attractor DID get hit.)

[quaz0r]

just ran across this old thread... i dont know if everyone else does this too or if there is some good reason not to do it, but i do 4 consecutive iterations then check for minimum bailout, when that is hit i roll back 4 iterations and then do the standard loop of one iteration then check for user-set bailout value.  this reduces the number of |z| computations and bailout checks to 1/4, and the speed gains are very tangible.  ive been doing this for quite a while and dont seem to have any problems with it.  come to think of it i think i was at the time stupidly checking the (higher) user-set bailout value when i was originally testing this, and found that more than 4 consecutive iterations could result in overflow, so i stuck with 4.  now i wonder if maybe you can actually get away with more than 4.  hmm...  so back to my original question i guess, does anyone else do this?  if so, how many consecutive iterations are you doing?

[ker2x]

just ran across this old thread... i dont know if everyone else does this too or if there is some good reason not to do it, but i do 4 consecutive iterations then check for minimum bailout, when that is hit i roll back 4 iterations and then do the standard loop of one iteration then check for user-set bailout value.  this reduces the number of |z| computations and bailout checks to 1/4, and the speed gains are very tangible.  ive been doing this for quite a while and dont seem to have any problems with it.  come to think of it i think i was at the time stupidly checking the (higher) user-set bailout value when i was originally testing this, and found that more than 4 consecutive iterations could result in overflow, so i stuck with 4.  now i wonder if maybe you can actually get away with more than 4.  hmm...  so back to my original question i guess, does anyone else do this?  if so, how many consecutive iterations are you doing?

Thx for the tips, will try