William F Pokorny <ano### [at] anonymousorg> wrote:
>
> I'm aware of that water_level setting, but I've never played with it.
> All those buttons and not the time to push them all! :-)
>

I'm was the same way with function height fields, until lately.

> The height_field code is old and due a refresh I expect. Someday...
>

So are we all!

> ---
>
> Since we are talking height_fields! The upcoming version (R7 v0.6.1) of
> my povr fork removes the special <=8 bit, red weighted color to grey
> scale conversion. No matter the color image channel depth the internal
> .grayscale() conversion will get used.
>
I never use the special <8 bit any way!

> Plus I made indexed images illegal as input. The old code used the index
> values in such images to create an equivalent gray level, but only with
> 256 index values. Further the height, for historical reasons, was muted
> in that the max height returned was never more than 0.4% of the full
> height_field height.

 But I have over 400 of those tga palette height field images. When I first
started pov it was dos. And I learned how to make gif images for height fields.
Then I upgraded and made my own tga/ppm win program for 256 and 63556 level
height fields just for pov. I still use tga for quick HF images. Gifs have gone
the way of the dodo. My flavor of ppm is really only good for really short HFs.
 I guess it is time to think of rewriting some new code. Or I can always use
older pov versions.

Have Fun!

Post a reply to this message