Buddhabrot optimizations

[ker2x]

Ho ...

And don't refresh your screen everytime you find an orbit.
Drawing (javascript or not) is SSSSSSLLLLLOOOOOOOOOWWWWWWWW !!

[Ryan D]

Have you considered simply ignoring whether they are in the M-set or not?  Points which escape quickly will not have much effect on your histogram.  They fall out of the iteration loop quickly and contribute very little to increasing the hit count of any individual pixel.  A very simple solution to that is to simply not plot the first few iterations - a classic escape-time view of the M-set looks almost the same after 20 iterations as it does after 2000 iterations, so just ignore the first 20 iterations before you start updating the hit count on the individual pixels.

Points which are very close to the border and require hundreds of iterations will follow a path very similar to the points just barely over the border, and only the last few iterations will vary significantly.  Again, that's only a few iterations and those will have very little effect on increasing the hit count of any individual pixel.

I play around a fair bit with orbit path Buddhabrot-style fractals, and I always ignore whether the point being tested escapes or not.  I'm old school, so I still have enough fun with Fractint that I'm not ambitious enough to bother updating to anything more current - probably I will some day, but I'll treat that as a retirement project!  In Fractint, you don't have the option of ignoring the first iterations, so you usually get a regular grid resulting from the first iteration or two, but if the colour scheme is set so that the lowest hit counts are the faintest colours, then you hardly notice that.  Here's one of my favourite orbit path animations, ignoring whether the points fall in or out of any set.

<a href="http://vimeo.com/moogaloop.swf?clip_id=49084660&amp;amp;server=vimeo.com&amp;amp;fullscreen=1" target="_blank">http://vimeo.com/moogaloop.swf?clip_id=49084660&amp;amp;server=vimeo.com&amp;amp;fullscreen=1</a>

Ryan

[ker2x]

Yes yes, of course.

All my codes have a min & max iteration, for each color

So you can have a buddhabroth like this :
RED : 100->1000 iterations
GREEN : 500 -> 1500
BLUE = 1000->3000

and 0 to 100 aren't drawn. any orbit with low iteration count (here < 100) are not drawn.

[cKleinhuis]

What i dont like about the buddhas is the random distribution of starting positions
i think interestin patterns could be found by somehow generalized aproach to scan a grid at least to check out what very dense starting positions vary . . .

[asimes]

ker2x, I don't think I follow a few of your posts and I think you either did not follow my explanations or misunderstood my code.

"You can't now for sure that something isn't in the mandelbrot set.
What you can now for sure is that some points are in the Mandelbrot set"

I don't see why I can't. Before I run the orbit trap loop I determine if each pixel is in the Mandelbrot Set. If it is I ignore it otherwise I add it to my nonMSet array. Any pixel in nonMSet it is guaranteed not to be in the Mandelbrot Set.

You test the infinitesimal point that is at the center of your pixel. But can you now for sure that the infinity of point/coordinates that are in this pixel are also in the mandelbrot set ?
You can't.

I pick a random pixel in nonMSet and add a random deviation in the range (-0.5 to 0.5) to its x and y values. The reason I am using -0.5 and 0.5 is because that theoretically means every pixel inNonMSet is now an area of random points (an area of the length of a pixel by the length of a pixel). I say theoretically because of floating point inaccuracy.

This does mean that one of the pixels chosen from nonMSet + random deviation could now be in the Mandelbrot Set, so that is why I test for it in the orbit trap code. I could add the quick rejection tests there, but otherwise I am doing the exact same thing.

And don't refresh your screen everytime you find an orbit.
Drawing (javascript or not) is SSSSSSLLLLLOOOOOOOOOWWWWWWWW !!

I'm not? I'm drawing the screen after 10,000 orbit traps are attempted (not all of them pass the not-in-the-Mandebrot-Set test).

[asimes]

Ryan D, That sounds like a promising idea, I will try it out

Edit: Still using my code the way it was but only adding orbit traps if their iterations count is > 20:
- Low maximum iteration counts fail often (they don't pass the acceptable-orbit-trap test often)
- A lot less noise around the image, looks nicer when the glowing cloud around the Buddhabrot hugs tighter instead of being spread out in a circle. Also builds a nice looking Buddhabrot without noise much faster.
- The glowing cloud around the Buddhabrot is affected in the sense that it kind of looks like a Buddhabrot rendered at 20 maximum iterations. In the picture below there is some lightning-looking stuff (I actually like it) around the head that never appeared before without the > 20 test.

Normal result for red max iterations = 1,000,000; green max iterations = 10,000; blue max iterations = 100:


Result of doing the n > 20 test for red max iterations = 1,000,000; green max iterations = 10,000; blue max iterations = 100 (I did not wait very long by comparison to the other images for this to be produced, it is faster):


Normal result for all max iterations = 20 (for reference):

[ker2x]

Because you'll add in your ignorelist a lot of point that are at the frontier of the MSet and they are the most interesting orbits.

[asimes]

ker2x, I tried making a diagram in Photoshop to explain and realized a random range of (-0.5 to 0.5) does miss some points. Here is the diagram anyway:



- The small red squares are pixels that do not belong to the Mandelbrot Set
- The small green squares are pixels that do belong to the Mandelbrot Set
- The pink areas are the random deviation every red pixel has (only shown at the boundary of the Mandelbrot Set)
- The light green areas might be part of the Mandelbrot Set and I am missing those

I will change the code to use a random range of (-1.0 to 1.0) and then that will completely cover the boundary

[asimes]

I'm not really sure why putting the minimum iteration limit (x) on n makes it look like a maximum iteration (x). The maximum iterations here are the same as above, the only difference is that the random point contributes to the value buffers if n > 10):

Code:

if (n > 10 && n < maxIterations[inRGB])

[Roquen]

I have no clue about the scheme involved, but about quasi-random (LDS) instead of pseudo?

[matsoljare]

How about making a video of the iteration count increasing?

[asimes]

matsoljare, that would be really cool but other than just taking a lot of screenshots I don't know of an easy way to use JavaScript to render a movie. It looks like some other people on this thread also have Buddhabrot renderers, maybe they would be more prepared.

By iteration count increasing did you mean:
- The maximum iteration count for one / all the color channels
- The minimum iteration count that was confusing me in the last few posts
- Something else?