mrflay
|
|
« Reply #60 on: May 27, 2013, 11:42:37 PM » |
|
In the applet it says the exeption occures for the string "1 024" (with a space). I tried with firefox and chrome always with the same error. I've also tried to change the number format in the configuration panel but no success. :-/
It looks like this might be a localisation issue. The number should be 1,024 but the comma has gone wrong. I think someone else had issues with this. I tried switching my computer to use commas and periods round the other way, but it didn't seem to reproduce the problem.
|
|
|
Logged
|
|
|
|
Kalles Fraktaler
|
|
« Reply #61 on: May 28, 2013, 12:28:43 AM » |
|
Mrflay, can you please tell in which code file, or function or variable name, you are scailing in order be able to zoom beyond e308? You wrote previously that you were able to zoom to e400, but I don't yet understand how... Edit: I think I solved my problem: my arbitrary precision library is optimized for fractal math and has a limit on big values, so instead of multiplying delta with a big value I have to "remove zeroes". However the e616 limit remains... But I will still be very happy to be able to create a 30 min HD movie to e600 on an interesting spot that requires a high number of iterations within days, instead of within years
|
|
« Last Edit: May 28, 2013, 11:45:43 AM by asdklfjdf »
|
Logged
|
|
|
|
mrflay
|
|
« Reply #62 on: May 28, 2013, 10:21:34 PM » |
|
Mrflay, can you please tell in which code file, or function or variable name, you are scailing in order be able to zoom beyond e308? You wrote previously that you were able to zoom to e400, but I don't yet understand how...
The scaling is done in the function FillInCubic. The size is specified by aActual_width*10^aSize_extra_exponent. In the test for "Is the ABC approximation accurate enough", it uses the extra exponent to scale the ABC values. Btw I have found a bug in SFT when saving an image beyond 1e308. The size is saved out as zero. However the coordinates are ok, so the save file can be 'fixed' by editing the text file and setting the size to something sensible. I should have a fix fairly soon.
|
|
|
Logged
|
|
|
|
|
Kalles Fraktaler
|
|
« Reply #64 on: May 29, 2013, 01:07:28 PM » |
|
My first SFT movie, rendered within one day I guess this movie would have taken at least a month to render in my old program, or in Fractal extreme. Above 1e4 0,0i is used as reference, with all X(n)=0. Below 1e4 only one reference point is used for all the frames in the whole movie, that's in the point in the middle of the last frame, which is somewhere inside the minibrot at the end. There is a little glitch at e105 where the zoom after a long path of centering turns to the side. I guess that in those frames the deepest point, reachable from a double, is not the end minibrot, at e255. This glitch is repeated at e180, e218 and e237. There is also a few strange "stains" in the large "empty" areas outside the spirals. I don't know where they come from, they are really stains in the middle of nothing and not something miscalculated in the edge of the frames. Anyway, if I hadn't tell you you wouldn't have noticed
|
|
|
Logged
|
|
|
|
cbuchner1
|
|
« Reply #65 on: May 29, 2013, 02:25:35 PM » |
|
How many individual frames did you render for this animation?
Could this be sped up further by rendering less frames at a somewhat higher resolution (or with predistortion optimized for zooming in), and interpolating any zooming or rotation that occurs inbetween?
|
|
|
Logged
|
|
|
|
cKleinhuis
|
|
« Reply #66 on: May 29, 2013, 03:18:10 PM » |
|
awesome zoom, is that 720p the resolution you rendered it ?
|
|
|
Logged
|
---
divide and conquer - iterate and rule - chaos is No random!
|
|
|
Alef
|
|
« Reply #67 on: May 29, 2013, 03:59:35 PM » |
|
My first SFT movie, rendered within one day I guess this movie would have taken at least a month to render in my old program, or in Fractal extreme. Above 1e4 0,0i is used as reference, with all X(n)=0. Below 1e4 only one reference point is used for all the frames in the whole movie, that's in the point in the middle of the last frame, which is somewhere inside the minibrot at the end. There is a little glitch at e105 where the zoom after a long path of centering turns to the side. I guess that in those frames the deepest point, reachable from a double, is not the end minibrot, at e255. This glitch is repeated at e180, e218 and e237. There is also a few strange "stains" in the large "empty" areas outside the spirals. I don't know where they come from, they are really stains in the middle of nothing and not something miscalculated in the edge of the frames. Anyway, if I hadn't tell you you wouldn't have noticed Could you do 5 minits compo style movie? Colours here are nicer than violet contest zoom.
|
|
« Last Edit: May 29, 2013, 04:02:18 PM by Alef »
|
Logged
|
fractal catalisator
|
|
|
Kalles Fraktaler
|
|
« Reply #68 on: May 29, 2013, 04:38:53 PM » |
|
How many individual frames did you render for this animation?
Could this be sped up further by rendering less frames at a somewhat higher resolution (or with predistortion optimized for zooming in), and interpolating any zooming or rotation that occurs inbetween?
I create a zoom-out sequence of images, each frame only render the new revealed pixels (like a frame) and squeezes the previous image, 10000 frame images in total. This also make the center of the movie smooth without using anti-aliasing and such. Then I assemble the images backwards to create a zoom-in movie. By doing so my old program rendered movies in about the same time as FX, although FX is faster than my program. awesome zoom, is that 720p the resolution you rendered it ?
The original frame images are 640x360 Could you do 5 minits compo style movie? Colours here are nicer than violet contest zoom.
My competition movie has my "metal-style" effect, which I hope is unique?
|
|
|
Logged
|
|
|
|
knighty
Fractal Iambus
Posts: 819
|
|
« Reply #69 on: May 29, 2013, 05:27:04 PM » |
|
It looks like this might be a localisation issue. The number should be 1,024 but the comma has gone wrong. I think someone else had issues with this. I tried switching my computer to use commas and periods round the other way, but it didn't seem to reproduce the problem.
I also tried that. Is it possible to make it filter for spaces as it does with commas? asdklfjdf: Nice video!
|
|
|
Logged
|
|
|
|
claude
Fractal Bachius
Posts: 563
|
|
« Reply #70 on: May 30, 2013, 12:08:16 AM » |
|
statistics about calculation time ? so, this method works well with gpu ? Using a CPU-based OpenCL runtime, my current implementation takes 15mins to render the whole SFT Library at 512x512 with only a few failures: http://mathr.co.uk/mandelbrot/2013-05-29_sft_library/This is using a plain iteration for each pixel using double precision (no cubic approximation, no recursive subdivision) and a similar one for difference in the derivative (for distance estimate colouring). Unfortunately some changes in the code stop it working on my GPU-based OpenCL runtime (too many kernel arguments), and when it did work it tended to peg Xorg and make interactively using the computer impossible until it finished. I looked briefly at the SFT source code (but not been able to compile it due to missing jnlp.jar or similar) and saw some "parent" fields in some objects. Am I correct in thinking it has a tree of points, with each level being created using a cubic approximation from the parent? That kind of algorithm might be harder to implement efficiently for GPU.
|
|
|
Logged
|
|
|
|
cKleinhuis
|
|
« Reply #71 on: May 30, 2013, 01:15:41 AM » |
|
dudes, congratulations all, i award this as nobel prize candidate for 2013!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1
|
|
|
Logged
|
---
divide and conquer - iterate and rule - chaos is No random!
|
|
|
Pharmagician
|
|
« Reply #72 on: May 30, 2013, 02:00:50 AM » |
|
Wow! Wonderful!
|
|
|
Logged
|
|
|
|
hgjf2
|
|
« Reply #73 on: May 30, 2013, 09:37:24 AM » |
|
Also a JAVA applet with explore MANDELBROT set with high precision with deep zooming it can finding at site http://math.hws.edu/xJava/MB/The JAVA applet can zoom to over 1E+300, same as in your movie posted, but for explorer deeping in zoom need more time because if you zoom deeper than 1E+15, image render slower, but zooming at 1E+300 image render more slow because calculate with other algorithm what generate all digit for the big numbers value. JAVA - fractal extreme emulator EH!
|
|
|
Logged
|
|
|
|
Kalles Fraktaler
|
|
« Reply #74 on: May 30, 2013, 12:39:53 PM » |
|
Also a JAVA applet with explore MANDELBROT set with high precision with deep zooming it can finding at site http://math.hws.edu/xJava/MB/The JAVA applet can zoom to over 1E+300, same as in your movie posted, but for explorer deeping in zoom need more time because if you zoom deeper than 1E+15, image render slower, but zooming at 1E+300 image render more slow because calculate with other algorithm what generate all digit for the big numbers value. JAVA - fractal extreme emulator EH! If you would include the SFT algorithm in your java app, it would be many times faster than all other Fractal programs to at least e400, perhaps e600! The really cool thing with SFT is that it is not so dependent of the speed of the arbitrary precision library, since it is only used for the reference point, and since double is probably as fast in Java as in C/C++/Assembler the programming language is not so important either. One could make a really decent Mandelbrot e400 explorer also in 32-bit Windows, or as a mobile-app, or anything! Oh I wish I knew about SFT 20 years ago, I would have been able to do magic in 16-bit Windows 3.11!!!
|
|
|
Logged
|
|
|
|
|