Kalles Fraktaler
|
|
« Reply #15 on: June 14, 2013, 03:43:44 PM » |
|
The frames were rendered at 800×500 and upscaled to 1600×1000 because youtube gives better bitrate for higher resolution.
But you could easily surpass this with your program that uses the SuperFractalThing rendering method.
OK, challenge accepted I have started an e2000 rendering now, we'll see when it is done, it is running on my old 32-bit dualcore laptop, with 640x360 frames (no pixel stretching as Fractal extreme When my move is done and published on youtube, I will make my program available (don't want you guys with super-hardware to precede me though ). Some features of my program: - Free of charges - we are enthusiasts aren't we!? - Unlimited pertubation SFT rendering (I finally managed to go beyond the e616 limit of double)!! (ok, e10'000 is the limit, however that can be extended) - Lossless animations - Automatic find of Minibrot - Just select an interesting path half the depth that you want your animation, choose the option "Find Minibrot" and sit back and watch! Sounds interesting??
|
|
« Last Edit: June 14, 2013, 03:47:02 PM by asdklfjdf »
|
Logged
|
|
|
|
Dinkydau
|
|
« Reply #16 on: June 14, 2013, 09:43:51 PM » |
|
That sounds very interesting, asdklfjdf!
Let's see how long it takes for someone to render a zoom to e10000.
|
|
|
Logged
|
|
|
|
grobblewobble
|
|
« Reply #17 on: June 17, 2013, 09:26:52 AM » |
|
What software did you use for this zoom? I heard there are some new improved algorithms?
edit: ok next time I should first read the thread before posting lol
asdklfjdf, what language are you writing your program in? Man this is so exciting, great news about that super fractal thing invention.
|
|
« Last Edit: June 17, 2013, 09:32:03 AM by grobblewobble »
|
Logged
|
|
|
|
rollercoaster158
|
|
« Reply #18 on: June 19, 2013, 08:02:42 PM » |
|
OK, challenge accepted I have started an e2000 rendering now, we'll see when it is done, it is running on my old 32-bit dualcore laptop, with 640x360 frames (no pixel stretching as Fractal extreme When my move is done and published on youtube, I will make my program available (don't want you guys with super-hardware to precede me though ). Some features of my program: - Free of charges - we are enthusiasts aren't we!? - Unlimited pertubation SFT rendering (I finally managed to go beyond the e616 limit of double)!! (ok, e10'000 is the limit, however that can be extended) - Lossless animations - Automatic find of Minibrot - Just select an interesting path half the depth that you want your animation, choose the option "Find Minibrot" and sit back and watch! Sounds interesting?? Why stop at E10000? So far my experiences with SFT have demonstrated that perturbation will speedily render just about anything that isn't too complex reguardless of depth or iteration count. While it may take weeks to render images of extremely complex deep minibrots, we could have very short rendering times of beautiful stacked shapes. Even if they go all the way down to E20000. Heck, get rid of the limit all together.
|
|
|
Logged
|
|
|
|
Dinkydau
|
|
« Reply #19 on: June 19, 2013, 10:32:54 PM » |
|
Are you aware how deep e10000 is? You will probably have RSI before you get there if you zoom non-stop. Of course no limit is always better, but extending the limit requires extra programming work if I'm not mistaken.
|
|
|
Logged
|
|
|
|
rollercoaster158
|
|
« Reply #20 on: June 20, 2013, 04:57:31 AM » |
|
Are you aware how deep e10000 is? You will probably have RSI before you get there if you zoom non-stop. Of course no limit is always better, but extending the limit requires extra programming work if I'm not mistaken.
I remember from reading the SuperFractalThing threads that there were some issues with double precision past E308 and arbitrary precision past E616, but asdklfjdf says that he has managed to solve the problem and get arbitrary precision to work. He said that the limit is E10000, but I don't think that the precision stopped working at such a round number. I guess we'll wait until asdklfjdf gets back to this thread.
|
|
|
Logged
|
|
|
|
Kalles Fraktaler
|
|
« Reply #21 on: June 20, 2013, 10:10:24 AM » |
|
asdklfjdf, what language are you writing your program in?
C++ Why stop at E10000? So far my experiences with SFT have demonstrated that perturbation will speedily render just about anything that isn't too complex reguardless of depth or iteration count. While it may take weeks to render images of extremely complex deep minibrots, we could have very short rendering times of beautiful stacked shapes. Even if they go all the way down to E20000. Heck, get rid of the limit all together.
The rendering with SFT is actually very dependent of the iteration count, and the depth also still affects, since it takes time to calculate the reference point which still requires arbitrary precision. The time processing arbitrary precision arithmetic grows exponentially, and above E2000 the calculation of the reference point takes more than half the time to render the whole image. For an animation, the reference point can be reused and then it only affects the first frame. However, a zoom to E2000 requires some 40000 frames if you don't want it to be too fast and just flickering, so it takes time...
|
|
« Last Edit: June 20, 2013, 10:21:54 AM by asdklfjdf »
|
Logged
|
|
|
|
Kalles Fraktaler
|
|
« Reply #22 on: June 20, 2013, 10:27:14 AM » |
|
I remember from reading the SuperFractalThing threads that there were some issues with double precision past E308 and arbitrary precision past E616, but asdklfjdf says that he has managed to solve the problem and get arbitrary precision to work. He said that the limit is E10000, but I don't think that the precision stopped working at such a round number. I guess we'll wait until asdklfjdf gets back to this thread.
No, the limit E10000 of my program is the limit of the arbitrary precision library, that is still used for the reference point. That is just a defined number specifying the size of the array of integers, so it can be extended to a much larger number. If Dinkydau and others with super hardware wants to use my program, which I hope, and wants to go even deeper, I can just change the number and compile again
|
|
|
Logged
|
|
|
|
grobblewobble
|
|
« Reply #23 on: June 20, 2013, 02:43:46 PM » |
|
However, a zoom to E2000 requires some 40000 frames if you don't want it to be too fast and just flickering, so it takes time...
Wait, are you saying you are calculating each frame? I thought that zoom movies are made by calculating only a subset (every doubling in size or something like that) and calculating the rest of the frames by intrapolation?
|
|
|
Logged
|
|
|
|
Kalles Fraktaler
|
|
« Reply #24 on: June 20, 2013, 03:26:57 PM » |
|
Wait, are you saying you are calculating each frame? I thought that zoom movies are made by calculating only a subset (every doubling in size or something like that) and calculating the rest of the frames by intrapolation?
No, I don't calculate every frame completely, but that is the number of frames in the movie. These frames can be created from every doubled size, as Fractal Extreme does, which still requires many calculated frames, log(1e2000)/log(2)=6644. However I create my moves as a backward zoom-out, for each frame I only calculate the new revealed pixels at the edge and squeeze the previous frame into the middle. By doing so the center of the images get smooth without use of anti-alias. Edit: Also, by doing so no pixels are stretched. However the edges of the movies does not eliminate interference patterns, which is visible when getting close to a minibrot - but not too close since then it just shows random noise.
|
|
« Last Edit: June 20, 2013, 04:29:54 PM by asdklfjdf »
|
Logged
|
|
|
|
Dinkydau
|
|
« Reply #25 on: June 20, 2013, 05:25:42 PM » |
|
That method of zoom rendering sounds like a very good idea, anti-aliasing where you most need it without any extra render time. No, the limit E10000 of my program is the limit of the arbitrary precision library, that is still used for the reference point. That is just a defined number specifying the size of the array of integers, so it can be extended to a much larger number. If Dinkydau and others with super hardware wants to use my program, which I hope, and wants to go even deeper, I can just change the number and compile again Assuming no technical limit of extending that way, why don't you make it something like e500 000 000? That should be "practically unlimited".
|
|
|
Logged
|
|
|
|
rollercoaster158
|
|
« Reply #26 on: June 20, 2013, 06:39:22 PM » |
|
No, the limit E10000 of my program is the limit of the arbitrary precision library, that is still used for the reference point. That is just a defined number specifying the size of the array of integers, so it can be extended to a much larger number. If Dinkydau and others with super hardware wants to use my program, which I hope, and wants to go even deeper, I can just change the number and compile again How about you add a parameter in the program that allows the user to set the size of the array of integers, and just pass that value to the arbitrary precision library? That way we aren't using giant E100000 integer arrays for more shallow zooms, but can set it back up to E100000 if we plan to zoom that far. (I wish you luck if you plan to navigate all the way down there.)
|
|
|
Logged
|
|
|
|
Kalles Fraktaler
|
|
« Reply #27 on: June 20, 2013, 09:55:29 PM » |
|
My arbitrary precision library has the integer array in a fixed size. The array is on the stack, which makes the code much faster than if it would be allocated on the heap for all variables. There exist other libraries that are capable of billions of decimals, apfloat for example that is used to calculate pi decimals, but the calculation of the reference point would take very much longer time, even for shallow depths. And of course a library that can be used for fractals needs to be able to control the precision and not use more decimals than necessary for each depth.
|
|
|
Logged
|
|
|
|
rollercoaster158
|
|
« Reply #28 on: June 20, 2013, 10:45:05 PM » |
|
And of course a library that can be used for fractals needs to be able to control the precision and not use more decimals than necessary for each depth.
That was my point, that we don't need huge arrays for calculation of shallower zooms. I see that you have already thought of that. Best of luck on your E2000 dive!
|
|
|
Logged
|
|
|
|
|