You know the spotted base where the height=0.
I was going through the 3.6 source code and there is:

const DBL HFIELD_OFFSET = 0.001;

This was added and subtracted to the bounding box as well as other things I
haven't chased down.

The point is that if I use a water_line of .001 the spots goes away.

I don't know about other versions. I guess I need to chase them down.

Have Fun!

Post a reply to this message

On 3/21/23 15:03, Leroy wrote:
> 
> You know the spotted base where the height=0.
> I was going through the 3.6 source code and there is:
> 
> const DBL HFIELD_OFFSET = 0.001;
> 
> This was added and subtracted to the bounding box as well as other things I
> haven't chased down.
> 
> The point is that if I use a water_line of .001 the spots goes away.
> 
> I don't know about other versions. I guess I need to chase them down.
> 
> Have Fun!
> 
Thanks for the information.

You're not the only one who's reported strangeness near 0.0 in the 
height field. Now a few years back, I came across a blog where someone 
was creating height_fields of her home terrain and using POV-Ray renders 
to look around. She had trouble when the camera positions got near 0.0 
which I'd bet was a near zero bug of some kind too.

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! :-)

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

---

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.

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.

So! I think, I've eliminated the image based height_field flakiness in 
the povr fork. I believe, too, this was the last of the special red 
weighted, red+green to grayscale conversion code that was in use.

Bill P.

Post a reply to this message

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

On 3/23/23 17:12, Leroy wrote:
 > I never use the special <8 bit any way!

The odd color to grey code kicked in at <=8 bit image channel depths.

> But I have over 400 of those tga palette height field images.

Would you be kind enough to post one example image here? I'm curious as 
to the exact format of your tga's.

In any case, my povr fork certainly breaks backward compatibility with 
POV-Ray in a great many ways. :-)

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 3/23/23 17:12, Leroy wrote:
>  > I never use the special <8 bit any way!
>
> The odd color to grey code kicked in at <=8 bit image channel depths.
>
> > But I have over 400 of those tga palette height field images.
>
> Would you be kind enough to post one example image here? I'm curious as
> to the exact format of your tga's.
>
> In any case, my povr fork certainly breaks backward compatibility with
> POV-Ray in a great many ways. :-)
>
> Bill P.

What I'm kind of proud of is that the palette is special. The blue part of the
each palette element matches that element number. So a pigment function that
outputs blue matches the old standard Height field. I didn't plan on that. When
I set it up  all those years ago I did it that way because it was easier to
code.

Here One that shows the full 256 range

Post a reply to this message

Attachments:
Download 'cratord.tga.tar' (158 KB)

On 3/26/23 15:36, Leroy wrote:
> What I'm kind of proud of is that the palette is special. The blue part of the
> each palette element matches that element number. So a pigment function that
> outputs blue matches the old standard Height field. I didn't plan on that. When
> I set it up  all those years ago I did it that way because it was easier to
> code.
> 
> Here One that shows the full 256 range

Thanks! Played with it a while and yep, these exactly the kind that do 
work and I've dropped support for them in my povr code... There are many 
format variations with tga and I thought you might be using something 
else.

The tga indexed input POV-Ray allows, can be 8 bit (256 deep) or 16 bit 
(65535 deep). The latter form won't work correctly with the index method 
in existing POV-Ray versions. It'll do some sort of wrap.

I looked around quickly for a converter which would convert to another 
image format directly from the index values, but had no luck. Something 
must exist somewhere I'd guess.

In general our image support is decent, but we don't support everything, 
every format can do by any stretch. With povr I don't want to burn my 
limited time on this image support work and I have considered dropping 
some formats completely. It's just a resource thing. But, I don't know, 
maybe there is a way to make use of an external conversion library or 
something.

Bill P.

Post a reply to this message

Le 2023-03-26 à 18:57, William F Pokorny a écrit :
> On 3/26/23 15:36, Leroy wrote:
>> What I'm kind of proud of is that the palette is special. The blue 
>> part of the
>> each palette element matches that element number. So a pigment 
>> function that
>> outputs blue matches the old standard Height field. I didn't plan on 
>> that. When
>> I set it up  all those years ago I did it that way because it was 
>> easier to
>> code.
>>
>> Here One that shows the full 256 range
> 
> Thanks! Played with it a while and yep, these exactly the kind that do 
> work and I've dropped support for them in my povr code... There are many 
> format variations with tga and I thought you might be using something else.
> 
> The tga indexed input POV-Ray allows, can be 8 bit (256 deep) or 16 bit 
> (65535 deep). The latter form won't work correctly with the index method 
> in existing POV-Ray versions. It'll do some sort of wrap.
> 
> I looked around quickly for a converter which would convert to another 
> image format directly from the index values, but had no luck. Something 
> must exist somewhere I'd guess.
> 
> In general our image support is decent, but we don't support everything, 
> every format can do by any stretch. With povr I don't want to burn my 
> limited time on this image support work and I have considered dropping 
> some formats completely. It's just a resource thing. But, I don't know, 
> maybe there is a way to make use of an external conversion library or 
> something.
> 
> Bill P.

Remember that 8 bits and less are paletted formats and that 16 or more 
are non-paletted.
IIRC, in hight fields, when the image is 24 bits, the red and green 
channels are used to to represent the high (green) and low (red) bytes 
of a 16 bits value and the blue channel is ignored.
16 bits is often called high colour and 24 and 32 bit are called true 
colour.

Post a reply to this message

On 3/27/23 15:28, Alain Martel wrote:
> Remember that 8 bits and less are paletted formats and that 16 or more 
> are non-paletted.

This doesn't look to me to be strictly true. It might be 'typically 
true' for height_field images in some formats with respect to 
traditional POV-Ray usage.

> IIRC, in hight fields, when the image is 24 bits, the red and green 
> channels are used to to represent the high (green) and low (red) bytes 
> of a 16 bits value and the blue channel is ignored.

In official POV-Ray releases: "when the color image is <=8 bits per RGB 
channel"

And, I too flipped the importance of green and red in one of my earlier 
descriptions - probably because green in typical color to gray 
conversions matters most to luminosity / the gray level.

It's not how the special (<=8 bit a channel) color to gray conversion in 
POV-Ray works where the most weight is in fact given to red.

> 16 bits is often called high colour and 24 and 32 bit are called true 
> colour.

Ah yes! I remember being so excited to finally be working on a true 
color display! :-)

My college terminals were teletypes.

I started work years on green and black IBM 3277s - and white and black, 
vector displays, I think, IBM 2250s or 3250s. Those latter displays had 
light pens you'd bang directly on a heavy glass screen for selection and 
movement.

Once you got a lot of vectors up, the refresh rolled across the screen 
at a few screen refreshes a second - and selection and movement got 
really hard. The heat on our faces and the sound in the terminal rooms 
was something else when folks were really cranking.

There were some black and green Tektronix displays in use too for our 
graphics. They were nice because they didn't flicker at high densities. 
The image was written on a screen sort of like an etch and sketch - 
until you refreshed. I cannot, at the moment, remember the models.

My time on another planet...

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 3/27/23 15:28, Alain Martel wrote:
> > Remember that 8 bits and less are paletted formats and that 16 or more
> > are non-paletted.
>
> This doesn't look to me to be strictly true. It might be 'typically
> true' for height_field images in some formats with respect to
> traditional POV-Ray usage.
>
> > IIRC, in hight fields, when the image is 24 bits, the red and green
> > channels are used to to represent the high (green) and low (red) bytes
> > of a 16 bits value and the blue channel is ignored.
>
> In official POV-Ray releases: "when the color image is <=8 bits per RGB
> channel"
>
> And, I too flipped the importance of green and red in one of my earlier
> descriptions - probably because green in typical color to gray
> conversions matters most to luminosity / the gray level.
>
> It's not how the special (<=8 bit a channel) color to gray conversion in
> POV-Ray works where the most weight is in fact given to red.
>
> > 16 bits is often called high colour and 24 and 32 bit are called true
> > colour.
>
> Ah yes! I remember being so excited to finally be working on a true
> color display! :-)
>
> My college terminals were teletypes.
>
> I started work years on green and black IBM 3277s - and white and black,
> vector displays, I think, IBM 2250s or 3250s. Those latter displays had
> light pens you'd bang directly on a heavy glass screen for selection and
> movement.
>
> Once you got a lot of vectors up, the refresh rolled across the screen
> at a few screen refreshes a second - and selection and movement got
> really hard. The heat on our faces and the sound in the terminal rooms
> was something else when folks were really cranking.
>
> There were some black and green Tektronix displays in use too for our
> graphics. They were nice because they didn't flicker at high densities.
> The image was written on a screen sort of like an etch and sketch -
> until you refreshed. I cannot, at the moment, remember the models.
>
> My time on another planet...
>
> Bill P.

Wait, are you older than me? ...haha.
I remember those days...out of college before there was computers. :)
But I did have an old vector image setter pre 8088 & post script that used an 8"
Winchester drive... first intro to burning film negatives with machine-coded
light.
Mike...from someone born in the 50's.uggg.

Post a reply to this message

On 4/12/23 23:25, Mike Miller wrote:
> Wait, are you older than me? ...haha.
> I remember those days...out of college before there was computers. 😄
> But I did have an old vector image setter pre 8088 & post script that used an 8"
> Winchester drive... first intro to burning film negatives with machine-coded
> light.
> Mike...from someone born in the 50's.uggg.

:-) Well, not if you were born in the 50s. Very early 60s for me.

8in Winchester drives...

Your post reminded me my 'very' first experience with a proper computer 
came thanks to the electronics teacher at our High School. He personally 
purchased a model 1 TRS 80 and was kind enough to bring it into school 
for periods of time. He let some of us to play with it after hours or 
during the odd teacher in service day. I remember working hard with a 
friend to create our own version of the early mainframe, Dungeons and 
Dragons game - all descriptive text. "You are standing in front of a 
door..." Cassette tape drive for storage IIRC. Black and white TV for a 
display.

Later, built a similar 'personal computer' as one of our class projects 
in college. Wire wrapped components on a board with a z80 as the cpu - 
power supply, tape interface and such from raw components. Switch 
sequences to start the boot up. It also used cassette tapes for storage 
and a small TV for the display. Basic as the inbuilt language, but 
programmed quite a bit in assembly too - using the switches IIRC - no 
assembler program...

Memory is well on foggy though - so might be some of the details are wrong.

Bill P.

Post a reply to this message