POV-Ray : Newsgroups : povray.programming : Request for Comment: AstroPov Server Time
28 Jul 2024 14:24:57 EDT (-0400)
  Request for Comment: AstroPov (Message 1 to 7 of 7)  
From: Chris Jeppesen
Subject: Request for Comment: AstroPov
Date: 28 Apr 2000 17:28:37
Message: <390a0285@news.povray.org>
I like to do astronomical (space probes in the solar system) raytracing.
Unfortunaltely, the current version of Povray can't handle extremely large
differences in numbers which are generated by this scenario.

I wish there were a program that can simultaneously handle:

1) Large and small. A sphere as large as the sun (10^10m) and one 1mm across
2) Near and Far. Simultaneously showing an object 1mm away from the camera
and one 10^12m away.
3) Small angles. Ideally, can see a 1mm object from 10^12 meters away.

The biggest difference in magnitude I am asking for is 10^15. Since double
precision numbers have 16 digits of precision, there should be no problem,
but I have tried tweaking the various constants which affect this sort of
thing to no avail. Tweaking constants is the current limit of my skills in
Povray source.

Any one know why this can't be done?


Post a reply to this message

From: Warp
Subject: Re: Request for Comment: AstroPov
Date: 29 Apr 2000 06:53:53
Message: <390abf41@news.povray.org>
Chris Jeppesen <chr### [at] digiquillcom> wrote:
: I like to do astronomical (space probes in the solar system) raytracing.
: Unfortunaltely, the current version of Povray can't handle extremely large
: differences in numbers which are generated by this scenario.

  And it probably never will (at least until the hardware develops so far that
bigger floating point numbers (say... 1024 bits at least) can be used).

: I wish there were a program that can simultaneously handle:

  I don't think there's any program out there which can handle this. The
problem is not the software, but the hardware.
  Ok, it is possible for the program to use its own floating point numbers
at whatever precision it wants, but that would slow down the program
considerably. Using the FPU for floating point calculations is just too
much faster than using the CPU for the same task.
  (For example an addition of two floating point numbers take usually one
clock cycle of processor time using the FPU; the same addition made with
software and bigger floating point numbers will probably take tens of even
hundreds of clock cycles.)

: Any one know why this can't be done?

  As I said, the hardware, ie. the FPU can handle only limited sized
floating point numbers. In povray usually the 'double' type is used, which
means a 64 bits floating point number in most systems (PC, sparc, ...).
It is pretty accurate, but it starts to be more and more inaccurate when
we use values that are extremely large and extremely small at the same time.


-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/


Post a reply to this message

From: Nigel Stewart
Subject: Re: Request for Comment: AstroPov
Date: 29 Apr 2000 12:32:21
Message: <390B0E01.A54CF4F1@nigels.com>
> I like to do astronomical (space probes in the solar system) raytracing.
> Unfortunaltely, the current version of Povray can't handle extremely large
> differences in numbers which are generated by this scenario.

	Something that I've found helpful is the facility to 
	adjust your units, according to the detail you're
	trying to capture.  For example, if you use AU
	(Astronomical Units) and you're rendering the
	solar system, perhaps setting AU to 1.0 makes
	sense.  But, if you want to model leaves on a
	tree on earth, 1 Meter should equal 1.0 and
	AU something much larger.  (Lack of precision
	of the position of Jupiter is not so much of
	an issue in this situation)

	Not a general solution, but a helpful technique.

--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.


Post a reply to this message

From: Peter J  Holzer
Subject: Re: Request for Comment: AstroPov
Date: 30 Apr 2000 14:01:16
Message: <slrn8gosfk.peg.hjp-usenet@teal.h.hjp.at>
On Fri, 28 Apr 2000 14:28:32 -0700, Chris Jeppesen wrote:
>I like to do astronomical (space probes in the solar system) raytracing.
>Unfortunaltely, the current version of Povray can't handle extremely large
>differences in numbers which are generated by this scenario.
>
>I wish there were a program that can simultaneously handle:
>
>1) Large and small. A sphere as large as the sun (10^10m) and one 1mm across
>2) Near and Far. Simultaneously showing an object 1mm away from the camera
>and one 10^12m away.
>3) Small angles. Ideally, can see a 1mm object from 10^12 meters away.
>
>The biggest difference in magnitude I am asking for is 10^15. Since double
>precision numbers have 16 digits of precision, there should be no problem,

You might want to read the thread about "(X <= D) is not equal ((X<D) |
(X=D))" (starting with news:39017a7a@news.povray.org) in povray.general.

There are two problems with achieving this precision:

1) Povray uses an arbitrary EPSILON in checking for equality in a number
    of places. I suspect that its use in at least some places is
    unnecessary and makes the inherent numerical problems of floating
    point arithmetic worse instead of better. However, I haven't looked
    at the code in detail yet, and it has been 10 years that I took that
    "Numerical Data Processing" course, so I might be wrong.

2) In any case, being able to distinguish two numbers isn't enough for
   Povray.  They also have to stay distinct during computation. 

   For example, if you have a sphere at <0, 0, 0> with a radius of 1,
   and a point at <1, 0, 1E-10> it is clear to you that it is
   outside of the sphere. However, if you compute the distance from the
   center, it will will come out as 1.0, because the exact result
   (1+1E-20) is not representable in a double. I am quite sure I could
   also come up with an example where the point lies inside or outside
   the sphere depending on whether you compute the distance by


>but I have tried tweaking the various constants which affect this sort of
>thing to no avail. Tweaking constants is the current limit of my skills in
>Povray source.

If your compiler supports a "long double" type which is distinct from
double, you could try to change the definitions of DBL_FORMAT_STRING and
DBL in frame.h. You may also have to tweak some constants.

	hp

-- 
   _  | Peter J. Holzer    | Nicht an Tueren mangelt es,
|_|_) | Sysadmin WSR       | sondern an der Einrichtung (aka Content).
| |   | hjp### [at] wsracat      |    -- Ale### [at] univieacat
__/   | http://www.hjp.at/ |       zum Thema Portale in at.linux


Post a reply to this message

From: Ron Parker
Subject: Re: Request for Comment: AstroPov
Date: 1 May 2000 15:03:23
Message: <slrn8grm0b.7cf.ron.parker@linux.parkerr.fwi.com>
On Sun, 30 Apr 2000 19:48:36 +0200, Peter J. Holzer wrote:
>If your compiler supports a "long double" type which is distinct from
>double, you could try to change the definitions of DBL_FORMAT_STRING and
>DBL in frame.h. You may also have to tweak some constants.

I think you'll find that such things are better changed in config.h.


-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
These are my opinions.  I do NOT speak for the POV-Team.


Post a reply to this message

From: Peter J  Holzer
Subject: Re: Request for Comment: AstroPov
Date: 1 May 2000 22:04:37
Message: <slrn8gs806.vkt.hjp-usenet@teal.h.hjp.at>
On 1 May 2000 15:03:23 -0400, Ron Parker wrote:
>On Sun, 30 Apr 2000 19:48:36 +0200, Peter J. Holzer wrote:
>>If your compiler supports a "long double" type which is distinct from
>>double, you could try to change the definitions of DBL_FORMAT_STRING and
>>DBL in frame.h. You may also have to tweak some constants.
>
>I think you'll find that such things are better changed in config.h.

Yes, of course. I grepped in the wrong directory :-(

	hp

-- 
   _  | Peter J. Holzer    | Nicht an Tueren mangelt es,
|_|_) | Sysadmin WSR       | sondern an der Einrichtung (aka Content).
| |   | hjp### [at] wsracat      |    -- Ale### [at] univieacat
__/   | http://www.hjp.at/ |       zum Thema Portale in at.linux


Post a reply to this message

From: Alexander Enzmann
Subject: Re: Request for Comment: AstroPov
Date: 2 May 2000 09:20:38
Message: <390ED705.6689EDF4@mitre.org>
Chris Jeppesen wrote:
> 
> I like to do astronomical (space probes in the solar system) raytracing.
> Unfortunaltely, the current version of Povray can't handle extremely large
> differences in numbers which are generated by this scenario.
> 
> I wish there were a program that can simultaneously handle:
> 
> 1) Large and small. A sphere as large as the sun (10^10m) and one 1mm across

Java3D - can handle huge universes & small objects (or sets of objects)
with local coordinates based on the universal ones.


> 2) Near and Far. Simultaneously showing an object 1mm away from the camera
> and one 10^12m away.

Unless it's a really big object, all you need to do is color a single
pixel for the distant object.  On the practical side, with large
differences between foreground and background, you might be better off
building an image of the background and draping it behind the close
thing.


> 3) Small angles. Ideally, can see a 1mm object from 10^12 meters away.

At a certain point you should switch to orthogonal camera.  Not a heck
of a lot of difference between a <1 degree fov that is way off and
orthogonal.

> 
> The biggest difference in magnitude I am asking for is 10^15. Since double
> precision numbers have 16 digits of precision, there should be no problem,
> but I have tried tweaking the various constants which affect this sort of
> thing to no avail. Tweaking constants is the current limit of my skills in
> Povray source.

You will see all sorts of errors creep into your arithmetic if you
really have differences in magnitude that go right to the edge of what
can be represented by your numbers.  Each operation in a high quality
math library will only be good to within half of the bottom bit.  After
a few operations, you will see the error start to creep up to multiple
bits.

Xander


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.