Help on first fractal maker

[kronikel]

I just learned what a fractal was yesterday and became very interested in them.
I decided to try and make my own fractal drawer.
I don't know much about them, but I think it worked (I was very surprised)
But now I am stuck.
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.
You very quickly get to the point where it takes too long to render.

Here is my code (are there any code tags I can use)

var
  Canvas: TCanvas;
  tx, ty, f: extended;

const
  Height = 2;
  Width = 2;
  Zoom = 50;



procedure ColorPoint(px, py: extended);
var
  x, y, xtemp: extended;
  Iteration, Max_iteration, Color: integer;

begin
  Max_iteration:= 200;
  x:= px;
  y:= py;
  while ((x*x + y*y <= (2*2))  and  (Iteration < Max_iteration)) do
  begin
    xtemp:= x*x - y*y + px;
    y:= 2*x*y + py;
    x:= xtemp;
    Iteration:= Iteration + 1;
  end;

  if (Iteration = Max_iteration) then
  Color:= 0 else
  Color:= HSLToColor(Iteration * 10, 100, 50);

  Canvas.Pixels[Round(px * Zoom) + (Width * Zoom), Round(py * Zoom) + (Height * Zoom)]:= Color;
end;




begin
  Canvas:= GetDebugCanvas;
  Canvas.Brush.Color:= 0;
  Canvas.Rectangle(-10, -10, 999, 999);
  tx:= -Width;
  ty:= -Height;
  f:= 0.01;
  repeat
    repeat
      tx:= tx + f;
      ColorPoint(tx, ty);
    until(tx >= Width);
    ty:= ty + f;
    tx:= -Width;
  until(ty >= Height);
  DisplayDebugImgWindow(500, 500);
end.

And I will attach a picture to make sure it is turning out right

I think I can get around the problem.
It seems like no matter how zoomed in you go there would be a way to make all renderings take the same amount of time.

[cKleinhuis]

hello, and , this is one all fractals have in common, the point is, that you are approaching the boarder ever closer, this means, you have to increase
iteration depth, and the problem with that is, that the "black" areas, which are "inside" are possessing endless iteration cycles, there exist
some optimizations to improve rendering speed, at mu ency there is a good tutorial on how to do successive refinment renderings
http://mrob.com/pub/muency/successiverefinement.html

although this method is not very good at special coloring algorithms, but plain escape time coloring is well for this method!

 

[kronikel]

Well that is no good, it took me a few minutes to render the one I showed and it is hardly zoomed in at all.
I still feel there is a way to only set the color of each pixel ONE time.
The way it is now it does decimals and will set the color of a single pixel multiple times.
For example it will calculate the color for the pixels (1.1, 2.3), (1.2, 2.3), (1.3, 2.3)
But all of those points round to (1, 2)
There has to be a way to make the points it sets look more like
(1, 2), (1, 3), (1, 4)

Edit:
I haven't gotten to the point where the "iteration cycles" are getting large.
That I can understand.
The issue I'm having is that the more I zoom the more times it will cycle through a single pixel setting its color multiple times.

[ker2x]

What is the language ? Delphi ?

if i understood your code correctly, you're doing it wrong. Well... not wrong, but it's suboptimal.
There is tons of mandelbrot sample code in every possible (and impossible) language.

i'm not sure about what you're doing with this f variable.


what i suggest is something like :

Code:

foreach pixel x,y
  (cx,cy) = convert pixel coordinate x,y in complex coordinate
  iterToExit = get the number of iteration needed to exit the mandelbrot set
  color[x,y] = convert "iterToExit" to color
end foreach

display the color array.

Here is the key parts of my C#/HLSL code to convert coordinate (and zoom, move, etc ...) :

C# code :

Code:

Vector2 pan = new Vector2(0.25f, 0.000f); // (0.25,0) is the center of the screen (in complex value)
float zoom = 3;
int iteration = 50;
float aspectRatio = (float)GraphicsDevice.Viewport.Height / (float)GraphicsDevice.Viewport.Width;

//Parameters given to the HLSL code : 
mandelbrotEffect.Parameters["Pan"].SetValue(pan);
mandelbrotEffect.Parameters["Zoom"].SetValue(zoom);
mandelbrotEffect.Parameters["Aspect"].SetValue(aspectRatio);
mandelbrotEffect.Parameters["Iterations"].SetValue(iteration);

and my hlsl code to convert pixel->complex :

Code:

float2 c = (texCoord - 0.5) * Zoom * float2(1, Aspect) - Pan; //converting pixel coordinate (texcoord) to complex coordinate.

if you can't do math operation on float2 type, here is the equivalent :

Code:

float cx = (texCoord.x - 0.5) * Zoom * Aspect - Pan.x;
float cy = (texCoord.y - 0.5) * Zoom * Aspect - Pan.y;

now you just have to change pan value to "move" up/down and left/right
and zoom ... to zoom.

hope this help.
Feel free to ask questions, we all got the same problem sooner or later

[ker2x]

It seems like no matter how zoomed in you go there would be a way to make all renderings take the same amount of time.

Yes and no ...
1) it's highly dependent of the area you're zooming in. (zone with high iteration -> slower. zone with low iteration -> faster)
2) the more you zoom, the more you should iterate. (more iteration -> slower)
3) deep zooming require high numeric precision. (higher -> slower)

[kronikel]

Assuming all iterations would be the same though, no matter how zoomed in you go it should take the same amount of time to render.
But I figured out my problem.
I fixed it by making it keep track of 2 sets of variables.
One set of points for the screen (whole numbers) and one set of points that are used to determine color (decimals)
And now it sets each pixel once because I have it cycle through the whole numbers rather than the decimal numbers.

[kronikel]

Didn't see your first post.
This is pretty much in delphi.
I use a compiler called SCAR which I believe is some custom mix of delphi and pascal.

[cKleinhuis]

hello, you need a step size for your image, with the top left corner and the lower left corner in complex coordinates, you calculate the distance ( xmin-xmax) and divide it by the pixel resolution, and the same for your y step

then you initialise your rendering loop with the topleft pixel, and increment by the step sizes for every new pixel, this way you wouldnt calculate the same pixel twice...

[kronikel]

Thanks trifox that's exactly what I changed to make it work.
Took me a while to catch it though because doing it like that required me to rewrite a lot of the code and also come up with an equation for the step using the constant "Zoom"

Something I just noticed.
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.

[David Makin]

Actually in the outer (y) loop you should convert the y pixel to the imaginary coordinate and in the inner (x) loop convert the x pixel to the real coordinate rather than using start values and delta steps for the complex value.
Delta steps is (slightly) quicker but considerably less accurate and will introduce rounding errors at lower magnifications - typically up to 100* worse than the calculation method.
I made the mistake of using delta steps for the complex values in MMFrac and that loses resolution at around magnification 1e14 whereas converting the pixel values to coordinates as described will result in reasonable accuracy to magnifications of around 1e16.

[David Makin]

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 using them, but when applied in a computer program they have to be treated as two real values with a specific method of performing the various mathematical operations on a 2D number system - hence the "x= x^2-y^2 and y = 2*x*y" for when squaring the complex number z where z = x+ i*y.

The best documentation I found on how to use complex numberrs programmatically is in the appendices of the "fractint.doc" document that used to be produced when typing "fractint -makedoc" in DOS or a command-line shell - I believe this document is now also available online in HTML format.

Other links:

http://en.wikipedia.org/wiki/Complex_number
http://mathworld.wolfram.com/ComplexNumber.html

[kronikel]

Hmm I understand what you are saying about the delta steps and also about how I am using complex numbers.
But I'm not sure how to go about not using steps.

[David Makin]

Hmm I understand what you are saying about the delta steps and also about how I am using complex numbers.
But I'm not sure how to go about not using steps.

Assuming we do mean essentially the same thing then using "delta steps" would be something like:

yimag = calculate top coord of complex number (imaginary value)
for (pixely=toppixel;pixely<btmpixel;pixely++)
    xreal = calculated left coord of complex number (real value)
    for (pixelx=leftpixel;pixelx<rightpixel;pixelx++)
        render fractal for coordinate (xreal,yimag) for pixel (pixelx,pixely)
        xreal = xreal + xrealstep
    next pixelx
    yimag = yimag + yimagstep
next pixely

Whereas the equivalent more accurate code would be:

for (pixely=toppixel;pixely<btmpixel;pixely++)
    yimag = top coord of complex number (imaginary value) + (pixely-toppixel)*yimagstep
    for (pixelx=leftpixel;pixelx<rightpixel;pixelx++)
        xreal = calculated left coord of complex number (real value) + (pixelx-leftpixel)*xrealstep
        render fractal for coordinate (xreal,yimag) for pixel (pixelx,pixely)
    next pixelx
next pixely

Note that to add rotation/zooming/translation etc. simply add appropriate transform/s of (xreal,yimag) after the calculation of xreal before rendering of the fractal for the pixel.

Edit: My mistake - obviously for zooming and translation (and even independant x/y scaling) you only need to adjust the base coord values and the step values. But as soon as you require rotation then both the pre-render x (real) and y (imag) components of the coord need adjusting in the inner loop so in that case you'd use code like this (at its simplest):

for (pixely=toppixel;pixely<btmpixel;pixely++)
    for (pixelx=leftpixel;pixelx<rightpixel;pixelx++)
        Apply affine transform to pixelx and pixely resulting in xreal and yimag
        render fractal for coordinate (xreal,yimag) for pixel (pixelx,pixely)
    next pixelx
next pixely

Said affine transform would normally consist of rotation/scaling and translation but could also include skewing and other possibilities.

[kronikel]

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.

I have a new problem though.
To scale this the way I would like to I need to figure out this-
Input - Output
1          2
2          1
3          .5
4          .25
5          .125

Each output is half of the last one
But what to do to the input to get the output?
This code gives correct output but but will only work on whole numbers.
But the input could be anything, such as 2.34029

Code:

Output:= 2;
for c:= 2 to Input do
Output:= Output / 2.0;

[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.

I have a new problem though.
To scale this the way I would like to I need to figure out this-
Input - Output
1          2
2          1
3          .5
4          .25
5          .125

Each output is half of the last one
But what to do to the input to get the output?
This code gives correct output but but will only work on whole numbers.
But the input could be anything, such as 2.34029

Code:

Output:= 2;
for c:= 2 to Input do
Output:= Output / 2.0;

scale = 2^(2-n)

n scale
1   2
2   1
3   0.5
etc.

Here's a slightly related fractal link...

http://www.fractalgallery.co.uk/cantor-set.html