 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chambers <ben### [at] pacificwebguycom> wrote:
> 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
yes, an example of hardware limits is that, due to limited z buffer
precision, the ratio between far and near clip planes needs to be kept
within certain limits (which vary depending on the accuracy you need). Some
ppl, use a rule of 1:300.
But POV renders to files so no issue with z buffer there.
However the limits of double precision still apply and you can lose accuracy
even at distances that would normally not be considered too large for double
precision, as my paper and "stress test" program show.
cheers,
chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
dragonmage <dra### [at] gmailcom> wrote:
> yes, an example of hardware limits is that, due to limited z buffer
> precision, the ratio between far and near clip planes needs to be kept
> within certain limits (which vary depending on the accuracy you need). Some
> ppl, use a rule of 1:300.
> But POV renders to files so no issue with z buffer there.
I think you have some confusions there. Firstly, POV-Ray doesn't use
any Z-buffer of any kind (raytracers don't need those), and secondly,
even if it used one, rendering to a file or to the screen makes no
difference, why would it? It's not like rendering to a file magically
removed the need for Z-buffering compared to rendering to the screen.
(And no, Z-buffering is not automatic/mandatory even if you scanline-render
using 3D hardware. It's perfectly possible to turn the Z-buffer off.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
