From: "Jay Hill"<jrhill@nosc.mil>
To: fractint@mail.xmission.com
Message-ID: <88256555.0082681C.00@NOTESGW.NOSC.MIL>
Date: Thu, 20 Nov 1997 16:51:05 -0800
Subject: Re: (fractint) Deep Zooming
Mime-Version: 1.0
Sender: owner-fractint@xmission.com
Precedence: bulk
Reply-To: fractint@mail.xmission.com
Content-Type: text/plain; charset=US-ASCII


Peter wrote:

>After 8 hours (my workday) of zooming an image centered at the Feigenbaum
>point at x10^14 with maxiter=2^31, using floating point and guessing
>(screen mode 320 x 200 x 256), the computer generated a row at the top and
>bottom of my screen of about 20 chunky, spaced pixels. It was still
>chugging away, but I estimate it would have taken a few months to finish
>the image.

Is this a high speed Pentium?  Never mind :-)  You are working, as I
said earlier, one of the most difficult parts of the MSet.  Fractint 20.0
will
(we hope) have some new methods like synchronous orbits working
which will greatly improve performance on this image.  Since you are
making a zoom movie, you might start back out a unit magnification
and work your way in while we wait for version 20.

>Does anyone have any tips on optimizing Fractint deep zooming.
Here are some ideas.

1)  The synchronous orbit method is an interpolation method.  In a
zoom movie most of the image has changed position only slightly.
So a history of the synchronous orbit calculation of one step could
be used for launching the trajectories of the next well into their
iterations. This would work especially well if the corners of the
synchronous orbits were not tied to the image coordinate grid
unit very late (when the synchronous orbit box is only a few pixels
on a side).  There have been similar ideas mentioned before,
but with points tied to the grid.  I'm suggesting a synchronous orbit
space (S.O.S., a tree like data structure) which can be pruned as
needed. Each image is displayed using the SOS which finishes at
the pixel level where we switch to the image space.  We should
be able to save the SOS so that work can continue at another
time or on another machine (a faster one as available, I hear
450 MHz Pentiums will be out in a year).

2) Peter is interested in images focusing on the Feigenbaum point,
the limit point at the end of a sequence of ever smaller buds.  So
a lot of his image will be in the buds and taking much computation.
Also the synchronous orbit method does not work well near MSet
components, not to mention inside one (ref. Robert Munafo). In
fact, in Peter's case, we can calculate the fraction of the screen 'in'
these components. The Feigenbaum constant is about
F=4.66920160910299. This is the ratio of succesive bud sizes.
The half angle of the wedge containing the bud sequence
is arcsin((F-1)/(F+1)).  The area (if my Post-It were only
a little bigger) is A=(F-1)/(F+1)*(W/2)^2= 0.161804159655
where W is the screen width.  The screen area is .75*W^2  so
the fraction is  0.21573887954.  I published methods for working
with these components in Fractal Horizons : The Future Use of
Fractals, (Cliff Pickover), editor (St. Martin's Press, 1996). A rapid
calculation can bound these buds and then flood fill finishes
them off.  The bud population in successive frames changes
slowly, dropping off some and adding others. Their constants
can be stored in another data structure, COS (Component Orbit
Space). That saves about 1/6 of the time in Peter's movie.

>Or is this a sign that my hardware cannot hack it? Any info would be
>appreciated, as my computer would like something to do when I am
>at work during the day. Thanks, Peter.

It looks like you have put your computer in for 20 years hard labor.  :-)

Jay



-
------------------------------------------------------------
Thanks for using Fractint, The Fractals and Fractint Discussion List
Post Message:   fractint@xmission.com
Get Commands:   majordomo@xmission.com "help"
Administrator:  twegner@phoenix.net
Unsubscribe:    majordomo@xmission.com "unsubscribe fractint"