High!

Once more with my long-cherished Solar System project... originally I 
equalled 1 POV unit = 1 km - which pretty soon turned out to be 
unfeasible, as the Sun is several times farther even from Mercury than 
PoV-Ray's epsilon value would allow it to be rendered correctly, let 
alone the other celestial bodies in the Solar System.

So I introduced a scale value, based on the aphelion (furthest point of 
orbit from the Sun) of trans-Kuiper Belt object Sedna, and adjusted it 
dynamically to the distance between camera and the Sun (or any other body):

#declare AU=149597870.691; // 1 Astronomical Unit in kilometres

#declare scconst=14596; // scaling constant, found by manual approximation

#declare objdist=975.56*AU; // Sedna's aphelion
#declare camdist=10000;     // Camera distance from Sedna

#declare sc=scconst*(objdist/(975.56*AU)); // scale factor adjusted to 
camera-sun (or camera-other body) distance

light_source // Sun
{
   0/sc
   color rgb 1
   looks_like
   {
     sphere
     {
       0/sc, 695000/sc
       texture
       {
        pigment { color rgb 1 }
        finish { ambient 1 diffuse 0 }
       }
     }
   }
}

sphere // Sedna dummy for lighting test
{
   <0, 0, -objdist>/sc, 1800/sc
   texture
   {
     pigment
     {
       color rgb <0.5, 0.35, 0.2>
     }
     finish { ambient 0 diffuse 1 brilliance 0.4 }
   }
}
camera
{
   location <-camdist, 0, -objdist>/sc
   look_at <0, 0, -objdist>/sc
   angle 40
}

Works fine... as long as I adjust the scale value according to Sedna's 
distance to the Sun rather than to the camera-Sedna distance. If I try 
the latter (i. e. insert 10000 instead of 975.56*AU, which is about 14 
billions), the illuminated half of the Sedna dummy sphere appears 
terribly grainy!

Just keeping 975.56*AU (objdist) as scaling parameter, Sedna (about 1800 
kms in diameter) would be a mere 0.12 units large, making structures 
several orders of magnitude smaller (such as colonies, spaceships, local 
terrain features) impossible to model.

Is there a way to avoid this without changing the position of the light 
source? I understand that I'll have to fake the visible disk of the sun 
(probably by using a sky_sphere with a multi-layered object pattern 
pigment), but to have a realistic illumination geometry, it would be 
nice to have the actual origin of the light cosistent with the chosen 
scale...

See you on www.khyberspace.de!

Yadgar

Post a reply to this message

> Works fine... as long as I adjust the scale value according to Sedna's 
> distance to the Sun rather than to the camera-Sedna distance. If I try 
> the latter (i. e. insert 10000 instead of 975.56*AU, which is about 14 
> billions), the illuminated half of the Sedna dummy sphere appears 
> terribly grainy!

  This is most probably just a limitation with 64-bit floating point
values. (Less probably a bug.)
  If that is indeed the reason, then there's little one can do about it.

-- 
                                                          - Warp

Post a reply to this message

Warp escribió:
>   If that is indeed the reason, then there's little one can do about it.

...other than heavily modifying POV-Ray to use arbitrary precision 
floating-point numbers, like with the MPFR library. Would be slow as 
hell though :)

Post a reply to this message

Nicolas Alvarez escribió:
> Warp escribió:
>>   If that is indeed the reason, then there's little one can do about it.
> 
> ...other than heavily modifying POV-Ray to use arbitrary precision 
> floating-point numbers, like with the MPFR library. Would be slow as 
> hell though :)

Hmm... Looks like there are some C++ wrappers around MPFR that would 
make it quite simpler. And when I say simpler, I mean that in many 
cases, replacing 'double' with 'mpfr_class' would be all (who said 
operator overloading was bad?)

Post a reply to this message

news:47e7f1fc$1@news.povray.org...
> High!
>
> Once more with my long-cherished Solar System project... originally I 
> equalled 1 POV unit = 1 km - which pretty soon turned out to be 
> unfeasible, as the Sun is several times farther even from Mercury than 
> PoV-Ray's epsilon value would allow it to be rendered correctly, let alone 
> the other celestial bodies in the Solar System.
>
> So I introduced a scale value, based on the aphelion (furthest point of 
> orbit from the Sun) of trans-Kuiper Belt object Sedna, and adjusted it 
> dynamically to the distance between camera and the Sun (or any other 
> body):
>

I hope future versions of Pov-Ray will fix this problem. A lot of Povers 
love doing astronomical stuff =)


-- 
-Nekar Xenos-

Post a reply to this message

Nekar Xenos wrote:

> news:47e7f1fc$1@news.povray.org...
>> High!
>>
>> Once more with my long-cherished Solar System project... originally I 
>> equalled 1 POV unit = 1 km - which pretty soon turned out to be 
>> unfeasible, as the Sun is several times farther even from Mercury than 
>> PoV-Ray's epsilon value would allow it to be rendered correctly, let alone 
>> the other celestial bodies in the Solar System.
>>
>> So I introduced a scale value, based on the aphelion (furthest point of 
>> orbit from the Sun) of trans-Kuiper Belt object Sedna, and adjusted it 
>> dynamically to the distance between camera and the Sun (or any other 
>> body):
>>
> 
> I hope future versions of Pov-Ray will fix this problem. A lot of Povers 
> love doing astronomical stuff =)

This is not a POV-Ray problem, it is a hardware limitation as has been 
explained countless of times over the decades...

	Thorsten

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> Hmm... Looks like there are some C++ wrappers around MPFR that would 
> make it quite simpler. And when I say simpler, I mean that in many 
> cases, replacing 'double' with 'mpfr_class' would be all (who said 
> operator overloading was bad?)

  There may be wrappers, but are they efficient?

  For such a wrapper to be efficient it would require its own allocator
(afaik. with most unlimited floating point libraries initializing a
floating point value is a heavy operation, so it is recommended to
reuse already-initialized values which are no longer used whenever possible
instead of always initializing new ones) and some type of copy-on-write
mechanism or such (to avoid the huge overhead related to copying/assignment
which would otherwise exist).

-- 
                                                          - Warp

Post a reply to this message

Nekar Xenos <nek### [at] gmailcom> wrote:
> I hope future versions of Pov-Ray will fix this problem.

  It will only happen when hardware starts supporting floating point
numbers larger than 64 bits.

  (Well, strictly speaking x87 supports 80-bit floating point numbers,
but that isn't usually of much help.)

-- 
                                                          - Warp

Post a reply to this message

I do astronomical renders all the time (well I am an astronomy lecturer!)... 
I simply choose a better base unit... Megametres, Gigametres or even AUs 
instead of kilometres.

1 AU = 149597870.691km
        = 149597.870691Mm
        = 149.597870691Gm

Even Sedna's orbit is now only 75-975 AU or 11219.7-145857Gm... The only 
slight problem there is that Sedna is only 0.0015Gm across!

One of these days I'm going to finish my SolarSystem toolkit include file!

Rarius

"Nekar Xenos" <nek### [at] gmailcom> wrote in message 
news:47e8ce0b@news.povray.org...
>

> news:47e7f1fc$1@news.povray.org...
>> High!
>>
>> Once more with my long-cherished Solar System project... originally I 
>> equalled 1 POV unit = 1 km - which pretty soon turned out to be 
>> unfeasible, as the Sun is several times farther even from Mercury than 
>> PoV-Ray's epsilon value would allow it to be rendered correctly, let 
>> alone the other celestial bodies in the Solar System.
>>
>> So I introduced a scale value, based on the aphelion (furthest point of 
>> orbit from the Sun) of trans-Kuiper Belt object Sedna, and adjusted it 
>> dynamically to the distance between camera and the Sun (or any other 
>> body):
>>
>
> I hope future versions of Pov-Ray will fix this problem. A lot of Povers 
> love doing astronomical stuff =)
>
>
> -- 
> -Nekar Xenos-
>

Post a reply to this message

If you're going to be combining nearby objects (such as a spaceship) and 
astronomical objects (such as Sedna) in the same scene, you may need to 
break the scaling.

You can split the scene into things that are nearby and things that are 
far away. Then you can use the fact that an object of diameter 1800km at 
a distance of 145900000000km looks almost exactly the same as an object 
of diameter 1.8m at a distance of 145900km. So dividing the distances 
and sizes of all the far away objects by a million makes no difference 
to the render.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message