Kalles Fraktaler
|
|
« on: September 01, 2013, 01:09:48 PM » |
|
This move was created from 822 key-frames, rendered with 960x540 in 10 hours. 85 of these frames needed to be manually corrected from blob glitches since this path passes close to several minibrots. Last frame rendered in 4000x2250 for the smooth display of the last minibrot
http://www.youtube.com/v/Zsgf6m3g5oc&rel=1&fs=1&hd=1
|
|
|
Logged
|
|
|
|
simon.snake
Fractal Bachius
Posts: 640
Experienced Fractal eXtreme plugin crasher!
|
|
« Reply #1 on: September 01, 2013, 02:13:39 PM » |
|
Nice.
Shows me what I could achieve with my Sculptured series of images (I did notice it was incredibly similar) if I keep at it.
Unfortunately, even though I've played with a couple of the SFT programs that have been written, I felt that if Bruce Dawson of Cygnus Software could incorporate the SFT rendering into Fractal eXtreme it would give all the friendly parts of the user interface with faster rendering and would be the best of both worlds.
For example, it would be good if you could still zoom in with the mouse wheel, and it would be nice if you could save and load colour palettes. Unfortunately, both programs (maybe they were early versions) could do neither of these important functions.
|
|
|
Logged
|
To anyone viewing my posts and finding missing/broken links to a website called www.needanother.co.uk, I still own the domain but recently cancelled my server (saving £30/month) so even though the domain address exists, it points nowhere. I hope to one day sort something out but for now - sorry!
|
|
|
Dinkydau
|
|
« Reply #2 on: September 01, 2013, 02:23:25 PM » |
|
Nice soft colors
Indeed the mouse wheel zooming and color options are very important, but also the efficiency. With SFT programs, the render time is influenced significantly by how fast the reference point is calculated. Bruce Dawson has improved his full precision calculation method over years and it's as efficient as it gets. That alone would make SFT render a lot faster!
|
|
|
Logged
|
|
|
|
Kalles Fraktaler
|
|
« Reply #3 on: September 01, 2013, 11:21:54 PM » |
|
simon.snake, I am sorry but it is your location. I hope you don't mind...
|
|
|
Logged
|
|
|
|
Nahee_Enterprises
|
|
« Reply #4 on: September 02, 2013, 03:07:23 AM » |
|
A long zoom sequence indeed !!
|
|
|
Logged
|
|
|
|
Kalles Fraktaler
|
|
« Reply #5 on: September 02, 2013, 09:21:04 AM » |
|
Nice soft colors
Indeed the mouse wheel zooming and color options are very important, but also the efficiency. With SFT programs, the render time is influenced significantly by how fast the reference point is calculated. Bruce Dawson has improved his full precision calculation method over years and it's as efficient as it gets. That alone would make SFT render a lot faster!
The ultimate optimization is to expand all for-loops. I've tried that in my previous non-sft version of my program and the size got 15mb with limit of e1600 (which could be reduced with fewer precision steps). The size increase exponentially so I cannot imagine the size of a program with limit of e20000 doing full precision as efficient as it gets, I don't think it would be reasonable. Fx has it's limit for a reason...
|
|
|
Logged
|
|
|
|
Dinkydau
|
|
« Reply #6 on: September 02, 2013, 06:10:35 PM » |
|
If a 15 MB program can go to e1600 with the full precision speed of fractal extreme combined with the SFT method, I think that's reasonable. E1600 is very very deep. Yesterday I was zooming with your program in an interesting area at a depth of e230 with over 1 200 000 iterations per pixel. The reference points took 10 seconds to calculate, while at that location fractal extreme calculates points at 0,14 seconds per point. Even with that difference, your program is easier to explore with because of the immense speed-up when finally the reference point is calculated, however, e1600 at this location is out of reach. For locations with many iterations it would help a lot to have better full precision speed, even it it comes with a limit like e1600, which really is deep already. I think you can only go to depths like e20000 if you stay on the real axis anyway, like you did in your (last) record deepest zoom.
|
|
« Last Edit: September 02, 2013, 06:13:18 PM by Dinkydau, Reason: more about how deep e1600 is »
|
Logged
|
|
|
|
Kalles Fraktaler
|
|
« Reply #7 on: September 02, 2013, 07:08:00 PM » |
|
It is possible to combine the full precision calculation of several pixels since for example the first 100 digits are the same for an image at e102 or something like that. But indeed, I believe fx's full precision calculation is much faster than mine, but I don't think the difference is that big.
|
|
|
Logged
|
|
|
|
simon.snake
Fractal Bachius
Posts: 640
Experienced Fractal eXtreme plugin crasher!
|
|
« Reply #8 on: September 02, 2013, 07:32:28 PM » |
|
simon.snake, I am sorry but it is your location. I hope you don't mind...
Not at all. Most enjoyable zoom movie.
|
|
|
Logged
|
To anyone viewing my posts and finding missing/broken links to a website called www.needanother.co.uk, I still own the domain but recently cancelled my server (saving £30/month) so even though the domain address exists, it points nowhere. I hope to one day sort something out but for now - sorry!
|
|
|
Dinkydau
|
|
« Reply #9 on: September 02, 2013, 10:29:18 PM » |
|
It is possible to combine the full precision calculation of several pixels since for example the first 100 digits are the same for an image at e102 or something like that. But indeed, I believe fx's full precision calculation is much faster than mine, but I don't think the difference is that big.
Okay, I measured how long it took for the first pixel to appear in fractal extreme: 1,8 seconds. It's not as big a difference as I thought it was.
|
|
|
Logged
|
|
|
|
Kalles Fraktaler
|
|
« Reply #10 on: September 02, 2013, 11:27:08 PM » |
|
Not at all. Most enjoyable zoom movie.
Thanks, yes it is a beautiful path both before and after the pictures you created. Okay, I measured how long it took for the first pixel to appear in fractal extreme: 1,8 seconds. It's not as big a difference as I thought it was.
...beside for-loop expansions there are also for each iteration conversions to doubles, that are stored in a the list to be used by the pertubation calculations. My big concern currently is instead how to get rid of the blobs. The current version use up to 8 reference points but I am investigating using more references and also trying to improve how to find the blobs. I think the blobs can probably not be fully identified by other means than analyzing the visible structure of the image and not being able to avoid adding unnecessary references in areas that do have the same number of iterations.
|
|
« Last Edit: September 02, 2013, 11:46:10 PM by Kalles Fraktaler »
|
Logged
|
|
|
|
|