Hi(gh)!

Am 29.12.2017 um 00:54 schrieb dick balaska:
> On 12/28/2017 06:10 AM, Jörg 'Yadgar' Bleimann wrote:
> 
>> I forgot to mention that I use either Windows XP Professional 
>> (32-bit), Windows 7 64-bit Professional or Debian Linux 8.9, 
> 
> I wondered if there were povers still using 32 bits.

Windows XP only on my slow ancient 512 MiB laptop...

See you in Khyberspace!

Yadgar

Post a reply to this message

Hi(gh)!

Am 29.12.2017 um 08:51 schrieb Thomas de Groot:

> You are welcome Yadgar. Glad to be of help. I hope you will find what 
> you want. If there is something fundamental that I have learned since I 
> started modelling (with POV-Ray of course!) back in the nineties, it is 
> that for each scale you often need a different tool/procedure. It is 
> almost impossible to use the same output for a planetary view /and/ for 
> a landscape. Both need different approaches.

Not necessarily... at least when it comes down to heightfields. Of 
course, for an Earth-sized planet with a circumference of about 40,000 
kms, a decent looking heightfield without needing vertical exaggeration 
should be at least 400,000 by 200,000 pixels, the larger the better - 
but this full size is mostly not needed, as it is only worthwile at 
"pedestrian views" - and then you need only a tiny fraction of the whole 
planetary surface. Which leads me to the next question: Does POV-Ray's 
eval_pigment() also handle 16-bit grayscale pngs correctly?

See you in Khyberspace!

Yadgar

Post a reply to this message

On 29-12-2017 9:42, Jörg 'Yadgar' Bleimann wrote:
> Hi(gh)!
> 
> Am 29.12.2017 um 08:51 schrieb Thomas de Groot:
> 
>> You are welcome Yadgar. Glad to be of help. I hope you will find what 
>> you want. If there is something fundamental that I have learned since 
>> I started modelling (with POV-Ray of course!) back in the nineties, it 
>> is that for each scale you often need a different tool/procedure. It 
>> is almost impossible to use the same output for a planetary view /and/ 
>> for a landscape. Both need different approaches.
> 
> Not necessarily... at least when it comes down to heightfields. Of 
> course, for an Earth-sized planet with a circumference of about 40,000 
> kms, a decent looking heightfield without needing vertical exaggeration 
> should be at least 400,000 by 200,000 pixels, the larger the better - 
> but this full size is mostly not needed, as it is only worthwile at 
> "pedestrian views" - and then you need only a tiny fraction of the whole 
> planetary surface. Which leads me to the next question: Does POV-Ray's 
> eval_pigment() also handle 16-bit grayscale pngs correctly?
> 

I don't know about eval_pigment. Somebody else might be more knowledgeable.

I tend to disagree with you about those height_fields. A planetary 
height_field used for a 'pedestrian' view will show horrible jaggies 
imho. Or you will need insane resolution values if you are using functions.

-- 
Thomas

Post a reply to this message

Am 29.12.2017 um 09:42 schrieb Jörg 'Yadgar' Bleimann:

> Which leads me to the next question: Does POV-Ray's
> eval_pigment() also handle 16-bit grayscale pngs correctly?

Absolutely. Everything you can use in a pigment, eval_pigment() will
handle correctly - for technically feasible definitions of "correctly".

Beware however the gamma monster. When using images as terrain elevation
maps, you'll typically want linear values. Ideally, the generating
software should use linear encoding and set the `gAMA` chunk
accordingly, but not all software is that well-behaved. To be on the
safe side, specify "gamma 1" in the image map. (Unless the generating
software uses non-linear encoding.)

(When using images in genuine height fields or bump maps, "gamma 1" is
the default. But for eval_pigment() you'll need to load the image as a
pigment first, in which case POV-Ray defaults to whatever gamma is
indicated in the PNG file, or sRGB if the file doesn't contain gamma
information.)

Post a reply to this message

On 29/12/2017 08:42, Jörg 'Yadgar' Bleimann wrote:
> Hi(gh)!
> 
> Am 29.12.2017 um 08:51 schrieb Thomas de Groot:
> 
>> You are welcome Yadgar. Glad to be of help. I hope you will find what 
>> you want. If there is something fundamental that I have learned since 
>> I started modelling (with POV-Ray of course!) back in the nineties, it 
>> is that for each scale you often need a different tool/procedure. It 
>> is almost impossible to use the same output for a planetary view /and/ 
>> for a landscape. Both need different approaches.
> 
> Not necessarily... at least when it comes down to heightfields. Of 
> course, for an Earth-sized planet with a circumference of about 40,000 
> kms, a decent looking heightfield without needing vertical exaggeration 
> should be at least 400,000 by 200,000 pixels, the larger the better - 
> but this full size is mostly not needed, as it is only worthwile at 
> "pedestrian views" - and then you need only a tiny fraction of the whole 
> planetary surface. Which leads me to the next question: Does POV-Ray's 
> eval_pigment() also handle 16-bit grayscale pngs correctly?
> 

I agree with Thomas. The difference in scales between domestic and 
geographical is too great for the resolution of heightfields.
But the link below might help. It is Gilles Tran's Spherical height field.

http://www.oyonale.com/modeles.php?lang=en&page=24


-- 

Regards
     Stephen

Post a reply to this message

Stephen <mca### [at] aolcom> wrote:
> On 28/12/2017 09:19, clipka wrote:
> >
> > "new WinXP"???
> >
> > Ouch.
> >
>
> Some people keep things that work.
> Going from Leroy's site. It was new in 2006
>

I wish I still had mine. :-(  It was ... STABLE. And a workhorse. But the stupid
crummy power supply eventually fried the motherboard. (an Emachines computer,
BTW.)

Post a reply to this message

Hi(gh)!

Am 29.12.2017 um 16:42 schrieb clipka:
> 
> Absolutely. Everything you can use in a pigment, eval_pigment() will
> handle correctly - for technically feasible definitions of "correctly".

Obviously not, at least not with POV-Ray for Windows... I used a 16-bit 
PNG generated with Wilbur to be parsed to a spherical mesh2 with this 
script:

// beginning of code

#include "functions.inc"

#declare xx=1024;
#declare yy=512;
#declare minrad=22;
#declare maxrad=38;


#declare AsteroidRelief =
pigment
{
   image_map { tga "asteroid1.tga" }
}

#declare vertices=2+xx*(yy-2);

#fopen asteroid_mesh_inc "asteroid_mesh.inc" write
#write (asteroid_mesh_inc,
         "#declare asteroid_mesh =\n
         mesh2\n
         {\n
           vertex_vectors\n
           {\n",
             vertices,"\n",
             <0, -35.678431, 0>," // south pole \n") // number of 
vertices: 2+b*(a-2) [2+xx*(yy-2)]
#declare a=1;
#while (a<yy-1)
   #declare b=0;
   // #declare rdcum = 0;
   #while (b<xx)
     #declare redval=eval_pigment(AsteroidRelief, <(0.5+b)*(1/xx), 
(0.5+a)*(1/yy), 0>).red * (maxrad-minrad);
     #declare greenval=eval_pigment(AsteroidRelief, <(0.5+b)*(1/xx), 
(0.5+a)*(1/yy), 0>).green * ((maxrad-minrad)/255);
     #declare rd=minrad+redval+greenval;
     /* #if (a=1 | a=yy-2)
       #declare rdcum=rdcum+rd;
     #end */
     #write (asteroid_mesh_inc,
 
(rd*<sin(radians(b*(360/xx)))*cos(radians(-90+a*(180/(yy-2)))), 
sin(radians(-90+a*(180/(yy-2)))), 
cos(radians(b*(360/xx)))*cos(radians(-90+a*(180/(yy-2))))>)," // ",rd,"\n")
     #declare b=b+1;
   #end
   #declare a=a+1;
#end

#write (asteroid_mesh_inc, <0, 35.741176, 0>,"// north pole\n
                         }\n
                         face_indices\n
                         {\n",
                            xx*2+xx*2*(yy-3),"\n") // number of faces: 
b*2+b*2*(a-3) [xx*2+xx*2*(yy-3)]
#declare a=0;
#while (a<yy-1)
   #declare b=0;
   #while (b<xx)
     #switch (a)
       #case (0)
         #if (b < xx-1)
           #write (asteroid_mesh_inc, <0, a+1+b, a+1+mod(b+1,xx)>, "\n") 
// b faces, all sharing first vertex (#0)
         #else
           #write (asteroid_mesh_inc, <0, a+1+b, 1>, "\n" // last 
triangle connecting to first one
         #end
       #break
       #range (1, yy-3)
         #if (b < xx-1)
           #write (asteroid_mesh_inc, <1+(a-1)*xx+b, 
1+(a-1)*xx+mod(b+1,xx), 1+a*xx+b>,",",<1+a*xx+b, 1+a*xx+mod(b+1,xx), 
1+(a-1)*xx+mod(b+1,xx)>, "\n") // b*2*(a-3) faces
         #else
           #write (asteroid_mesh_inc, <1+(a-1)*xx+b, 1+(a-1)*xx, 
1+a*xx+b>,",",<1+a*xx+b, 1+(a-1)*xx, 1+a*xx>, "\n") // last pair of 
triangles in row connecting to first pair
         #end
       #break
       #case (yy-2)
         #if (b < xx-1)
           #write (asteroid_mesh_inc,  <1+(a-1)*xx+b, 
1+(a-1)*xx+mod(b+1,xx), vertices-1>) // b faces, all sharing last vertex
         #else
           #write (asteroid_mesh_inc,  <1+(a-1)*xx+b, 1+(a-1)*xx, 
vertices-1> // last triangle connecting to first one
         #end
       #break
     #end
     #declare b=b+1;
   #end
   #declare a=a+1;
#end
#write (asteroid_mesh_inc, "  }\n}")

#fclose asteroid_mesh_inc

// end of code

It seemed to parse correctly - but POV-Ray crashed immediately 
afterwards, regardless how big or small values I used for xx and yy. I 
didn't try yet whether it still produced a valid mesh2 - but I don't 
think so.

See you in Khyberspace!

Yadgar

Post a reply to this message

Am 30.12.2017 um 02:21 schrieb Jörg 'Yadgar' Bleimann:
>> Absolutely. Everything you can use in a pigment, eval_pigment() will
>> handle correctly - for technically feasible definitions of "correctly".
> 
> Obviously not, at least not with POV-Ray for Windows... I used a 16-bit
> PNG generated with Wilbur to be parsed to a spherical mesh2 with this
> script:

https://youtu.be/tc2tDFPlyWY?t=1h51m5s

/Some/ day I'll teach you folks to specify the version number when
reporting an issue ;)

> It seemed to parse correctly - but POV-Ray crashed immediately
> afterwards, regardless how big or small values I used for xx and yy. I
> didn't try yet whether it still produced a valid mesh2 - but I don't
> think so.

If the scene parses, it's not an issue with `eval_pigment()`, as that's
called during parsing. Rather, the /scene/ created must have some
problematic properties.

Also, that's a TGA file you're using there, not PNG ;)

To further diagnose the issue, I'd probably need a copy of the image.

Post a reply to this message

On 30/12/2017 12:35, clipka wrote:
> https://youtu.be/tc2tDFPlyWY?t=1h51m5s
> 
> /Some/  day I'll teach you folks to specify the version number when
> reporting an issue;)


That's a bit subtle, for us.
Just say what you mean before we grow beards. ;)

-- 

Regards
     Stephen

Post a reply to this message

Le 17-12-30 à 11:00, Stephen a écrit :
> On 30/12/2017 12:35, clipka wrote:
>> https://youtu.be/tc2tDFPlyWY?t=1h51m5s
>>
>> /Some/  day I'll teach you folks to specify the version number when
>> reporting an issue;)
> 
> 
> That's a bit subtle, for us.
> Just say what you mean before we grow beards. ;)
> 

If you don't provide the version number, there is no way to know if the 
issue is an old one, maybe already fixed in later version, or a new one 
accidentally introduced.

Where you using version 3.5, 3.6, 3.7, the latest test build...?

Post a reply to this message