High!

Resuming my long-cherished Khyberspace project, I once more started downloading
SRTM radar elevation data tiles and converting them into PNG 16-bit
heightfields.
For performance reasons, I pre-created the huge mesh2 code to be read in by the
scene script proper (as the mesh2 code is some 120 MB large, I just included
here the PNG heightfield and the mesh2writer script rather than the mesh2
itself).

When I render the scene, two problems occur:

First, between most of the mesh2 triangles, ugly black gaps show up (see
attached image file - no, it's NOT a anti-aliasing issue, the very scene you see
was rendered using +a0.3!). I remember that problem from back in 2005, when I
also tried a Khyberspace scene from SRTM data, and back then, I was told by Mike
Williams (if my notes are right) that it has got something to do with floating
point accuracy. So I got the suggestion to define each vertex of the mesh2 as
close to the origin as possible and then to re-translate the whole mesh.

But when I looked up the old script from 2005, I found that the I wrote back
then was a true Heath Robinson contraption, much too complicated to make use of
it now, so I did not implement Mike William's solution up to now.

The second problem is that whenever I give Earth rotation angles other than 0
(or include the axial tilt), the mesh2 is rotated "out of sight" for the trace()
vector to place the camera on the surface - though in the definition of the
mesh2, all vertices are defined with respect to the origin (as you might look up
in mesh2writer.pov)! So when I try to render such a scene, I just get empty
black space...

Any suggestion how to fix that?

See you in Khyberspace!

Yadgar

Post a reply to this message

Attachments:
Download '2010-11-20 afghan highlands south of koh-e baba range, take 1.jpg' (42 KB)

Preview of image '2010-11-20 afghan highlands south of koh-e baba range, take 1.jpg'

> High!
>
> Resuming my long-cherished Khyberspace project, I once more started downloading
> SRTM radar elevation data tiles and converting them into PNG 16-bit
> heightfields.
> For performance reasons, I pre-created the huge mesh2 code to be read in by the
> scene script proper (as the mesh2 code is some 120 MB large, I just included
> here the PNG heightfield and the mesh2writer script rather than the mesh2
> itself).
>
> When I render the scene, two problems occur:
>
> First, between most of the mesh2 triangles, ugly black gaps show up (see
> attached image file - no, it's NOT a anti-aliasing issue, the very scene you see
> was rendered using +a0.3!). I remember that problem from back in 2005, when I
> also tried a Khyberspace scene from SRTM data, and back then, I was told by Mike
> Williams (if my notes are right) that it has got something to do with floating
> point accuracy. So I got the suggestion to define each vertex of the mesh2 as
> close to the origin as possible and then to re-translate the whole mesh.
>
> But when I looked up the old script from 2005, I found that the I wrote back
> then was a true Heath Robinson contraption, much too complicated to make use of
> it now, so I did not implement Mike William's solution up to now.
>
> The second problem is that whenever I give Earth rotation angles other than 0
> (or include the axial tilt), the mesh2 is rotated "out of sight" for the trace()
> vector to place the camera on the surface - though in the definition of the
> mesh2, all vertices are defined with respect to the origin (as you might look up
> in mesh2writer.pov)! So when I try to render such a scene, I just get empty
> black space...
>
> Any suggestion how to fix that?
>
> See you in Khyberspace!
>
> Yadgar
>
>

Did you try applying the rotations before translating to the final location?
If you translate then rotate, the mesh will orbit around the origin.
You may also use min_extent() and max_extent() to locate the final 
location of the mesh and trace accordingly.


Alain

Post a reply to this message

"Alain" <aze### [at] qwertyorg> schrieb im Newsbeitrag 
news:4ce824bc@news.povray.org...


> Did you try applying the rotations before translating to the final 
> location?

Yes, I did - see here:

#declare Earth_Slice=
object
{
  Earth_Slice_N34E067
  texture
  {
    pigment { color rgb <1, 0.9, 0.4> }
    finish { ambient 0.1 diffuse 1 brilliance 0.4 }
  }
  rotate <0, -Earth_Rot, 0>
  translate Earth_Pos
  // rotate <Earth_Tilt, 0, 0>
}

...and the original mesh2 definition does not contain any rotate statement 
at all!

See you in Khyberspace!

Post a reply to this message

> "Alain"<aze### [at] qwertyorg>  schrieb im Newsbeitrag
> news:4ce824bc@news.povray.org...

>
>> Did you try applying the rotations before translating to the final
>> location?
>
> Yes, I did - see here:
>
> #declare Earth_Slice=
> object
> {
>    Earth_Slice_N34E067
>    texture
>    {
>      pigment { color rgb<1, 0.9, 0.4>  }
>      finish { ambient 0.1 diffuse 1 brilliance 0.4 }
>    }
>    rotate<0, -Earth_Rot, 0>
>    translate Earth_Pos
>    // rotate<Earth_Tilt, 0, 0>
> }
>
> ...and the original mesh2 definition does not contain any rotate statement
> at all!
>
> See you in Khyberspace!
>
>

Then, you need to use min_extent() and max_extent() to locate the actual 
bounding box of the mesh and trace to somewhere into that bounding box.



Alain

Post a reply to this message