POV-Ray : Newsgroups : povray.general : Double? Reasons for pixelation in mandelbrot Server Time
8 Aug 2024 16:19:12 EDT (-0400)
  Double? Reasons for pixelation in mandelbrot (Message 1 to 6 of 6)  
From: Greg M  Johnson
Subject: Double? Reasons for pixelation in mandelbrot
Date: 11 Dec 2000 08:53:23
Message: <3A34DAE9.30135268@my-dejanews.com>
WARNING:  I use MegaPov, but assume this is a 3.1g question, not a
mega-team's-code question.

Q1:
When I zoomed in on the Mandelbrot pattern with a camera 10 units away
from the pattern and an angle of 10E-12, I start to see pixelation in
the pattern.  I assume I've hit some kind of wall in the precision the
Mandel algorithm, povray itself, C itself, or my CPU.

One of the things this non-programmer loves about pov is that I don't
have to study 12 variable types--I put down gagging the Java and C books
that start with a couple of chapters on this subject .   However, is
there a way to get more precision, especially inside the Mandelbrot
pattern itself?

Q2:
For playing with the Mandelbrot pattern itself, I find povray to be far
superior to excellent programs like Fractint or perhaps even Tierazon.
The math behind these fractals have to do with the number of iterations
on some complex math before it explodes.  The question is, is there any
way to insert another equation into pov and have it compute this
iterations-till-explosion?   That is the one advantage that Tierazon
would still have over povray-- a huge grab bag of equations to play
with.  I figured out how to do math on the standard result of the
Mandelbrot--such as the square or sine of the value in the pattern, but
I'm looking for more...


Post a reply to this message

From: Warp
Subject: Re: Double? Reasons for pixelation in mandelbrot
Date: 11 Dec 2000 10:10:32
Message: <3a34ee68@news.povray.org>
Greg M. Johnson <gre### [at] my-dejanewscom> wrote:
: When I zoomed in on the Mandelbrot pattern with a camera 10 units away
: from the pattern and an angle of 10E-12, I start to see pixelation in
: the pattern.  I assume I've hit some kind of wall in the precision the
: Mandel algorithm, povray itself, C itself, or my CPU.

  Floating point numbers have limited accuracy. A camera angle of 10E-12
starts sounding like it really is reaching the limits of the floating
point numbers.
  It's a hardware thing. There's nothing that can be done about it.

: One of the things this non-programmer loves about pov is that I don't
: have to study 12 variable types--I put down gagging the Java and C books
: that start with a couple of chapters on this subject .   However, is
: there a way to get more precision, especially inside the Mandelbrot
: pattern itself?

  Not in povray scripting language.
  If you want more precision, you'll have to use bigger floating point
numbers (just like Fracting does). It is, however, extremely slow to do
this (as you can check with Fractint), so the benefits of doing this are
dubious. (It's slow because you don't have hardware support for bigger
numbers and thus you have to handle them with software, which makes it
very slow...)
  The only way of getting more accuracy would probably be compiling
povray in a system which supports larger numbers in hardware (eg. 128 bit
floating point numbers or whatever). There aren't many out there.
  In a PC you'll probably get a bit larger accuracy if you define the DBL
type in the povray source code as 'long double' (which in a PC with most
compilers is a 80-bit floating point number) and recompile. I doubt,
however, that you'll get much more accuracy (but your memory usage will
probably double).

: The question is, is there any
: way to insert another equation into pov and have it compute this
: iterations-till-explosion?

  Not currently.
  I have made a patch (found in MegaPov) for other fractal types (mandel3,
mandel4, julia, julia3, julia4, magent1m, magnet1j, magnet2m magnet2j for
instance), but that's all.
  If you want to play with other functions, you'll probably have to modify
the source code itself and recompile. This, of course, is more trouble than
it's worth, usually.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/


Post a reply to this message

From: Christoph Hormann
Subject: Re: Double? Reasons for pixelation in mandelbrot
Date: 11 Dec 2000 10:17:58
Message: <3A34F026.915095DB@gmx.de>
"Greg M. Johnson" wrote:
> 
> WARNING:  I use MegaPov, but assume this is a 3.1g question, not a
> mega-team's-code question.
> 
> Q1:
> When I zoomed in on the Mandelbrot pattern with a camera 10 units away
> from the pattern and an angle of 10E-12, I start to see pixelation in
> the pattern.  I assume I've hit some kind of wall in the precision the
> Mandel algorithm, povray itself, C itself, or my CPU.
> 

First there is the max_iteration parameter, but you probably already
checked it.  

The double data type itself can store values from 
1.7 x 10^-308 to 1.7 x 10^308 so i don't think that is the problem
(although i'm not totally sure)

> 
> Q2:
> For playing with the Mandelbrot pattern itself, I find povray to be far
> superior to excellent programs like Fractint or perhaps even Tierazon.
> The math behind these fractals have to do with the number of iterations
> on some complex math before it explodes.  The question is, is there any
> way to insert another equation into pov and have it compute this
> iterations-till-explosion?   That is the one advantage that Tierazon
> would still have over povray-- a huge grab bag of equations to play
> with.  I figured out how to do math on the standard result of the
> Mandelbrot--such as the square or sine of the value in the pattern, but
> I'm looking for more...

In megapov there are some more fractal types, furthermore i think it would
be possible to use the isosurface function parser for this purpose.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/


Post a reply to this message

From: Greg M  Johnson
Subject: Re: Double? Reasons for pixelation in mandelbrot
Date: 11 Dec 2000 10:21:31
Message: <3A34EFA4.A2E9B9DE@my-dejanews.com>
Warp wrote:

> I have made a patch (found in MegaPov) for other fractal types (mandel3,
> mandel4, julia, julia3, julia4, magent1m, magnet1j, magnet2m magnet2j for
> instance), but that's all.

But that's a lot.  Shouldda  RFTM!


Post a reply to this message

From: Greg M  Johnson
Subject: Re: Double? Reasons for pixelation in mandelbrot
Date: 11 Dec 2000 10:28:14
Message: <3A34F12D.74CE71BA@my-dejanews.com>
Christoph Hormann wrote:

> First there is the max_iteration parameter, but you probably already
> checked it.

Yes, I had it set at 1000.

As I understand it, it determines the number of possible values (colors)
returned by the pattern, or if one had an isosurface, the number of possible
heights to the pattern.

I'm talking about pixelation in the x  y plane.


Post a reply to this message

From: Warp
Subject: Re: Double? Reasons for pixelation in mandelbrot
Date: 11 Dec 2000 11:14:09
Message: <3a34fd50@news.povray.org>
Greg M. Johnson <gre### [at] my-dejanewscom> wrote:
: As I understand it, it determines the number of possible values (colors)
: returned by the pattern, or if one had an isosurface, the number of possible
: heights to the pattern.

  Well, not really. That's only a side-effect which is used to color the
exterior (and sometimes the interior) of the set.

  The mathematical definition of the Mandelbrot set defines that when the
function is iterated an infinite number of times, if the value of the
function converges to infinity, then the starting complex number does
not belong to the set. If the value doesn't converge to infinity, then
it belongs to the set.
  The mathematical definition of the Mandelbrot set doesn't say anything
about a certain number of iterations. I don't even think that it makes
sense to talk about "iterations". It's just a recursive function, that's all.

  Since in computers we can't iterate an infinite number of times and we
can't compare numbers to infinity, we have to use an approximation.
  Instead of iterating an infinite number of times we iterate a finite number
of times. Instead of comparing to infinity, we compare to a finite value.
  Fortunately a really good approximation can be achieved with rather small
finite values.
  It's easy to prove that if the orbit of the function ever goes outside
a sphere of radius 2, the function will converge to infinity. That's why
the value 2 is used.
  As for iterations, depending on the resolution of the image a rather
small number of them is enough to get a correct result at pixel-level
(that is, the error produced by the size of the pixel is larger than the
error produced by the limited iterations amount). Zooming the image just
increases the resolution and thus the number of iterations has to be
increased accordingly.

  The mandelbrot set is just a set of complex values.
  The colors seen around the set when it's drawn on screen are not part of
the set. They are (usually) generated by taking the number of iterations
before bailout (ie. before the orbit went outside the circle of radius 2)
and mapping this value to a color.
  That's why the number of iterations affects the colors used to draw the
set.
  It wouldn't be true to say that the colors have nothing to do with the
set itself, since they have. There's a property in the function that makes
points closer to the border of the set take longer to bailout. Because of
this, points closer to the set will take more iterations to bailout and
thus it will affect their color. This can bring out the shape of the set
although the set itself is not visible in some parts (because it's so small).
  However, the coloring according to the number of iterations is purely
artificial and has little to do with the Mandelbrot function itself (except
for the property described above).

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.