 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
So... I am guessing that this is too big a number for POV to handle? I
know there is a limit but I forget what it is.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bill DeWitt wrote:
>
> So... I am guessing that this is too big a number for POV to handle? I
> know there is a limit but I forget what it is.
No, that's not the concept of floating point numbers, the absolute maximum
is 1.7 x 10^308 (for double), probably much more than you will ever need,
some cases, numbers like 6000000000 can already lead to precision
problems.
Christoph
--
Christoph Hormann <chr### [at] gmx de>
IsoWood include, radiosity tutorial, TransSkin and other
things on: http://www.schunter.etc.tu-bs.de/~chris/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christoph Hormann" <chr### [at] gmxde> wrote in message
news:3B17F8B1.3F27EDCE@gmx.de...
>
>
> Bill DeWitt wrote:
> >
> > So... I am guessing that this is too big a number for POV to handle?
I
> > know there is a limit but I forget what it is.
>
> No, that's not the concept of floating point numbers, the absolute maximum
> is 1.7 x 10^308 (for double), probably much more than you will ever need,
> but in any case there are only 15-16 significant decimals. Therefore in
> some cases, numbers like 6000000000 can already lead to precision
> problems.
My problem is that when I contain an iso in a large box, it disappears.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wasn't it Bill DeWitt who wrote:
> My problem is that when I contain an iso in a large box, it disappears.
That might possibly be due to insufficient max_gradient.
What can happen is that the renderer starts at the edge of the box, and
evaluates the function there. If the value of the function is greater
than max_gradient * size-of-box, then it knows that the function can't
become zero anywhere in the box and gives up immediately.
E.g. if we examine the function {x^2 + y^2 + z^2 - 1}
This works fine with "method 2 eval" if it is contained by a box that's
smaller than box{-6.52,6.52}, but when it's contained by a larger box
there's bits missing, and if the box is larger than 6.62 it disappears
completely.
The gradient of the function at the corner of the box is actually about
2.83 * size-of-box, but for a 6.58 box "eval" guesses only 15.313
instead of 18.61. For larger boxes "eval" guesses lower and lower
numbers. Whenever the renderer is working with an incorrect max_gradient
(whether it's because you specified a wrong value, eval guessed wrongly,
or you didn't specify anything and it assumed the default) bits of the
surface are likely to go missing.
--
Mike Williams
Gentleman of Leisure
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann <chr### [at] gmxde> wrote:
: No, that's not the concept of floating point numbers, the absolute maximum
: is 1.7 x 10^308 (for double)
I think there are more inner limitations in POV-Ray besides that.
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
