  | 
  | 
 
 | 
  | 
 | 
  | 
 
 |   |  
 |   |  
 | 
  | 
 | 
  | 
 
 |   |  
 |   |  
 | 
  | 
Hi(gh)!
Meanwhile, I fixed mesh2writer.pov and placed the global flattening of 
the mesh2 object into povearth.pov... but now another problem showed up: 
the terrain texture is strangely distorted, as if in each line of 
vertices, one texture sample is omitted (see attachment).
The respective code in mesh2writer.pov:
// begin code
#if (!(tilename="n80e014" | tilename="n80e016" | tilename="n80e017")) // 
for elevation data tiles north of 80°N, no Blue Marble texture tiles are 
available!
   #declare i=0;
   #write (ES, "  texture_list")
   #write (ES, "  {\n")
   #write (ES, concat("    ",str(NumTextures, 1, 0),"\n"))
   #for (a, 0, ydim-1)
     #for (b, 0, xdim-1)
       #declare C_Texture = eval_pigment(P_Texture, 
<(0.5+b)*(1/(xdim-1)), (0.5+a)*(1/(ydim-1)), 0>);
       // #warning concat("Iteration ", str(a, 1, 0), "-", str(b, 1, 0))
       #write (ES, "    texture\n")
       #write (ES, "    {\n")
       #write (ES, "      pigment\n")
       #write (ES, "      {\n")
       #write (ES, concat("	   color rgb <",vstr(3, C_Texture, ",", 1, 
7),">\n"))
       #write (ES, "      }\n")
       #write (ES, "    }\n")
       // #declare c=c+1;
     #end
   #end
   #write (ES, "  }\n")
#end
// end code
I tried to replace xdim-1 and ydim-1 with xdim and ydim respectively, 
but then got the error message "missing }, texture found instead" - 
obviously, NumTextures is exceeded. But when I in fact use the full xdim 
and ydim values, shouldn't there be a black last column and row?
See you in Khyberspace!
Yadgar
 Post a reply to this message 
 
Attachments: 
Download 'tbilisi.png' (320 KB)
 
  
Preview of image 'tbilisi.png'
   
   
 | 
  | 
 
 |   |  
 |   |  
 | 
  | 
 | 
  | 
 
 |   |  
 |   |  
 | 
  | 
hi,
=?UTF-8?Q?J=c3=b6rg_=22Yadgar=22_Bleimann?= <yaz### [at] gmx de> wrote:
> Hi(gh)!
>
> Meanwhile, I fixed mesh2writer.pov and placed the global flattening of
> the mesh2 object into povearth.pov... but now another problem showed up:
> the terrain texture is strangely distorted, as if in each line of
> vertices, one texture sample is omitted (see attachment).
out of interest, what does 'P_Texture' look like?
> ...  But when I in fact use the full xdim
> and ydim values, shouldn't there be a black last column and row?
that would be my expectation too.  the code looks kosher, have you tried with
same code but different data tile/set?
regards, jr.
 
 Post a reply to this message 
 | 
  | 
 
 |   |  
 |   |  
 | 
  | 
 | 
  | 
 
 |   |  
 |   |  
 | 
  | 
"jr" <cre### [at] gmail com> wrote:
> ...
> that would be my expectation too.  the code looks kosher, have you tried with
> same code but different data tile/set?
actually, belay that.  :-)  sorry, noise, etc..
the increments where you make the vector for 'eval_pigment', pretty sure you'll
want '<(.5+b)*(1/xdim), (.5+a)*(1/ydim),0>'.
regards, jr.
 
 Post a reply to this message 
 | 
  | 
 
 |   |  
 |   |  
 | 
  | 
From: Jörg "Yadgar" Bleimann 
Subject: Re: POVEarth: Distorted Terrain Texture 
Date: 13 Aug 2020 18:29:49 
Message: <5f35bedd$1@news.povray.org> 
 | 
 
 
 | 
  | 
 
 |   |  
 |   |  
 | 
  | 
Hi(gh)!
On 13.08.20 21:03, jr wrote:
> "jr" <cre### [at] gmail com> wrote:
>> ...
>> that would be my expectation too.  the code looks kosher, have you tried with
>> same code but different data tile/set?
> 
> actually, belay that.  :-)  sorry, noise, etc..
> 
> the increments where you make the vector for 'eval_pigment', pretty sure you'll
> want '<(.5+b)*(1/xdim), (.5+a)*(1/ydim),0>'.
As the data tile is square, xdim = ydim! Of course you're right, if I 
ever wanted to render a non-square data set, it's better to have the two 
variables assigned to the proper dimensions.
See you in Khyberspace!
Yadgar
 
 Post a reply to this message 
 | 
  | 
 
 |   |  
 |   |  
 | 
  | 
From: Jörg "Yadgar" Bleimann 
Subject: Re: POVEarth: Distorted Terrain Texture 
Date: 13 Aug 2020 18:50:33 
Message: <5f35c3b9@news.povray.org> 
 | 
 
 
 | 
  | 
 
 |   |  
 |   |  
 | 
  | 
Hi(gh)!
On 13.08.20 20:55, jr wrote:
> out of interest, what does 'P_Texture' look like?
See first attachment!
> 
>> ...  But when I in fact use the full xdim
>> and ydim values, shouldn't there be a black last column and row?
> 
> that would be my expectation too.  the code looks kosher, have you tried with
> same code but different data tile/set?
No, I didn't... but meanwhile, I experimented with various values for 
the loop and NumTextures, finally ended up with xdim-2 respectively 
ydim-2, which is (xdim-1)*(ydim-1) for NumTextures, which did the trick 
(see second attachment)!
See you in Khyberspace!
Yadgar
 
 Post a reply to this message 
 
Attachments: 
Download 'n41e044_2004-07.png' (74 KB)
Download '2020-08-14 tbilisi area, take 4 - overview from 200 kms altitude.jpg' (42 KB)
 
  
Preview of image 'n41e044_2004-07.png'
   
Preview of image '2020-08-14 tbilisi area, take 4 - overview from 200 kms altitude.jpg'
   
   
 | 
  | 
 
 |   |  
 |   |  
 | 
  | 
From: Alain Martel 
Subject: Re: POVEarth: Distorted Terrain Texture 
Date: 13 Aug 2020 20:50:52 
Message: <5f35dfec@news.povray.org> 
 | 
 
 
 | 
  | 
 
 |   |  
 |   |  
 | 
  | 
Le 2020-08-13 à 11:43, Jörg "Yadgar" Bleimann a écrit :
> Hi(gh)!
> 
> Meanwhile, I fixed mesh2writer.pov and placed the global flattening of 
> the mesh2 object into povearth.pov... but now another problem showed up: 
> the terrain texture is strangely distorted, as if in each line of 
> vertices, one texture sample is omitted (see attachment).
> 
> The respective code in mesh2writer.pov:
> 
> // begin code
> 
> #if (!(tilename="n80e014" | tilename="n80e016" | tilename="n80e017")) // 
> for elevation data tiles north of 80°N, no Blue Marble texture tiles are 
> available!
>    #declare i=0;
>    #write (ES, "  texture_list")
>    #write (ES, "  {\n")
>    #write (ES, concat("    ",str(NumTextures, 1, 0),"\n"))
>    #for (a, 0, ydim-1)
> 
>      #for (b, 0, xdim-1)
>        #declare C_Texture = eval_pigment(P_Texture, 
> <(0.5+b)*(1/(xdim-1)), (0.5+a)*(1/(ydim-1)), 0>);
>        // #warning concat("Iteration ", str(a, 1, 0), "-", str(b, 1, 0))
>        #write (ES, "    texture\n")
>        #write (ES, "    {\n")
>        #write (ES, "      pigment\n")
>        #write (ES, "      {\n")
>        #write (ES, concat("       color rgb <",vstr(3, C_Texture, ",", 
> 1, 7),">\n"))
>        #write (ES, "      }\n")
>        #write (ES, "    }\n")
>        // #declare c=c+1;
>      #end
>    #end
>    #write (ES, "  }\n")
> #end
> 
> // end code
> 
> I tried to replace xdim-1 and ydim-1 with xdim and ydim respectively, 
> but then got the error message "missing }, texture found instead" - 
> obviously, NumTextures is exceeded. But when I in fact use the full xdim 
> and ydim values, shouldn't there be a black last column and row?
> 
> See you in Khyberspace!
> 
> Yadgar
Looks like one image was taken late summer during a drought and the 
other in late rainy spring.
 Post a reply to this message 
 | 
  | 
 
 |   |  
 |   |  
 | 
  | 
 | 
  | 
 
 |   |  
 |   |  
 | 
  | 
hi,
=?UTF-8?Q?J=c3=b6rg_=22Yadgar=22_Bleimann?= <yaz### [at] gmx de> wrote:
> On 13.08.20 21:03, jr wrote:
> > "jr" <cre### [at] gmail com> wrote:
> >> ...
> > the increments where you make the vector for 'eval_pigment', pretty sure you'll
> > want '<(.5+b)*(1/xdim), (.5+a)*(1/ydim),0>'.
>
> As the data tile is square, xdim = ydim! Of course you're right, if I
> ever wanted to render a non-square data set, it's better to have the two
> variables assigned to the proper dimensions.
re square vs non-square -- if you use the method suggested by BE, ie using
'max_extent' to obtain '[xy]dim', you never need to know, nor care.
re code -- I think that you will see improved performance if you, again, follow
the advice given by BE regarding pre-calculating what you can.  so '[xy]dim' are
constant, for that bit of code, and not calculating both in the inner loop
removes two (relatively) expensive (division) operations; furthermore, file
system operations too are expensive, so consolidating the '#write's should make
a noticeable difference.  suggest bracket yr existing code with '#declare before
= now;' and '#declare after = now;' and run two or three times to get the number
of seconds, then replace yr code with the below, and compare.  I'd be v
interested to find out what savings that makes for the large kind of image
you're playing with.
   #declare i=0;
   #write (ES, "  texture_list")
   #write (ES, "  {\n")
   #write (ES, concat("    ",str(NumTextures, 1, 0),"\n"))
   #declare xincr = 1 / xdim;
   #declare yincr = 1 / ydim;
   #declare before = now;
   #for (a, 0, ydim-1)
     #for (b, 0, xdim-1)
       #declare C_Texture = eval_pigment(P_Texture,
<(.5+b)*xincr,(0.5+a)*yincr,0>);
       #write (ES, concat("    texture\n",
                          "    {\n",
                          "      pigment\n",
                          "      {\n",
                          "        color rgb <",
                          vstr(3, C_Texture, ",", 1, 7),
                          ">\n",
                          "      }\n",
                          "    }\n"))
     #end
   #end
   #write (ES, "  }\n")
   #declare after = now;
regards, jr.
 
 Post a reply to this message 
 | 
  | 
 
 |   |  
 |   |  
 | 
  | 
 | 
  | 
 
 |   |  
 
 | 
  |