SharkD wrote:
> Nicolas Alvarez <nic### [at] gmailcom> wrote:
>> I don't think it would be easy at all. You definitely can't use
>> antialiasing :) (try slightly blurring the image you have and loading it
>> into your app, see what you get!)
> 
> Antialiasing doesn't seem to have harmed it in any way.

That's because at first I thought you wanted to do the opposite: generate
such a 24-bit image from POV-Ray, for another program to use. *That* would
be harmed by AA.

Post a reply to this message

"SharkD" <nomail@nomail> 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.
>
> http://i421.photobucket.com/albums/pp292/SharkD2161/Support/Untitled1_hf.png
>
> -Mike

I just rediscovered that I originally created the heightfield using Daylon
Leveller.

-Mike

Post a reply to this message

SharkD wrote:
> I just rediscovered that I originally created the heightfield using Daylon
> Leveller.

Daylon provides a patch for POV-Ray that can load .ter files (directly from
Leveller) as heightfield images.

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailcom> wrote:
> Daylon provides a patch for POV-Ray that can load .ter files (directly from
> Leveller) as heightfield images.

Does this result in superior heightfields, or is it just for the convenience of
not having to convert between various formats?

-Mike

Post a reply to this message

"SharkD" <nomail@nomail> wrote:
> 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

It seems the 48 bit image is being converted to grayscale first, which results
in a wildly different heightfield.

-Mike

Post a reply to this message