Welcome to Fractal Forums

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/watch?v=Zsgf6m3g5oc

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.

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!

simon.snake, I am sorry but it is your location. I hope you don't mind...

A long zoom sequence indeed !!    :)
 

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

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.

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.

Not at all. Most enjoyable zoom movie.

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.

Thanks, yes it is a beautiful path both before and after the pictures you created.

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