POV-Ray : Newsgroups : povray.binaries.images : Spherical displacement map : Re: Spherical displacement map Server Time
1 May 2024 18:21:02 EDT (-0400)
  Re: Spherical displacement map  
From: Le Forgeron
Date: 21 Jul 2020 08:14:33
Message: <5f16dc29@news.povray.org>
Le 21/07/2020 à 12:58, Bald Eagle a écrit :
> Le_Forgeron <jgr### [at] freefr> wrote:
> 
>> acos( min( y / length, 1) ) : the clipping is done for the north pole,
>> but not the south pole (-1)
>>
>> what about "acos(max(min(y/length, 1),-1)) ?
> 
> Thanks Jerome, it was a good suggestion, but the hole is still there.
> 
> I'm also concerned that although I may happen upon a "solution" that looks nice
> graphically, it will be numerically wrong.  And that's because I'm going to be
> using these calculations to "look up" the altitude on the rectangular elevation
> map in order to construct planet tiles that are in the right position (as
> closely as possible using this method and the data available).
> 
> I'm also curious as to why I got I got a core dump with no clipping, and no core
> dump with half-clipping, if the domain input was the underlying issue.  Because
> without the min(), then I'd be running into the same problem that I was
> imagining was happening, only with the opposite sign.
> 
> And I'm not even sure that the domain was out range now that we're back into
> this again.  (it's early, before coffee, and it's HOT)
> (I mean, can y ever exceed the vector length to give a quotient exceeding
> unity?)
> I DO have my isosurface contained by a sphere instead of a box - maybe that has
> something to do with it - I will check later this afternoon.
> 
> I really do have a knack for finding these little hidden problems...
> 
> 
For playing with geodesique coordinates in another life, my
recommendation is that you should avoid acos formula, as for position
near the pole the precision is about 1-x²/2, which means you are getting
compression of detail at the pole so strong that you cannot tell apart
two poins that are 100 m aways.

When distance between two points is to be computed, there is a
preference for the haversine formula instead of basic acos.

For your computation of latitude, you can use the complemented angle and
asin instead, then complement the result, using the sign of y as final
update.

The loss of precision near 0 is far "better" than the loss of precision
near 1, due to representation of floating point numbers.

#declare Latitude = pi/2 - asin( sqrt( x*x+z*z)/sqrt(x*x+y*y+z*z) );
#if (y<0)
#declare Latitude = -1 * Latitude;
#end


Post a reply to this message

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