Does this mean I won't be able to do a scene that starts on earth, flies up
into space and look at earth again with the sun included?

Nekar

"Ron Parker" <ron### [at] povrayorg> wrote in message
news:slr### [at] fwicom...
> On Sat, 31 Mar 2001 11:19:04 -0700, Xplo Eristotle wrote:
> >That sounds almost exactly like my problem. So this is, in fact, a
> >long-standing bug in POV-Ray?
>
> Not a bug.  A design flaw, perhaps, but not a bug.  POV-Ray is not
> designed to do full-scale simulations of microscopic or astronomical
> distances, and especially not of both in the same scene.
>
> --
> Ron Parker   http://www2.fwi.com/~parkerr/traces.html
> My opinions.  Mine.  Not anyone else's.

Post a reply to this message

Tek <tek### [at] evilsuperbraincom> wrote:
: you can do 2 billion in integers). What it also means is that nothing is
: ever precise

  I wouldn't say "ever". For example 1.0 + 1.0 is exactly 2.0, no more, no
less. (Well, at least if IEEE floating point numbers are used.)

  Of course something like 1.1 + 1.1 may not be exactly 2.2... (mainly
because the value 1.1 can't be represented accurately in the IEEE format.)

-- 
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););}    /*- Warp -*/

Post a reply to this message

Nekar Xenos <vir### [at] iconcoza> wrote:
: Does this mean I won't be able to do a scene that starts on earth, flies up
: into space and look at earth again with the sun included?

  Everything has its price.
  If you wanted variable precision floating point numbers, then povray would
be about 100 times slower than it's now. And we don't want that, do we?
  So we have to use the system's own floating point numbers. They are usually
64 bit long, and you can easily see that with that amount of bits there's a
rather small set of numbers that can be represented ("small" if we are
talking about scale differences comparable to the stars and to individual
atoms). The advantage of using those is the incredible speed boost (which
is natural since the numbers are crunched in hardware).

  And to answer your question: Yes, you can make a scene where you can
fly from the earth to the stars, but you can't have both things at the
same time. You have to first model the earth with big accuracy and the
stars with low accuracy, and as you fly away from one and towards the other
you have to lower the accuracy of the first and increase the accuracy of
the second.
  This only means that you can't have a scene of the surface of the earth
and an extremely powerful telescope looking at the surface of another
planet (not without using tricks, that is).

-- 
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););}    /*- Warp -*/

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3ac8608f@news.povray.org...
> Nekar Xenos <vir### [at] iconcoza> wrote:
> : Does this mean I won't be able to do a scene that starts on earth, flies
up
> : into space and look at earth again with the sun included?
>
>   Everything has its price.
>   If you wanted variable precision floating point numbers, then povray
would
> be about 100 times slower than it's now. And we don't want that, do we?
>   So we have to use the system's own floating point numbers. They are
usually
> 64 bit long...
>

    A systems floating point numbers may well be 64-bit, but POVs aren't -
not under Windows, anyhow - take a look at the source - it uses nothing but
32-bit floats, which according to the MSDN, gives 6-7 sig. digits and a
range of 1.17549351E-38 to 3.402823466E+38. Upping all the floats to 64-bit
doubles would give a much more respectable 16-16 sig. digits and a range of
2.2250738585072014E-308 to 1.7976931348623158E+308.

--
Scott Hill
Software Engineer.
NC Graphics (Cambridge) Ltd.
Web : http://www.ncgraphics.co.uk
E-mail : sco### [at] ncgraphicsnet
ICQ : 110661991

Post a reply to this message

On Tue, 10 Apr 2001 15:57:09 +0100, Scott Hill wrote:
>    A systems floating point numbers may well be 64-bit, but POVs aren't -
>not under Windows, anyhow - take a look at the source - it uses nothing but
>32-bit floats, which according to the MSDN, gives 6-7 sig. digits and a

I suspect you need to look at the source again.  Most important stuff is
declared as DBL, which is a typedef for double.  On x86en, that's 64 bits.
The only things I can think of that are floats are color components, which 
don't need 64 bits of resolution anyway.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote:
: The only things I can think of that are floats are color components, which 
: don't need 64 bits of resolution anyway.

  If I read the source code correctly, there's another thing which is stored
with 32-bit floats (using the SNGL data type): Triangle mesh vertices and
normals.
  I really don't like this (since meshes are usually HUGE with lots of
tiny details), but I suppose it's done so for memory saving reasons.

-- 
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););}    /*- Warp -*/

Post a reply to this message

"Ron Parker" <ron### [at] povrayorg> wrote in message
news:slr### [at] fwicom...
> On Tue, 10 Apr 2001 15:57:09 +0100, Scott Hill wrote:
> >    A systems floating point numbers may well be 64-bit, but POVs
aren't -
> >not under Windows, anyhow - take a look at the source - it uses nothing
but
> >32-bit floats, which according to the MSDN, gives 6-7 sig. digits and a
>
> I suspect you need to look at the source again.  Most important stuff is
> declared as DBL, which is a typedef for double.  On x86en, that's 64 bits.
> The only things I can think of that are floats are color components, which
> don't need 64 bits of resolution anyway.
>


    Well, as I don't have a copy of the source handy I'll have to take your
word for it. However, I'm sure when I looked at the source (to self : or was
it the MegaPOV source ?) everything used SNGL - I remember because I started
going through changing everything to DBL. My memory could be in error, but
if it is, I've got no idea what is I could be miss-remembering.

Odd.

--
Scott Hill
Software Engineer.
NC Graphics (Cambridge) Ltd.
Web : http://www.ncgraphics.co.uk
E-mail : sco### [at] ncgraphicsnet
ICQ : 110661991

Post a reply to this message

Scott Hill <sco### [at] ncgraphicsnet> wrote:
: However, I'm sure when I looked at the source (to self : or was
: it the MegaPOV source ?) everything used SNGL - I remember because I started
: going through changing everything to DBL. My memory could be in error, but
: if it is, I've got no idea what is I could be miss-remembering.

  In the povray 3.1 source directory:

% cat *.c *.h | grep -c "DBL"
1645
% cat *.c *.h | grep -c "SNGL"
72


-- 
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););}    /*- Warp -*/

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
: % cat *.c *.h | grep -c "DBL"
: 1645
: % cat *.c *.h | grep -c "SNGL"
: 72

  And by the way, that's only the number of _lines_ where those words
appear, not the total count of appearances.
  A more sophisticated command (read: kludge) can count the total number
of appearances:

% cat *.c *.h | grep "DBL" | perl -pe 's/DBL/\nDBL\n/g' | grep -c "DBL" 
2054
% cat *.c *.h | grep "SNGL" | perl -pe 's/SNGL/\nSNGL\n/g' | grep -c "SNGL"
78


-- 
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););}    /*- Warp -*/

Post a reply to this message

On 12 Apr 2001 11:22:19 -0400, Warp wrote:
>% cat *.c *.h | grep "DBL" | perl -pe 's/DBL/\nDBL\n/g' | grep -c "DBL" 

Or the much shorter

$ cat *.h *.c | perl -0 -ne "print scalar s/DBL//g"

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message