Help on first fractal maker

[David Makin]

I barely know any c based language so that was a bit confusing.
I'll have to look into it though because I know it will be faster than what I am using.

Probably my fault for writing it in a mix of C and BASIC syntax

[kronikel]

Any ideas on an equation?
I'm pretty stumped but I feel like I'm over thinking this

[David Makin]

I think you missed it:

http://www.fractalforums.com/programming/help-on-first-fractal-maker/msg24585/#msg24585

"^" is "to the power of" - in standard c you might have to use "scale = pow(2, 2-n)" I think - or is that "scale = pow(2-n,2)" ?

[kronikel]

Ahah! I didn't see that and I didn't think of that because my brain wanted to shut off when approaching negative exponents for some reason.
Output:= Pow(2, 2 - Input);

I think that's all I needed I'll try to throw it together and see what I get.

[kronikel]

Everything is working but I'm still left with the problem of it taking a lot longer to render when zooming in.
Now it does each pixel only once and I'm sure of it.
It does not execute more lines of code by zooming in on the fractal at all.
The only difference I see is that the numbers is uses get a log bigger.
Does computing a number like 1.203592928220659 take a long longer than just 1.2?
I've never noticed it before so I'm thinking even if larger numbers do take more time it can't make this much of a difference.

[ker2x]

Does computing a number like 1.203592928220659 take a long longer than just 1.2?

No. They are both 64bits floating point numbers on a 64bits CPU, it take exactly the same time.

[kronikel]

Edit:
Uggh I was changing the wrong variable when I was testing the max iteration problem and that actually was it.
If I set it lower I can render a high magnification in under a second now.

[Tabasco Raremaster]

"I can't figure out how to zoom in on the fractal without the time it takes to draw it increasing.
Every time I zoom in it takes a lot longer to draw out than the last time, even though the area drawn is the same size"

For as far as I know there is no fractal rendering program in where the rendering time does not increase with a higher zoom.
My sugestion is : Figure it out. Just do it!

[ker2x]

A lot of people seem to be talking about these complex and imaginary numbers.
I understand for the most part what they are but I don't use them in any way that I'm aware of.

You are drawing the mandelbrot set, the formula is : z = z²+c where z and c are compex numbers.

your code :

Code:

xtemp:= x*x - y*y + px;
y:= 2*x*y + py;
x:= xtemp;

is doing z = z²+c with
"px" -> real part of c
"py" -> imaginary part of c
"x" -> real part of z
"y" -> imaginary part of z

[David Makin]

Everything is working but I'm still left with the problem of it taking a lot longer to render when zooming in.
Now it does each pixel only once and I'm sure of it.
It does not execute more lines of code by zooming in on the fractal at all.
The only difference I see is that the numbers is uses get a log bigger.
Does computing a number like 1.203592928220659 take a long longer than just 1.2?
I've never noticed it before so I'm thinking even if larger numbers do take more time it can't make this much of a difference.

Zooming in taking longer to render is pretty unavoidable if you're zooming into areas on the boundary of the Set, in particular if the image has large areas of "inside", this is simply because more iterations are necessary on average per pixel to decide if the pixels are inside or outside.
As you say a solution is reduce the max iteration value but of course doing this results in loss of detail and the more you zoom in the greater the loss of detail will be, in fact normally one would actually want to *increase* the max iterations on higher magnifications.
One way of offsetting the speed problem that is emploiyed in many fractal programs is early detection of "inside" points where the orbit of the point concerned is tending to a fixed value (point attractor).
To do this on each iteration before calculation of the new z value, store the current value as say zold, then after calculating the new z value test the value of (z.x-zold.x)^2+(z.y-zold.y)^2 against a small threshold (smallbailout), say at largest 1e-3 and if the calculated value is less than 1e-3 then assume the point is "inside" and stop iterating. The problem with this method is if the theshold value (here 1e-3) is too large then this test in itself will introduce "errors" in the render i.e. reduce the detail level.
The thing to do to render a given view of an escape-time fractal in an optimum manner speedwise is to use a correct balance of the 3 values - the bailout value, the max iteration value and this small bailout test value (here 1e-3). Speedwise of course one should always use the minimum possible bailout value, e.g. testing z.x^2+z.y^2 against 4.0 for the z^2+c Mandelbrot (and z^2+c Julias), the optimum max iterations and smallbailout test value will depend on individual views but in general the more zoomed in you are then to avoid gross loss of detail then the larger you need to make max iterations and the smaller you need to make the small bailout test value.

For a better guide on fractal orbits see:

http://www.fractalgallery.co.uk/orbits.html

[ker2x]

Everything is working but I'm still left with the problem of it taking a lot longer to render when zooming in.
Now it does each pixel only once and I'm sure of it.
It does not execute more lines of code by zooming in on the fractal at all.
The only difference I see is that the numbers is uses get a log bigger.
Does computing a number like 1.203592928220659 take a long longer than just 1.2?
I've never noticed it before so I'm thinking even if larger numbers do take more time it can't make this much of a difference.

Zooming in taking longer to render is pretty unavoidable if you're zooming into areas on the boundary of the Set, in particular if the image has large areas of "inside", this is simply because more iterations are necessary on average per pixel to decide if the pixels are inside or outside.
As you say a solution is reduce the max iteration value but of course doing this results in loss of detail and the more you zoom in the greater the loss of detail will be, in fact normally one would actually want to *increase* the max iterations on higher magnifications.
One way of offsetting the speed problem that is emploiyed in many fractal programs is early detection of "inside" points where the orbit of the point concerned is tending to a fixed value (point attractor).
To do this on each iteration before calculation of the new z value, store the current value as say zold, then after calculating the new z value test the value of (z.x-zold.x)^2+(z.y-zold.y)^2 against a small threshold (smallbailout), say at largest 1e-3 and if the calculated value is less than 1e-3 then assume the point is "inside" and stop iterating. The problem with this method is if the theshold value (here 1e-3) is too large then this test in itself will introduce "errors" in the render i.e. reduce the detail level.
The thing to do to render a given view of an escape-time fractal in an optimum manner speedwise is to use a correct balance of the 3 values - the bailout value, the max iteration value and this small bailout test value (here 1e-3). Speedwise of course one should always use the minimum possible bailout value, e.g. testing z.x^2+z.y^2 against 4.0 for the z^2+c Mandelbrot (and z^2+c Julias), the optimum max iterations and smallbailout test value will depend on individual views but in general the more zoomed in you are then to avoid gross loss of detail then the larger you need to make max iterations and the smaller you need to make the small bailout test value.

For a better guide on fractal orbits see:

http://www.fractalgallery.co.uk/orbits.html

Mmm, it may be interesting for my openCL buddhabrot code

[David Makin]

Of course with respect to using a "smallbailout' to test for point-attractors so you have early detection of "inside", you can extend this to test for attractors of higher period - for instance period 2 attractors are almost as easy to detect as point attractors but here you need z, zold and zolder and would test the value of (z.x-zolder.x)^2+(z.y-zolder.y)^2 against a smallbailout.
There are also reasonably quick (but less efficient) algorithms to test for periodic attractors of arbitrary period.
Of course for particular Julia Sets (at least for z^p+c) then one only needs test for a specific periodic attractor in order to detect "inside" early, though obviously the period would be best known at runtime for maximum efficiency.
To state the obvious, the larger the period then the less effective testing for periodic attractors becomes.