 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
dragonmage wrote:
> Anyone have insight into the actual part of the calculation that is failing?
There is no failure. The implementation is designed with certain limits for
the maximum and minimum intersection distances. This is necessary as
precision is finite and very large as well as very small numbers will
accumulate increasingly visible inaccuracies as they flow through the
intersection computations. Keep your scene within 10e7 to 10e-5 and you will
be fine for most object types.
Thorsten, POV-Team
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tim Attwood nous apporta ses lumieres en ce 20-03-2007 04:11:
>> You'd think that a double precision float would be able to handle more
>> than this, since the difference between the two is only 20 bits, but
>> apparently this is the limit.
> Oh yeah, I guess it uses doubles in there too, maybe 3.7 will be more
> accurate? (probably not though... but maybe the 64 bit version
> eventually?)
Version 3.7 use double precision the same way as version 3.6, 3.1 and previous.
64 bits processors still use the 64 (80 internal = double and half precision)
bits FPU used in previous 32 bits CPU, even 16 bits BPU used, then external, 64
bits FPU.
You need 128 bits FPU (quad precision) to realy exeed actual precision limitations.
--
Alain
-------------------------------------------------
Getting the job done is no excuse for not following the rules.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Chambers <ben### [at] pacificwebguy com> wrote:
>> You're dealing with two numbers, one of them being approximately 20
>> million times the other. It's a known aspect of the hardware we use
>> that you should keep your ratios smaller than this to avoid precision
>> errors.
>
> Where exactly are you getting that number?
Location of 1M, radius of 0.05. Since floating point uses, well, a
floating exponent, you're fine mixing numbers of the same scale, but
objects of extremely different scales won't necessarily have the same
precision when used together.
I assumed that it was this mixing of scales that caused the error
(similar to what's explained here:
http://tag.povray.org/povQandT/misconceptions.html, look under "Sunlight
Simulation"), as I didn't know about POV's internal limit on
intersection distances.
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> You are most probably hitting the internal limit set in POV-Ray for
> distances.
>
> POV-Ray uses a deliberate limit. If an intersection point is farther
> away than this limit, it's ignored.
>
> There are many reasons for setting up this kind of limit, one of which
> is to prevent the program from misrendering objects due to floating point
> inaccuracies. Granted, I think that limit could be made larger without
> any accuracy problems showing up, at least not with most primitives.
>
> --
> - Warp
Can you be more specific on what/where this limit is documented?
I am trying to search for it but not finding it amongst all the hits.
Not that there is very little distance between light, camera and objects:
they are all displaced together by 1mil from the origin.
chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
> dragonmage wrote:
> > Anyone have insight into the actual part of the calculation that is failing?
>
> There is no failure. The implementation is designed with certain limits for
> the maximum and minimum intersection distances. This is necessary as
> precision is finite and very large as well as very small numbers will
> accumulate increasingly visible inaccuracies as they flow through the
> intersection computations. Keep your scene within 10e7 to 10e-5 and you will
> be fine for most object types.
>
> Thorsten, POV-Team
Ah, thanks for the keywords I needed: "intersection distance".
Looking up this distance online it seems to be the distance between pixel
and intersection in scene. For my scene,there are only small distances
between the Pixels and the surfaces.
There are no large distances between light/object/eye in the given scene,
even tho the whole is displaced by 1M.
If you look at the values in the scene, there should be no intersection
distance more than a little over 20.
chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chambers <ben### [at] pacificwebguycom> wrote:
> Warp wrote:
> > Chambers <ben### [at] pacificwebguycom> wrote:
> >> You're dealing with two numbers, one of them being approximately 20
> >> million times the other. It's a known aspect of the hardware we use
> >> that you should keep your ratios smaller than this to avoid precision
> >> errors.
> >
> > Where exactly are you getting that number?
>
> Location of 1M, radius of 0.05. Since floating point uses, well, a
> floating exponent, you're fine mixing numbers of the same scale, but
> objects of extremely different scales won't necessarily have the same
> precision when used together.
Yes I see, note it is actually the accuracy that varies: precision is
constant at "double precision".
>
> I assumed that it was this mixing of scales that caused the error
> (similar to what's explained here:
That's reasonable and it does cause accuracy problems. Here the problem is
more that the shift away from the origin by 1M means that all coordinates
have less accuracy: the coordinate space has lower resolution.
Note: I am deliberately causing accuracy problems to measure the effects.
It is only in this case that the effect is not completely explainable (to
me).
I know it is caused by loss of accuracy but not precisely why the strange
truncation is occurring as opposed to the more common effects such as
shifting of relative object positions (and the consequent changes in
rendering), z buffer tearing/clipping etc.
chris
> http://tag.povray.org/povQandT/misconceptions.html, look under "Sunlight
> Simulation"), as I didn't know about POV's internal limit on
> intersection distances.
>
> ...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chambers <ben### [at] pacificwebguycom> wrote:
> Warp wrote:
> > Chambers <ben### [at] pacificwebguycom> wrote:
> >> You're dealing with two numbers, one of them being approximately 20
> >> million times the other. It's a known aspect of the hardware we use
> >> that you should keep your ratios smaller than this to avoid precision
> >> errors.
> >
> > Where exactly are you getting that number?
> Location of 1M, radius of 0.05.
You didn't really answer my question.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Chambers <ben### [at] pacificwebguycom> wrote:
>> Warp wrote:
>>> Chambers <ben### [at] pacificwebguycom> wrote:
>>>> You're dealing with two numbers, one of them being approximately 20
>>>> million times the other. It's a known aspect of the hardware we use
>>>> that you should keep your ratios smaller than this to avoid precision
>>>> errors.
>>> Where exactly are you getting that number?
>
>> Location of 1M, radius of 0.05.
>
> You didn't really answer my question.
>
OK Warp, then 1M / 0.05 = 20M. So the one number is 20M times the other.
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chambers <ben### [at] pacificwebguycom> wrote:
> Warp wrote:
> > Chambers <ben### [at] pacificwebguycom> wrote:
> >> Warp wrote:
> >>> Chambers <ben### [at] pacificwebguycom> wrote:
> >>>> You're dealing with two numbers, one of them being approximately 20
> >>>> million times the other. It's a known aspect of the hardware we use
> >>>> that you should keep your ratios smaller than this to avoid precision
> >>>> errors.
> >>> Where exactly are you getting that number?
> >
> >> Location of 1M, radius of 0.05.
> >
> > You didn't really answer my question.
> >
> OK Warp, then 1M / 0.05 = 20M. So the one number is 20M times the other.
You are not understanding.
You said, and I quote: "It's a known aspect of the hardware we use
that you should keep your ratios smaller than this to avoid precision
errors."
I didn't know that the ratio between double precision floating point
numbers must be smaller than 20 millions in order to preserve accuracy.
I asked where did you get that number.
The limit hit by the original poster has nothing to do with double
precision floating point number accuracy.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> You are not understanding.
>
> You said, and I quote: "It's a known aspect of the hardware we use
> that you should keep your ratios smaller than this to avoid precision
> errors."
> I didn't know that the ratio between double precision floating point
> numbers must be smaller than 20 millions in order to preserve accuracy.
> I asked where did you get that number.
Thanks for clarifying. It was a faulty assumption on my part.
It IS true that you should keep your numbers in the same range for the
greatest accuracy. As I was unaware of the internal limits imposed by
POV-Ray, I assumed this range difference was the culprit, and therefore
I assumed that the limit had been reached.
Really what I should have said was, "It's a known aspect of the hardware
we use that you should keep your ratios within a reasonable limit to
avoid precision errors, and I'm assuming that you have reached that limit."
Of course he hadn't yet reached that limit, but instead had run into
POV's internal limits.
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
