High!

A recent thread on p.b.i. drew my attention to http://www.buining.com - 
those 16-bit PNG elevation maps of Earth, the Moon and Mars look 
tempting! But AFAIK PoV-Ray's height_field functionality can't handle 
grayscale 16-bit PNGs... are there any tool for conversion into 16-bit 
heightfield TGAs available? Or at least into ordinary uncompressed 
32-bit TGAs, so I could write a converting routine on my own... perhaps 
I should take a closer look at the latest version of IrfanView?

See you on www.khyberspace.de!

Yadgar

Now playing: Solid Rock (Dire Straits)

Post a reply to this message

> A recent thread on p.b.i. drew my attention to http://www.buining.com - 
> those 16-bit PNG elevation maps of Earth, the Moon and Mars look 
> tempting! But AFAIK PoV-Ray's height_field functionality can't handle 
> grayscale 16-bit PNGs... are there any tool for conversion into 16-bit 
> heightfield TGAs available? 

I think this should work:

global_settings{hf_gray_16}

plane{z,0
  texture{
   pigment{
    image_map{png "your_file_here" interpolate 2}
    translate -.5
    scale 2.1
   }
   scale <-1,1,1>
   finish{brilliance 0 ambient 1}
  }
}

camera{
  orthographic
  location <0,0,-1>
  up 1*y right 1*y
  angle 90
  look_at 0
}

--
Jaime

Post a reply to this message

> A recent thread on p.b.i. drew my attention to http://www.buining.com - 
> those 16-bit PNG elevation maps of Earth, the Moon and Mars look 
> tempting! But AFAIK PoV-Ray's height_field functionality can't handle 
> grayscale 16-bit PNGs...

It should work. From the documentation of height fields:

"PNG format heightfields are usually stored in the form of a grayscale 
image with black corresponding to lower and white to higher parts of the 
height field. Because PNG files can store up to 16 bits in grayscale 
images they will be as smooth as TGA and PPM images."

Post a reply to this message

> But AFAIK PoV-Ray's height_field functionality can't handle 
> grayscale 16-bit PNGs...

AFAIK, yes it can.

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:

> > But AFAIK PoV-Ray's height_field functionality can't handle
> > grayscale 16-bit PNGs...
>
> AFAIK, yes it can.

I've had trouble with 16 bit PNGs as well.  The height_field come out as if it
were noise.

Post a reply to this message

Jaime Vives Piqueres <jai### [at] ignoranciaorg> wrote:

> > A recent thread on p.b.i. drew my attention to http://www.buining.com -
> > those 16-bit PNG elevation maps of Earth, the Moon and Mars look
> > tempting! But AFAIK PoV-Ray's height_field functionality can't handle
> > grayscale 16-bit PNGs... are there any tool for conversion into 16-bit
> > heightfield TGAs available?
>
> I think this should work:
>

OK, I'm *completely* new to making 16-bit HFs. And so far, I'm feeling like a
complete dunce.  :-S  Even after reading the POV documentation. Help!

I downloaded the EarthDEM2160.png image file from the given link--a hi-rez,
16-bit elevation map of the earth's continents. Or so says the site--I have no
way of checking the bit depth, computer-knowledge-impaired as I am. (Photoshop
5.0 brings it up as an 8-bit image.)

So, do I understand that the proper series of events is, first to use Jaime's
technique of rendering this image in POV--as a hi-rez render, and setting my INI
file to Output_File_Type=N?  Doing so, I get a nice .png rendering...in 16 bits,
I assume. (Do I need to set Bits_Per_Color = 16 in the INI file as well? Haven't
done that yet.)

Then, do I take that rendered image and stick it into a a HF scene?  Like thus--

global{.....}
camera{......}
light_source(.....}
height_field{png "rendered_HF_image.png" scale <1,.2,1> // smooth
     texture{......}
            }

I get a HF, but it looks rather rough (to my eyes), like the vertical resolution
is still 8-bit.  Don't really know for sure.

Do I have the steps correct?

Ken W.

Post a reply to this message

> file to Output_File_Type=N?  Doing so, I get a nice .png rendering...in 16 bits,
> I assume. (Do I need to set Bits_Per_Color = 16 in the INI file as well? Haven't
> done that yet.)
> 
> I get a HF, but it looks rather rough (to my eyes), like the vertical resolution
> is still 8-bit.  Don't really know for sure.

Yes, you do need Bits_Per_Color=16. Or just +fn16, which sets image type 
to PNG and 16 bits :) I remember the short +stuff easier than the 
Long_Ini_Settings... (and faster to type)

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:

>
> Yes, you do need Bits_Per_Color=16. Or just +fn16, which sets image type
> to PNG and 16 bits :) I remember the short +stuff easier than the
> Long_Ini_Settings... (and faster to type)

Thanks!

Either I'm vision-impaired, or I just haven't seen that little tidbit in the POV
docs, in either the hf_gray_16 section or the one on HFs. Perhaps it should be
obvious... though my initial thought was that setting the original rendering to
hf_gray_16 would take care of that.

Details, details...

So if the file_type has to be manually set to .png, and the Bits_Per_Color to
16--what exactly does global{hf-gray-16} do?? Besides making the image
gray-scale?  Hmm, perhaps that IS its only purpose, to eliminate unnecessary
color channels. Gee, I feel smarter already!

Ken W.

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:

>
> So, do I understand that the proper series of events is, first to use Jaime's
> technique of rendering this [downloaded] image in POV--as a hi-rez render,
> and setting my INI file to Output_File_Type=N...

Duh!  It just occurred to me--I'm finally starting to use my brain--that I can
use the 16-bit downloaded grayscale image AS-IS to make the height_field. No
hf_gray_16 rendering step required. The HF renders nicely.

So I have a question (truly out of ignorance): What is the purpose of
re-rendering  that 16-bit image using the hf_gray_16 rendering step that was
mentioned? Seems unnecessary and redundant (other than to apply interpolate 2
to it?) I DO understand that a preliminary rendering step is of course
necessary (using one of POV's patterns, for example) if there is no 16-bit
image to begin with.

I'm confused; please enlighten this poor unfortunate soul.

Ken W.

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:

> So I have a question (truly out of ignorance): What is the purpose of
> re-rendering  that 16-bit image using the hf_gray_16 rendering step that was
> mentioned?

A more enlightened reading of Jaime's original post tells me that I was
completely confused about what he meant (and I probably confused others by my
question.) It's clear now; he was describing a solution to the question in the
original post, a technique for taking a 16-bit .png image and re-rendering it to
be a different file type, one that could be used to make a 16-bit HF in case the
..png image itself didn't work.

But as others have said, a 16-bit .png image works as-is.

All clear. I'm off and running!

Ken W.

Post a reply to this message