Kalles Fraktaler
|
|
« Reply #30 on: May 19, 2013, 05:13:08 PM » |
|
mrflay, even if you did not have the time to make your code open-source, can you give us any pseudo-code or something please?
I am trying to investigate this, however it seems that I didn't get it quite right. I am still only using the arbitrary precision library.
The function is Dn= 2*X*D + D*D + CD, where CD is the offset from the pixel I am calculating using the ordinary Mandelbrot calculation (D0), X is the Mandelbrot variable, D is the delta and Dn is the next delta. The ordinary Mandelbrot calculation, where C is the location: xin = 2*(xr*xi) + ci; xrn = xr*xr - xi*xi + cr;
Before this, the new Delta-values are calculated, and cd is the difference between the X and the Y values: dnr+dni = 2*(xr+xi)*(dr+di) + (dr+Di)*(dr+di) + cdr + cdi => dnr+dni = 2*xr*dr + 2*xr*di + 2*xi*dr + 2*xi*di + dr*dr + 2*dr*di + di*di + cdr + cdi =>
This is the resulting code: dnr = 2*xr*dr + 2*xi*di + dr*dr + di*di + cdr; dni = 2*xr*di + 2*xi*dr + 2*dr*di + cdi;
So in each iteration, the above is calculated and added to the Y value, and then checked for the absolute value not exceeding 2: yr=xr+dnr; yi=xi+dni; if(yr*yr+yi*yi > 4) break;
However I only get the same value on Y as on X. The terms dr*dr and di*di get very small compared to 2*xr*dr and 2*xi*di Can you or anybody please help?
|
|
|
Logged
|
|
|
|
mrflay
|
|
« Reply #31 on: May 19, 2013, 06:14:15 PM » |
|
This is the resulting code: dnr = 2*xr*dr + 2*xi*di + dr*dr + di*di + cdr; dni = 2*xr*di + 2*xi*dr + 2*dr*di + cdi;
Did you include the minus signs from the i*i? Here's my code: // update dx temp = 2*(x*dx - xi*dxi); tempi = 2*(x*dxi + xi*dx);
temp += delta; tempi += deltai; temp += (dx*dx - dxi*dxi); tempi += 2*dx*dxi; dx = temp; dxi = tempi;
|
|
|
Logged
|
|
|
|
Kalles Fraktaler
|
|
« Reply #32 on: May 19, 2013, 06:32:52 PM » |
|
Thanks a lot!!! , yes I forgot the minus sign
|
|
|
Logged
|
|
|
|
mrflay
|
|
« Reply #33 on: May 19, 2013, 07:01:49 PM » |
|
|
|
|
Logged
|
|
|
|
blob
Strange Attractor
Posts: 272
|
|
« Reply #34 on: May 19, 2013, 08:11:01 PM » |
|
Hi, it would be nice if you could compile a standalone jar file for desktop use for those like myself who have no clue what to do to compile this code into a useable application.
Thanks.
|
|
|
Logged
|
|
|
|
mrflay
|
|
« Reply #35 on: May 21, 2013, 12:06:35 AM » |
|
Hi, it would be nice if you could compile a standalone jar file for desktop use for those like myself who have no clue what to do to compile this code into a useable application.
I might make that a project for this weekend - I think it needs some GPL information put in the about box.
|
|
|
Logged
|
|
|
|
Kalles Fraktaler
|
|
« Reply #36 on: May 23, 2013, 10:45:20 PM » |
|
I have now had some time to investigated this a little. The following two fractals are zoomed to just a little more than e100. Only the top left pixel is calculated with the standard Mandelbrot function with a arbitrary precision library. The rest of the pixels (of the 100x100 images, which are here magnified 4 times) are calculated with the SFT method with the standard double variables (the result is almost identical if I use the arbitrary precision library with the SFT method). The first fractal (random colors different for each iteration) is near the edge rel:-1 img:0 and give a really promising result, there is only a little glitch in the middle of the spines, where the iterations are vary the most: The second fractal (gradient colors) is in the "sea horse valley" (or actually on the opposite side, which I don't know the name for) and don't give any good result at all. Is SFT accurate only near rel:-1 img:0 or does your program give better results? The glitches are clearly visible even if I calculate every 3rd pixel with the Mandelbrot function. If you are able to zoom into more complex regions, what ratio of Mandelbrot and SFT pixels do you use in your program?
|
|
|
Logged
|
|
|
|
cKleinhuis
|
|
« Reply #37 on: May 24, 2013, 12:55:39 AM » |
|
regarding that your name sound like hitting head on the keyboard, thank you for those tryouts, why not choose a pixel in the middle ? and to be true, this method can not guess points deeper iterated than the original point i guess
|
|
« Last Edit: May 24, 2013, 10:33:00 AM by cKleinhuis »
|
Logged
|
---
divide and conquer - iterate and rule - chaos is No random!
|
|
|
|
Kalles Fraktaler
|
|
« Reply #39 on: May 24, 2013, 09:19:05 AM » |
|
regarding that your name sound like hitting head on the keyboard, All the names I wanted on youtube was already used so eventually I just hitted the keyboard, I am using the same name here since most of my youtube movies are fractal zooms thank you for those tryouts, why not choose a pixel in the middle ? and to be true, this method can not guess points deeped iterated than the original point i guess You may regard the images as 200x200 pixels with the Mandelbrot pixel in the middle And yes, the reference Mandelbrot pixel continues to be calculated in my test until all the SFT pixels are set, so in my opinion it should not matter if the SFT pixels are much deeper. However, you have a good point here and my opinion is wrong - if I use the deepest pixel as reference the fractal gets really good even in complex regions: So, in order to make a general Mandelbrot explorer - how can the deepest pixel in an image be chosen prior calculation? Or maybe we can just live with the errors it gets when just choose the pixel in the middle? Edit: The fractal above is zoomed to e103. Time to render the left image with the Mandelbrot function (in one thread) is 9.6s. Time to render the right image is amazingly 0.072 seconds!!! There is an improvement of 133 times!!! A e103 image rendered almost instantly!!!
|
|
« Last Edit: May 24, 2013, 09:48:59 AM by asdklfjdf »
|
Logged
|
|
|
|
cKleinhuis
|
|
« Reply #40 on: May 24, 2013, 10:09:17 AM » |
|
|
|
|
Logged
|
---
divide and conquer - iterate and rule - chaos is No random!
|
|
|
cKleinhuis
|
|
« Reply #41 on: May 24, 2013, 10:12:23 AM » |
|
Wow, nice technique! I reimplemented the maths in OpenCL to run it on GPU (or CPU if you have no GPU that supports double precision): https://gitorious.org/maximus/fractal-bits/trees/master/mandelbrot-delta-clExample output (25mins render time at 8192x8192 then downscaled): http://mathr.co.uk/misc/2013-05-23_opencl_mandelbrot_perturbation_de.pngCoordinates -1.744462934349396211092633065532440162654657162058301205300011967233679112768696718643911450570050500237635116030934362e+00 + -2.204215166614661298784067716126285236126642700430015281578297171107705673910697920586811821018057499939594440402773182e-02 i @ 4e-99 period 5308 There are some white blobs that shouldn't be there - it's not maximum iteration count being reached, but something else (inappropriate reference point for those pixels? over/underflow somewhere? mystery...) statistics about calculation time ? so, this method works well with gpu ? who is in for implementing a ultra deep mandelbrot realtime zoomer on gpu, this would be just awesome, this task is open for anyone right now and it would have massively deep and huge impact, it might become a reference example for nowadays graphics cards
|
|
|
Logged
|
---
divide and conquer - iterate and rule - chaos is No random!
|
|
|
Kalles Fraktaler
|
|
« Reply #42 on: May 24, 2013, 12:05:00 PM » |
|
the actual reference point does not need to be recalculated for every frame
Yes, I agree, an animation should only needed the center point to be calculated once! Amazing possibilities opens, not only very deep zooms but also very zooms with very high iterations will be possible! However, in order to exceed e308, which is the limit of a double, it is necessary to scale the values from the arbitrary library to double and then back again... Any suggestions anyone?
|
|
|
Logged
|
|
|
|
cbuchner1
|
|
« Reply #43 on: May 24, 2013, 01:09:55 PM » |
|
So screensavers performing a GPU based HD realtime deep zoom into a set of previously chosen deep locations should be easy to implement. Has anyone checked yet if float vs double precision makes a difference?
|
|
|
Logged
|
|
|
|
Kalles Fraktaler
|
|
« Reply #44 on: May 24, 2013, 03:15:37 PM » |
|
Has anyone checked yet if float vs double precision makes a difference?
I did not work for me with float, seems the precision is too low.
|
|
|
Logged
|
|
|
|
|