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