 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] san rrcom> 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
|
|
| |
| |
|
|
|
|
| |
