Nicolas Alvarez wrote:
> But using some creative coding, I can get an isosurface out of a
> heightfield. I lose almost all interpolation though; it looks like a
> heightfield without the "smooth" parameter.

http://imagebin.ca/view/5lUU-ge.html

Source attached.

"interpolate 2" in the image_map is absolutely necessary. Without
interpolation, it like a bunch of square blocks, one for each pixel; the
function gradient and the render times go through the roof, and it looks
ugly. With it, the isosurface looks like a non-smoothed heightfield.

Post a reply to this message

Attachments:
Download 'us-ascii' (1 KB)

Nicolas Alvarez <nic### [at] gmailcom> wrote:
> I put the image directly into a heightfield, and I think I got the correct
> height, but only at 16 bits. I can't see any way (without hacking the code)
> to get 24 bits of precision in a heightfield.

How did you check whether it was only using 16 bits?

-Mike

Post a reply to this message

"SharkD" <nomail@nomail> wrote:
> Nicolas Alvarez <nic### [at] gmailcom> wrote:
> > SharkD wrote:
> > > I generated the following heightfield in some program or other. It uses
> > > all 24 bits for elevation information. My question is, how are the
> > > colors/height data organized? I would like to create a pigment that
> > > produces similar maps.
> >
> > Seems similar to the POV-Ray TGA heightfields, except using all three
> > channels instead of two.
> >
> > Basically, red*256*256 + green*256 + blue = 24-bit grayscale value.
>
> How would I create this type of pigment? Thanks.
>
> -Mike

OK, here's the pigment:

#local hf_pigment_function_pow = function {y * pow(256,3)}
#local hf_pigment_function_b = function {mod(hf_pigment_function_pow(x,y,z),
pow(256,1))}
#local hf_pigment_function_g = function {mod(hf_pigment_function_pow(x,y,z) -
hf_pigment_function_b(x,y,z), pow(256,2))}
#local hf_pigment_function_r = function {mod(hf_pigment_function_pow(x,y,z) -
hf_pigment_function_b(x,y,z) - hf_pigment_function_g(x,y,z), pow(256,3))}

#local hf_pigment_b = pigment
{
 function {hf_pigment_function_b(x,y,z) / pow(256,1)}
 color_map {[0 rgb 0][1 rgb z]}
}
#local hf_pigment_g = pigment
{
 function {hf_pigment_function_g(x,y,z) / pow(256,2)}
 color_map {[0 rgb 0][1 rgb y]}
}
#local hf_pigment_r = pigment
{
 function {hf_pigment_function_r(x,y,z) / pow(256,3)}
 color_map {[0 rgb 0][1 rgb x]}
}

// This is the one you want
#local hf_pigment_rgb = pigment
{
 average
 pigment_map {[3 hf_pigment_b][3 hf_pigment_g][3 hf_pigment_r]}
}

Post a reply to this message

"Reactor" <rea### [at] hotmailcom> wrote:
> I am intrigued by this idea.  I have been using hf_gray_16 in the past, and it
> usually creates enough levels, but an hf_gray_24 might be pretty cool too.

Well, an hf_gray_24 function would require a new image format: one in which each
channel stores 24 bits of color information, for a total of 72 bits for the
entire image. AFAIK, povray only supports a maximum of 16 bits-per-color in a
handful of formats (PNG is one of them).

The pigment I created will generate 24 bits of heightfield data in 8
bits-per-color images (the most common format), and 48 bits of heightfield data
in 16 bits-per-color images.

-Mike

Post a reply to this message

SharkD wrote:
> Nicolas Alvarez <nic### [at] gmailcom> wrote:
>> I put the image directly into a heightfield, and I think I got the
>> correct height, but only at 16 bits. I can't see any way (without hacking
>> the code) to get 24 bits of precision in a heightfield.
> 
> How did you check whether it was only using 16 bits?

The documentation says so.

Post a reply to this message

"SharkD" <nomail@nomail> wrote:
> "Reactor" <rea### [at] hotmailcom> wrote:
> > I am intrigued by this idea.  I have been using hf_gray_16 in the past, and it
> > usually creates enough levels, but an hf_gray_24 might be pretty cool too.
>
> Well, an hf_gray_24 function would require a new image format: one in which each
> channel stores 24 bits of color information, for a total of 72 bits for the
> entire image. AFAIK, povray only supports a maximum of 16 bits-per-color in a
> handful of formats (PNG is one of them).
>
> The pigment I created will generate 24 bits of heightfield data in 8
> bits-per-color images (the most common format), and 48 bits of heightfield data
> in 16 bits-per-color images.
>
> -Mike

Actually, the hf_gray_16 format doesn't use 16 bits per channel.  It uses the
existing channels. From the docs:
"The TGA and PPM file formats may be used as a storage device for 16 bit numbers
rather than an image file. These formats use the red and green bytes of each
pixel to store the high and low bytes of a height value.
....
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. Since they are grayscale images you will be able
to view them with a regular image viewer."

You can use hf_gray_16 with png also, and it results in the same sort of
multicolored output, but only with 16 bits for 65536 levels.  What I meant by
hf_gray_24 wasn't for 24 bits per channel, but a 24 bit grayscale image which,
instead of using only the red and green 8-bit channels for 16 bits, would use
the red, green, and blue channels for a total of 24 bits.  No new image format
would be needed.

-Reactor

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailcom> wrote:
> SharkD wrote:
> > Nicolas Alvarez <nic### [at] gmailcom> wrote:
> >> I put the image directly into a heightfield, and I think I got the
> >> correct height, but only at 16 bits. I can't see any way (without hacking
> >> the code) to get 24 bits of precision in a heightfield.
> >
> > How did you check whether it was only using 16 bits?
>
> The documentation says so.

I couldn't find anywhere in the docs where it said there was a maximum *limit*.
Rather, it merely provides an overview of the different formats, and fails to
mention any 24 bit options.

As an experiment, I created a copy of "Untitled1_hf.png", except with the blue
channel set to zero. The resulting heightfield looks subtly but noticibly
different. If it is true that povray only supports 16 bits, then 8 bits must be
being discarded *somewhere*.

-Mike

Post a reply to this message

SharkD wrote:
> As an experiment, I created a copy of "Untitled1_hf.png", except with the
> blue channel set to zero. The resulting heightfield looks subtly but
> noticibly different.
Oh really...

Post a reply to this message

"Reactor" <rea### [at] hotmailcom> wrote:
> Actually, the hf_gray_16 format doesn't use 16 bits per channel.  It uses the
> existing channels. From the docs:
> ...
> You can use hf_gray_16 with png also, and it results in the same sort of
> multicolored output, but only with 16 bits for 65536 levels.  What I meant by
> hf_gray_24 wasn't for 24 bits per channel, but a 24 bit grayscale image which,
> instead of using only the red and green 8-bit channels for 16 bits, would use
> the red, green, and blue channels for a total of 24 bits.  No new image format
> would be needed.
>
> -Reactor

OK, thanks. I tried opening up one of these PNG images in my image editor, with
weird results. Adjusting the blue and green channels had no effect, and setting
the red channel to 0% still leaves some residual coloring. Also, the program
claims the image has only 256 unique colors! Checking the levels also resulted
in wonkyness.

:)

-Mike

Post a reply to this message

"SharkD" <nomail@nomail> wrote:
> OK, here's the pigment:
> ...

I tested the pigment on a cone, and then used the output in a heightfield. It
seems to work OK if the output is rendered in as a 24 bit image, but produced
weird results when using a 48 bit image.

-Mike

Post a reply to this message