 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'm trying to model an astronomical situation, with everything to scale.
As this is vaguely scientific, I'm trying to use standard units
throughout, which means that some of my coordinates are rather large.
I'm finding that Povray appears to behave rather oddly when dealing with
very large coordinates. In particular, the world seems to be being
clipped by an invisible sphere at about 30e6 radius from the camera ---
although light sources outside this sphere work fine.
Are there any limits to the world size that I should be aware of? If so,
can they be adjusted?
--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─────
http://www.cowlark.com ─────
│
│ "Sufficiently advanced incompetence is indistinguishable from
│ malice." -- Vernon Schryver
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 02.01.10 12:57, David Given wrote:
> I'm trying to model an astronomical situation, with everything to scale.
> As this is vaguely scientific, I'm trying to use standard units
> throughout, which means that some of my coordinates are rather large.
<http://wiki.povray.org/content/Knowledgebase:Language_Questions_and_Tips#Topic_24>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 02/01/10 13:02, Thorsten Froehlich wrote:
> On 02.01.10 12:57, David Given wrote:
>> I'm trying to model an astronomical situation, with everything to scale.
>> As this is vaguely scientific, I'm trying to use standard units
>> throughout, which means that some of my coordinates are rather large.
>
> <http://wiki.povray.org/content/Knowledgebase:Language_Questions_and_Tips#Topic_24>
Thanks, but I'm not sure whether this is actually the problem --- I've
tried scaling my entirely model down by a factor of 1000 (so that I'm
now working with kilometres rather than metres) and everything behaves
much better. This suggests that it's related to absolute magnitude
rather than precision (because that hasn't changed).
In addition, if I carefully ease an object over the edge of the boundary
I can see it getting clipped. I wouldn't expect precision errors to
behave with, well, such precision!
Can Povray be built to use long doubles instead of doubles?
--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─────
http://www.cowlark.com ─────
│
│ "Sufficiently advanced incompetence is indistinguishable from
│ malice." -- Vernon Schryver
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 02/01/2010 15:34, David Given nous fit lire :
> On 02/01/10 13:02, Thorsten Froehlich wrote:
>> On 02.01.10 12:57, David Given wrote:
>>> I'm trying to model an astronomical situation, with everything to scale.
>>> As this is vaguely scientific, I'm trying to use standard units
>>> throughout, which means that some of my coordinates are rather large.
>> <http://wiki.povray.org/content/Knowledgebase:Language_Questions_and_Tips#Topic_24>
>
> Thanks, but I'm not sure whether this is actually the problem --- I've
> tried scaling my entirely model down by a factor of 1000 (so that I'm
> now working with kilometres rather than metres) and everything behaves
> much better. This suggests that it's related to absolute magnitude
> rather than precision (because that hasn't changed).
>
> In addition, if I carefully ease an object over the edge of the boundary
> I can see it getting clipped. I wouldn't expect precision errors to
> behave with, well, such precision!
>
> Can Povray be built to use long doubles instead of doubles?
>
Your problem is that there is two kind of precision...magnitude.
Your scene provide units with magnitude U & precision u.
But some objects are transformed to unit object internally and back to
your scene dimension once rendered. For instance, the length of a full
cone is always 1.0 in the solver. And that solver has a finite precision
limit too. That precision get boosted back as magnitude when returning
to the scene space.
So, reducing the magnitude in the scene does in fact has an impact on
the precision. For astronomical system, you would better use thousand of
kilometers as a unit. (Earth perimeter = 4... Radius = 4/(2*PI) )
In fact, you'd better use UA directly ( 1 UA = 149.60×10^9 m),
leaving the oort clouds at its 50 000 UA radius!
Sedna has quite a small orbit with its 928 UA aphelie.
Changing to long doubles instead of double: the issue is that not only
the type must be changed in structure (easy), but that all functions
calls (for the maths) must be replaced with the relevant long double
functions (and long double are not portable, at least not backward with
old architectures still supported): cosl instead of cos, sqrtl for sqrt,
... everywhere. (otherwise, the internal would use 64 bits while storing
it inside a 128 bits **) That's a lot of code to change, for a very
marginal gain, if any.
The time to play on the long double might be significantly longer than
on a double, especially on 32 bits architectures. (you would also fill
the cpu cache quicker, meaning a very actual loss of performance
sooner). Have you yet some FPU with a 160 bits units ? (assuming the
same ranges for 64/80: 128/160 ?? )
Graphics cards have large bus, but usually they pump more than one float
at a time, they rarely deals with such precision either.
**: Beware, even when using long double, you might get a compiler which
handles them as double (from the size point of view).
PS: the industry seems to hesitate currently between binary128 (basic
extension of IEEE-754 to 1/15/113 (whereas 64 bits is 1/11/53, & 32 :
1/8/24 ), and a new standard of 2008: decimal128 (allowing to keep
rounding precision as for accounting; the limit of decimal128 seems to
be that 10^34-1 with a precision of 1)...
and to make things worst, decimal*** has two representation: a simple
binary one, and a densely packed decimal significand one.
Wait & See!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 02/01/10 15:41, Le_Forgeron wrote:
[...]
> Your problem is that there is two kind of precision...magnitude.
Well, blast.
> So, reducing the magnitude in the scene does in fact has an impact on
> the precision. For astronomical system, you would better use thousand of
> kilometers as a unit. (Earth perimeter = 4... Radius = 4/(2*PI) )
I'd very much like to use meaningful units where possible, simply to
stop myself getting confused... at what point do the large numbers cause
problems? Could I avoid the whole issue by, for example, constructing my
model in metres or kilometres, scaling it to millions of kilometres or
AUs, and adding it to the universe? Or am I basically unable to reliably
model objects in the metre scale and objects in the 10^9 metre scale at
the same time?
[...]
> Changing to long doubles instead of double: the issue is that not only
> the type must be changed in structure (easy), but that all functions
> calls (for the maths) must be replaced with the relevant long double...
Oh, well, it was a thought. Probably wouldn't have helped much anyway.
Now, a version of Povray built to use bignums... *then* we'd be getting
somewhere!
--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─────
http://www.cowlark.com ─────
│
│ "Sufficiently advanced incompetence is indistinguishable from
│ malice." -- Vernon Schryver
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David Given wrote:
> I'd very much like to use meaningful units where possible, simply to
> stop myself getting confused... at what point do the large numbers caus
e
> problems? Could I avoid the whole issue by, for example, constructing m
y
> model in metres or kilometres, scaling it to millions of kilometres or
> AUs, and adding it to the universe? Or am I basically unable to reliabl
y
> model objects in the metre scale and objects in the 10^9 metre scale at
> the same time?
>
No, you can't have both very big and very small objects at the same
time. As for modelling with meaningful units, that's easy:
#declare m = ...;
#declare km = 1000 * m;
#declare AU = 149.6e9 * m;
And then always use the units when modelling as in:
sphere {
0, // location
6400 * km // radius
...
}
Then you can adjust the internal representation by changing the
declaration of "m".
> [...]
>> Changing to long doubles instead of double: the issue is that not only
>> the type must be changed in structure (easy), but that all functions
>> calls (for the maths) must be replaced with the relevant long double..
.
>
> Oh, well, it was a thought. Probably wouldn't have helped much anyway.
>
> Now, a version of Povray built to use bignums... *then* we'd be getting
> somewhere!
>
Given the render times it would have, I'm not sure that *getting*
is the right word here ;)
Jerome
--
mailto:jeb### [at] free fr
http://jeberger.free.fr
Jabber: jeb### [at] jabberfr
Post a reply to this message
Attachments:
Download 'us-ascii' (1 KB)
|
|
| |
| |
|
|
|
|
| |
|
|
