And I mean *really* deep:
http://www.youtube.com/watch?v=foxD6ZQlnlU

  Years ago I asked here the question: "If you zoom enough into the
Mandelbrot set, will you finally find the Truth?"

  If you watch that fullscreen from start to finish, with sounds on,
maybe you will.

-- 
                                                          - Warp

Post a reply to this message

On 31/10/2010 1:31 PM, Warp wrote:
>    And I mean *really* deep:
> http://www.youtube.com/watch?v=foxD6ZQlnlU
>
>    Years ago I asked here the question: "If you zoom enough into the
> Mandelbrot set, will you finally find the Truth?"
>
>    If you watch that fullscreen from start to finish, with sounds on,
> maybe you will.
>

That is deep!

I can't say I appreciate or like the music.

Thanks for posting, I like the 3D version. :-D

-- 

Best Regards,
	Stephen

Post a reply to this message

Stephen <mca### [at] aoldotcom> wrote:
> I can't say I appreciate or like the music.

  It's not a question of liking it. It's a question of feeling it.

-- 
                                                          - Warp

Post a reply to this message

On 31/10/2010 8:14 PM, Warp wrote:
> Stephen<mca### [at] aoldotcom>  wrote:
>> I can't say I appreciate or like the music.
>
>    It's not a question of liking it. It's a question of feeling it.
>

That's as deep as the zoom ;-)

-- 

Best Regards,
	Stephen

Post a reply to this message

Warp wrote:
>   Years ago I asked here the question: "If you zoom enough into the
> Mandelbrot set, will you finally find the Truth?"

Very cool. Altho I'm not quite sure what his comment about the speed of 
light is supposed to mean. :-)

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

I find it interesting that at the beginning of the movie, it zooms into 
largely repetitive areas of the fractal (fringe areas where very similar 
features are repeated over and over next to each other), and then for 
the last two thirds, it zooms into one specific point of interest. 
During the second part, you can see wheels with spokes, and the number 
of spokes increases, slowly at first and then very quickly until the end 
(which I won't "spoil" for those who haven't watched it). It's as though 
bypassing all the repetitions in the first part is "winding up" 
complexity that has to be "unwound" by zooming very deep into the 
concentric circles in the second part. There's probably a mathematical 
explanation for this.

  - Slime

Post a reply to this message

On 31/10/2010 01:31 PM, Warp wrote:
>    And I mean *really* deep:
> http://www.youtube.com/watch?v=foxD6ZQlnlU

That is really, really deep. Everything a look at now appear to be 
receding away from me.

It's also very pink. I don't know what this was rendered with, but it 
seems to have a 256-colour limit, meaning that the colours repeat a hell 
of a lot. I did a zoom not unlike this using POV-Ray. Obviously the AA 
is all over the place, but it does mean I have unlimited colours, and I 
can map them as I see fit.

The location chosen is very, *very* repetitive. I mean, really, if you 
watch the first minute or two of the video, you've now seen everything 
there is to see for the entire 10 minute marathon.

Ditto for the music, actually. It's just a drum beat with some 
occasional accompaniment. I like trance music, but this is the kind of 
thing I'd routinely skip over. There's just too much drum and not enough 
notes. I also find it kind of interesting that I'm gazing at pristine 
mathematical perfection while listening to distorted gurgling electronic 
grunge.

Of course, what I'd really like to do some day is do a long fractal zoom 
(or more likely a succession of them), and spend time tweaking all the 
colours to the exact details of the fractal, and build some sort of 
soundscape that complements each feature of it. Sadly, I am drastically 
incapable of synthesizing such a transcendental fusion...

Post a reply to this message

Le 2010-11-01 07:46, Invisible a écrit :
> On 31/10/2010 01:31 PM, Warp wrote:
>> And I mean *really* deep:
>> http://www.youtube.com/watch?v=foxD6ZQlnlU
>
> That is really, really deep. Everything a look at now appear to be
> receding away from me.
>
> It's also very pink. I don't know what this was rendered with, but it
> seems to have a 256-colour limit,

That's what I thought too.  It reminded me of the old FractInt, which, 
by default, saved to .GIF so it was limited to 256 colors as well.

*Googles*

Holy crap!  FractInt is still maintained!  There goes today's hope of 
doing actual work.

-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

On 01/11/2010 12:31 PM, Francois Labreque wrote:

> Holy crap! FractInt is still maintained! There goes today's hope of
> doing actual work.

What, you didn't know that? ;-)

I used FractInt to produce all my stuff on Zazzle. Still, I keep meaning 
to put together a "real" fractal renderer one of these days. One that 
can handle 48 megapixel images without having to render them as 
two-dozen GIF images rendered in a framebuffer that has to fit inside 
"conventional memory" (!!) and then stitching them together into a giant 
50MB GIF file. It's really slow...

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> It's also very pink. I don't know what this was rendered with, but it 
> seems to have a 256-colour limit, meaning that the colours repeat a hell 
> of a lot. I did a zoom not unlike this using POV-Ray. Obviously the AA 
> is all over the place, but it does mean I have unlimited colours, and I 
> can map them as I see fit.

  Naturally POV-Ray won't cut it for such a deep zoom because it will
start glitching out at about 2^50 zoom factor (because 'double' only
has 53 mantissa bits). You need a software with multiple-precision
floating point numbers (or such a library, if you want to write the
program yourself). Of course rendering such deep zooms with such a
library will be slooooow (because software floating point is very slow,
and the amount of iterations required for such zoom levels doesn't help
the matter either).

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> and the amount of iterations required for such zoom levels doesn't help
> the matter either).

I wouldn't think it takes more iterations per pixel to do a deep zoom than 
to do a surface zoom. (Of course, if you have the whole set in view, sure. I 
mean when you're at 2^30 zoom, does it really take fewer iterations per 
pixel than 2^70 zoom?)


-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

On 1-11-2010 3:36, Slime wrote:
> I find it interesting that at the beginning of the movie, it zooms into
> largely repetitive areas of the fractal (fringe areas where very similar
> features are repeated over and over next to each other), and then for
> the last two thirds, it zooms into one specific point of interest.
> During the second part, you can see wheels with spokes, and the number
> of spokes increases, slowly at first and then very quickly until the end

The number of spokes jumps up and down most of the time. I tried to 
guess how many there would be in the next generation to keep it a bit 
interesting for me.

> (which I won't "spoil" for those who haven't watched it).

Let me spoil it for them ;) If you look at the first few minutes, you 
know what the last shot will be.

>  It's as though
> bypassing all the repetitions in the first part is "winding up"
> complexity that has to be "unwound" by zooming very deep into the
> concentric circles in the second part. There's probably a mathematical
> explanation for this.

I think most of it has a more easy artistic explanation. And possibly 
also some technical explanation. It might be that this point that they 
wanted to find at the end is more easy to find here. How much time would 
they have spent in setting up this shot?

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > and the amount of iterations required for such zoom levels doesn't help
> > the matter either).

> I wouldn't think it takes more iterations per pixel to do a deep zoom than 
> to do a surface zoom.

  It does. Each color band in the classically-colored Mandebrot set (which
is what is used in the video) represents one iteration. Now count how many
distinct color bands there are in the entire video (I have no idea, but
I'm guessing it's in the millions).

> (Of course, if you have the whole set in view, sure. I 
> mean when you're at 2^30 zoom, does it really take fewer iterations per 
> pixel than 2^70 zoom?)

  It's more like you don't *need* so many iterations for a 2^30 zoom to
look good as you need for a 2^70 zoom. You *could* use the larger amount
of iterations also for the 2^30 zoom, but it would change very little
(only pixels adjacent to the set would probably get different coloring).

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Invisible <voi### [at] devnull> wrote:
> > It's also very pink. I don't know what this was rendered with, but it
> > seems to have a 256-colour limit, meaning that the colours repeat a hell
> > of a lot. I did a zoom not unlike this using POV-Ray. Obviously the AA
> > is all over the place, but it does mean I have unlimited colours, and I
> > can map them as I see fit.
>
>   Naturally POV-Ray won't cut it for such a deep zoom because it will
> start glitching out at about 2^50 zoom factor (because 'double' only
> has 53 mantissa bits). You need a software with multiple-precision
> floating point numbers (or such a library, if you want to write the
> program yourself). Of course rendering such deep zooms with such a
> library will be slooooow (because software floating point is very slow,
> and the amount of iterations required for such zoom levels doesn't help
> the matter either).
>

Povray runs out of steam long before you hit *that* limitation because of the
artificially low limit of 32000 set for the iterations.

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Warp wrote:
>>> and the amount of iterations required for such zoom levels doesn't help
>>> the matter either).
> 
>> I wouldn't think it takes more iterations per pixel to do a deep zoom than 
>> to do a surface zoom.
> 
>   It does. Each color band in the classically-colored Mandebrot set (which
> is what is used in the video) represents one iteration. Now count how many
> distinct color bands there are in the entire video (I have no idea, but
> I'm guessing it's in the millions).

Maybe I've misspoken somewhere.

Figuring out what color to make one pixel near the end of the video doesn't 
take more iterations than figuring out what color to make one pixel near the 
start of the video?

It sounds like you're saying that a 1 minute video takes fewer iterations 
than a 10 minute video. Yes, that seems obvious.

But does drawing a 640x480 pixel section of the mandelbrot set (on the 
border of course) that's 0.0001 on a size take fewer iterations than drawing 
a 640x480 pixel section of the mandelbrot set that/s 0.000000000000001 on a 
side?

>   It's more like you don't *need* so many iterations for a 2^30 zoom to
> look good as you need for a 2^70 zoom. 

I don't see how this works out, tho. If you have 256 colors, you (could) do 
256 iterations for each pixel, regardless of the mapping of the cartesian 
plane to the screen, yes?

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

> Maybe I've misspoken somewhere.
>
> Figuring out what color to make one pixel near the end of the video
> doesn't take more iterations than figuring out what color to make one
> pixel near the start of the video?

To be absolutely technically correct, computing pixels at a higher 
magnification does not /necessarily/ require more iterations. However, 
if the part you're magnifying is one of the "interesting" bits (i.e., 
not a screenful of flat colour) then yes, yes it does take more iterations.

> I don't see how this works out, tho. If you have 256 colors, you (could)
> do 256 iterations for each pixel, regardless of the mapping of the
> cartesian plane to the screen, yes?

If you only do 256 iterations, then after a very modest zoom (30x or 
so), you won't see any additional detail.

(I presume you meant "up to" 256 iterations, since the pixel's colour 
indicates the exact number of iterations performed - or in this case, 
the least significant 8 bits of the count, anyway...)

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Figuring out what color to make one pixel near the end of the video doesn't 
> take more iterations than figuring out what color to make one pixel near the 
> start of the video?

  It does.

  The farther away you are from the border of the set, the fewer iterations
it takes for the complex numbers to bail out (ie. to exit the circle of
radius 2, which is usually what's used for this). The closer you get to
the border of the set, the more iterations it takes for it to bail out.

  If you do too few iterations, points very close to the set will look like
they belong to the set even though they don't, and thus get wrongly colored
like the interior of the set (in other words, all color bands which are
closer to the set than the iteration amount will get colored black).

  Zooming into the Mandelbrot set usually means zooming to some point which
is extremely close to the border of the set (any other place would be boring
because you would get a flat color after a little while). Zooming to a point
which is extremely close to the set means in practice that you are approaching
the border of the set, and hence you need larger iteration counts in order
to get the correct result. (If you don't increase the iteration count
appropriately, you end up having a wrongly-colored black image.)

  As I said in my earlier post, with the classical coloring each color
band represents one iteration (in other words, all the pixels of that
color took the same amount of iterations to bail out). The pixels of a
color band immediately inside another color band took 1 iteration more
to calculate. If you count the total number of distinct color bands,
you will get how many iterations it took for (each of the pixels of) the
innermost color band to calculate.

  In the video I estimate this count is in the millions.

> It sounds like you're saying that a 1 minute video takes fewer iterations 
> than a 10 minute video. Yes, that seems obvious.

  No, I'm talking about individual images. The amount of iterations needed
to get a proper result depends on the zoom level.

> But does drawing a 640x480 pixel section of the mandelbrot set (on the 
> border of course) that's 0.0001 on a size take fewer iterations than drawing 
> a 640x480 pixel section of the mandelbrot set that/s 0.000000000000001 on a 
> side?

  Yes, if you are looking at the border of the set (and you want a result
which is correct).

> >   It's more like you don't *need* so many iterations for a 2^30 zoom to
> > look good as you need for a 2^70 zoom. 

> I don't see how this works out, tho. If you have 256 colors, you (could) do 
> 256 iterations for each pixel, regardless of the mapping of the cartesian 
> plane to the screen, yes?

  The palette size doesn't affect how many iterations you need to perform
per pixel in order to get a correct image. It's simply that the iteration
count (before bailout) is mapped to the color palette, and you can do that
however you wish.

-- 
                                                          - Warp

Post a reply to this message

gregjohn <pte### [at] yahoocom> wrote:
> Povray runs out of steam long before you hit *that* limitation because of the
> artificially low limit of 32000 set for the iterations.

  Why is there such a limit?

-- 
                                                          - Warp

Post a reply to this message

Le 02/11/2010 15:03, Warp a écrit :
> gregjohn <pte### [at] yahoocom> wrote:
>> Povray runs out of steam long before you hit *that* limitation because of the
>> artificially low limit of 32000 set for the iterations.
> 
>   Why is there such a limit?
> 
Is there such limit ? (in which version ?)
I do not see such limit to 32000 in mandel pattern in 3.7beta38 code.
And it does not seems to be present either in 3.6.1;

Now the actual code of mandelbrot's pattern computation might be
sub-optimal when compared to dedicated code. But that's another story.

-- 
A good Manager will take you
through the forest, no mater what.
A Leader will take time to climb on a
Tree and say 'This is the wrong forest'.

Post a reply to this message

Le 02/11/2010 15:47, Le_Forgeron a écrit :
> And it does not seems to be present either in 3.6.1;

I stand corrected, in 3.6.1, it's a short;
And it is still so in 3.7;

It can probably easily be fixed by a change of type in the frame.h for
3.7 (Iterations field)

-- 
A good Manager will take you
through the forest, no mater what.
A Leader will take time to climb on a
Tree and say 'This is the wrong forest'.

Post a reply to this message

Le_Forgeron <lef### [at] freefr> wrote:
> Le 02/11/2010 15:47, Le_Forgeron a écrit :
> > And it does not seems to be present either in 3.6.1;
>
> I stand corrected, in 3.6.1, it's a short;
> And it is still so in 3.7;
>
> It can probably easily be fixed by a change of type in the frame.h for
> 3.7 (Iterations field)
>
> --

Thanks for the discussion, but are you saying there are some versions of povray
with a limit, or that I need to prove my assertion?  As an animator I *am* stuck
with Megapov because I need some of the features that aren't allowed into the
3.5+x versions of povray.

Post a reply to this message

Warp wrote:
>   The farther away you are from the border of the set, the fewer iterations
> it takes for the complex numbers to bail out (ie. to exit the circle of
> radius 2, which is usually what's used for this). The closer you get to
> the border of the set, the more iterations it takes for it to bail out.

Ah! I see. Very cool.  Thanks for the insight!  That makes sense now.  I 
hadn't connected it with "how close to the edge are you".

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

Le 02/11/2010 16:18, gregjohn nous fit lire :

> Thanks for the discussion, but are you saying there are some versions of povray
> with a limit, or that I need to prove my assertion?

First one. I first look at the parsing and usage of the iteration limit,
and see no limitation to 32000 (they all use int, which is expected to
be something like 31 bits value on most hardware).
Then I (too late) open the struct definition... to find that the value
is stored in an short.

>  As an animator I *am* stuck
> with Megapov because I need some of the features that aren't allowed into the
> 3.5+x versions of povray.
> 

Just out of curiosity (3.7 is so late that adding more features now is
probably a big no-no, and I'm not in charge of that anyway), which ones ?

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:
> Le 02/11/2010 16:18, gregjohn nous fit lire :
>
> > Thanks for the discussion, but are you saying there are some versions of povray
> > with a limit, or that I need to prove my assertion?
>
> First one. I first look at the parsing and usage of the iteration limit,
> and see no limitation to 32000 (they all use int, which is expected to
> be something like 31 bits value on most hardware).
> Then I (too late) open the struct definition... to find that the value
> is stored in an short.
>
> >  As an animator I *am* stuck
> > with Megapov because I need some of the features that aren't allowed into the
> > 3.5+x versions of povray.
> >
>
> Just out of curiosity (3.7 is so late that adding more features now is
> probably a big no-no, and I'm not in charge of that anyway), which ones ?


i) camera_view
ii) STP
iii) advanced splines: it actually made a difference in the look of some of my
SDL- procedurally-generated mesh-based modeling, but might be hard to prove it
right now.


Feel free to deduct 10 points from my score if the latest 3.x were to have
actually most of these.)


Thanks also for checking on the Mandel code. I found that the iterations limit
of 32000 makes for "ugliness" at high mag long before the calculation precision
runs out. How about making that a double ! ;-)

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   The farther away you are from the border of the set, the fewer iterations
> > it takes for the complex numbers to bail out (ie. to exit the circle of
> > radius 2, which is usually what's used for this). The closer you get to
> > the border of the set, the more iterations it takes for it to bail out.

> Ah! I see. Very cool.  Thanks for the insight!  That makes sense now.  I 
> hadn't connected it with "how close to the edge are you".

  Btw, that also explains why you need more mantissa bits to zoom deeper.
The complex numbers which start "on screen" don't stay there during the
iterative process. Instead, they orbit around and start escaping to
infinity (in practical implementations it's tested if they leave the
circle of radius 2, because it's easy to prove that if an orbit leaves
that circle it will inevitably escape to infinity). Thus you need to be
able to take some complex numbers which require a very high accuracy
(dozens and even hundreds of decimal places, depending on the zoom level),
and do calculations until they reach the circle-of-radius-2 limit.

  You can see the mantissa limit being hit when you zoom enough into the
set when you start getting rectangular artifacts. As stated, standard
double-precision floating point variables allow a zoom factor of something
around 2^50 before you hit the limit.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> As stated, standard
> double-precision floating point variables allow a zoom factor of something
> around 2^50 before you hit the limit.
>

But povray's iterations limit of 32000 causes one to lose details far before you
get to that.

Post a reply to this message

Le 02/11/2010 20:09, gregjohn nous fit lire :
> Thanks also for checking on the Mandel code. I found that the iterations limit
> of 32000 makes for "ugliness" at high mag long before the calculation precision
> runs out. How about making that a double ! ;-)
> 
Well, their might be room for better usage of the structure:
 iterations, ext_type & int_type are all stored as short so far.

 * iterations could well be extended to an unsigned int (does negative
iteration make sense ?) (I'm afraid of a per-pixel-loop of more than
2^32, as the next step would be 2^64 (it might have a portability issue
too) even at 2 Giga operation per second, that's only 2 x 2^30 loop per
second, at best 2^32 needs a few seconds, we do not want to wait for
2^34 seconds for one pixel (even per core...). So 32 bits for the
iterations should be enough, shouldn't it ?

 * both *_type are 0 to 6... they could share a byte (it's worthless on
current architecture, they can probably have their own byte anyway,
allowing fancy extension from 7 to 127 or 255 if anyone ever come with
such new different conversions from computation to the map)

And looking at the type, I wonder why there is not already something like:
(for exterior, i guess; as for interior, it's a constant)
   return (Iterations % (Factor+1))/Factor
(or simile)

Post a reply to this message

mesmerizing...

yeah, only took the time to watch it now...

Post a reply to this message

On 11/2/2010 8:14 PM, nemesis wrote:
> yeah, only took the time to watch it now...

Me too.  I didn't watch it previously because it was posted on 10/31, so 
I expected it to end with me getting the sh** scared out of me by a loud 
scream and a picture of Linda Blair popping up.

Post a reply to this message

Francois Labreque <fla### [at] videotronca> writes:

> Holy crap!  FractInt is still maintained!  There goes today's hope of
> doing actual work.

Not well maintained, though.

--

Post a reply to this message

>> Holy crap!  FractInt is still maintained!  There goes today's hope of
>> doing actual work.
>
> Not well maintained, though.

No, there is that.

Then again, most of the recent questions on the FractInt mailing list 
are "how do I make FractInt run under Windows XP?" or "how do I make an 
MS-DOS boot disk?"

It's a powerful little program, for sure, but I fear it has been 
somewhat left behind by now...

Post a reply to this message

Invisible wrote:
> It's a powerful little program, for sure, but I fear it has been 
> somewhat left behind by now...

Is it open source? It would seem to be the kind of thing that isn't hard to 
keep up to date, at least at the core.

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> >> Holy crap!  FractInt is still maintained!  There goes today's hope of
> >> doing actual work.
> >
> > Not well maintained, though.

> No, there is that.

> Then again, most of the recent questions on the FractInt mailing list 
> are "how do I make FractInt run under Windows XP?" or "how do I make an 
> MS-DOS boot disk?"

> It's a powerful little program, for sure, but I fear it has been 
> somewhat left behind by now...

  I would recommend XaoS. It might have all the features of fractint, but
most fractals can be zoomed in real-time, which makes it cool.

-- 
                                                          - Warp

Post a reply to this message

On Mon, 08 Nov 2010 19:54:16 +0200, Warp <war### [at] tagpovrayorg> wrote:

> Invisible <voi### [at] devnull> wrote:
>> >> Holy crap!  FractInt is still maintained!  There goes today's hope of
>> >> doing actual work.
>> >
>> > Not well maintained, though.
>
>> No, there is that.
>
>> Then again, most of the recent questions on the FractInt mailing list
>> are "how do I make FractInt run under Windows XP?" or "how do I make an
>> MS-DOS boot disk?"
>
>> It's a powerful little program, for sure, but I fear it has been
>> somewhat left behind by now...
>
>   I would recommend XaoS. It might have all the features of fractint, but
> most fractals can be zoomed in real-time, which makes it cool.
>

I'd love to see a screensaver like that =)

-Nekar Xenos-

Post a reply to this message

>> It's a powerful little program, for sure, but I fear it has been
>> somewhat left behind by now...
>
> Is it open source? It would seem to be the kind of thing that isn't hard
> to keep up to date, at least at the core.

Yeah, the source code is completely open.

On the other hand, the entire UI is text-mode fun and games using BIOS 
calls, and the entire graphical engine revolves around either calling 
the BIOS or directly poking magic numbers into hardware registers. 
(Wanna guess why it doesn't work under Windows any more?)

On top of that, the entire program fundamentally assumes you're working 
with 6 bits per channel and palette graphics. These assumptions are not 
easy to change. (E.g., all of the external file formats describe colours 
as triples of integers between 0 and 63.)

Really, it would be simpler and quicker to just start again. And indeed 
many modern fractal programs understand FractInt parameter files as a 
sort of de facto data standard. (Although none of them have the layers 
upon layers of backwards compatibility that FractInt itself has, and 
AFAIK none of them can read the data chunks that FractInt embeds in the 
GIF files it writes.)

Then again, I'm not really aware of any freeware program that has quite 
the range of scope that FractInt has. Most of them seem to plot just one 
kind of fractal, and that's it...

Post a reply to this message

On 08/11/2010 05:54 PM, Warp wrote:

>    I would recommend XaoS. It might have all the features of fractint, but
> most fractals can be zoomed in real-time, which makes it cool.

On the other hand, it seems to be comparatively slow. And it doesn't 
have arbitrary precision, so you can only zoom in so far. (Then again, 
FractInt's arbitrary precision mode makes continental drift look fast, 
so...)

It also has an annoying habit of sometimes "forgetting" to finish 
rendering an image. Like, when you zoom in it's all blocks, and 
gradually the resolution increases. But sometimes, it stops increasing 
before it's finished.

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> On 08/11/2010 05:54 PM, Warp wrote:

> >    I would recommend XaoS. It might have all the features of fractint, but
> > most fractals can be zoomed in real-time, which makes it cool.

> On the other hand, it seems to be comparatively slow.

  Comparatively slow? You can use XaoS to zoom into the Mandelbrot set
(and other fractals) in real-time. Fractint isn't that good.

> (Then again, 
> FractInt's arbitrary precision mode makes continental drift look fast, 
> so...)

  Btw, "continental drift" is an obsolete theory. "Plate tectonics" is the
currently accepted one.

  (Of course you are talking figuratively, but I couldn't help but nitpick.)

-- 
                                                          - Warp

Post a reply to this message

>>>     I would recommend XaoS. It might have all the features of fractint, but
>>> most fractals can be zoomed in real-time, which makes it cool.
>
>> On the other hand, it seems to be comparatively slow.
>
>    Comparatively slow? You can use XaoS to zoom into the Mandelbrot set
> (and other fractals) in real-time. Fractint isn't that good.

FractInt seems to render things quite a bit faster than Xaos. I haven't 
actually measured it, it just seems more responsive. And you don't need 
to zoom in very far before you have to frequently stop zooming and let 
Xaos catch up with redrawing the image, so you can see where to go next.

(It probably doesn't help that Xaos uses boundary-trace to draw the 
image in certain instances, and the display updates very, very 
infrequently while it does this. With FractInt, you can see what's 
happening while it does this. It's kind of mesmerising, actually...)

>    Btw, "continental drift" is an obsolete theory. "Plate tectonics" is the
> currently accepted one.

It's news to me that continental drift isn't the same thing as plate 
tectonics...

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> >    Btw, "continental drift" is an obsolete theory. "Plate tectonics" is the
> > currently accepted one.

> It's news to me that continental drift isn't the same thing as plate 
> tectonics...

  Wikipedia is your friend.

-- 
                                                          - Warp

Post a reply to this message