William F Pokorny <ano### [at] anonymousorg> wrote:
>
> Just something I happened to see while looking into other height_field
> questions of late.
>
> The HF zero (y as image/fnct evaluated) and z HF result should cleanly
> show up no matter scaling! At best it is today noisy.
>
> Looks to be an issue back through v3.7 stable at least. I think given
> the noise it's likely some numerical and/or bounding issue rather than
> the actual HF mesh. We'll see.
>

[Running v3.8.0 beta 1 in Windows 10]

I ran a bunch of animation tests of
height_field{
      function 500,500 {0}
.....

....while changing various values. Here are some results:

If the HF is given a solid color pigment, I don't see any speckles or odd
coincident-surface problems at all.

But if I give it
       pigment{ gradient y color_map{[0 rgb 0][1 red 10]}}
I do see the speckles.

Apparently, the color_map is repeating from the top of its red color, but from
'below' the HF.

I also ran some tests while slightly varying the function value itself, and also
used min_extent/max_extent to see what values they would return. The results are
a bit odd, to say the least:

(using the gradient y color_map):

function 500,500 {0} has the speckles
MIN_EXT = <0.0000000000, -0.0000000023, 0.0000000000> note minus sign for y
MAX_EXT = <0.0000000000, -0.0000000023, 0.0000000000>

function 500,500 { 0 + .0000152} has the speckles.
The resulting height_field size:
MIN_EXT = <0.0000000000, -0.0000000023, 0.0000000000> -- same as above
MAX_EXT = <0.0000000000, -0.0000000023, 0.0000000000>

function 500,500 { 0 + .0000153} shows no speckles at all -- but with an abrupt
change in the y value:
MIN_EXT = <0.0000000000, 0.0000022865, 0.0000000000>
MAX_EXT = <0.0000000000, 0.0000022865, 0.0000000000>
---------
Now, if I change the function additions to subtractions:
function 500,500 { 0 - .0000152} has the speckles.
MIN_EXT = <0.0000000000, -0.0000000023, 0.0000000000> -- same as addition
MAX_EXT = <0.0000000000, -0.0000000023, 0.0000000000> -- ditto

function 500,500 { 0 - .0000152} -- The planar HF jumps up to y=1 (almost!) as I
kind of expected... but no speckles at all again, which was surprising.
MIN_EXT = <0.0000000000, 0.9999847412, 0.0000000000> -- y is not quite 1.0
MAX_EXT = <0.0000000000, 0.9999847412, 0.0000000000>

So from these stats and results, my *guess* is that there could be a very slight
'bias'(?) in the HF creation code-- or function-to-HF process? -- whereby the HF
is not actually from 0-1, but (0 minus a small value) to (1 minus the small
value.) OR, the same with the color_map mechanism. Although, the abrupt 'jumps'
between .0000152 and .0000153 are puzzling.

The tests were interesting at least!

Post a reply to this message

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

A typo, so sorry.

> function 500,500 { 0 - .0000152} -- The planar HF jumps up to y=1 (almost!) as I
> kind of expected... but no speckles at all again, which was surprising.
> MIN_EXT = <0.0000000000, 0.9999847412, 0.0000000000> -- y is not quite 1.0
> MAX_EXT = <0.0000000000, 0.9999847412, 0.0000000000>

function 500,500 { 0 - .0000153}

Post a reply to this message

On 2/18/23 14:50, Kenneth wrote:
> So from these stats and results, my*guess*  is that there could be a very slight
> 'bias'(?) in the HF creation code-- or function-to-HF process? -- whereby the HF
> is not actually from 0-1, but (0 minus a small value) to (1 minus the small
> value.) OR, the same with the color_map mechanism. Although, the abrupt 'jumps'
> between .0000152 and .0000153 are puzzling

Interesting results and I think on the right track for some of what is 
unique about height_field bounding. What you see with the sudden large 
jump on that last subtraction is the out of bounds ramp wave value re-map.

For the smaller jumps. Internally, and probably due the original 
image_map only usage, the max 3d size we can have is 2^16 a side - 
HF_VAL is an unsigned short int. Vertically this means we are working in 
a best resolution of 1/2^16 steps = 0.00001525...  This lines up with 
the values where you see abrupt change in extents and that's kinda cool.

The bounds tracking is done at least in part in terms of doubles during 
calculation and where a value of HFIELD_OFFSET (currently 0.001) is 
subtracted from the lowest value per side and added to the greatest 
value on the top side. After the at double calculation, the result is 
converted back to HF_VAL.

Because that 0.001 isn't a multiple of the 16bits of resolution I 
believe there must be some value snapping going on during the double to 
HF_VAL conversion.

That's as far as I got before bailing out.

In looking at your results I'm not at all sure why the max extent values 
for x and z are all zero? The HF max extent should be 1 or larger for x 
and z (always I think if not scaled) ?

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:

>
> In looking at your results I'm not at all sure why the max extent values
> for x and z are all zero? The HF max extent should be 1 or larger for x
> and z (always I think if not scaled) ?

Yes, that surprised me as well. My HF scale was at <1,1,1>. Odd results indeed.

Post a reply to this message

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> >...
> > I used the 4 term because I think it reads a little cleaner when setting
> > up a boolean test in the first term which can only return a zero or one
> > - the negative action is never used as Bill W said.
>
> I agree..
>
>
> > Aside: You can use the 3 term select depending upon a boolean result in
> > the first term test by doing something like:
> >
> > select(1-(2*((x<0.0) | (x>1.0))), 0, 1)
> >...
>
> How about just this:
>
> select(
>     -((x < 0.0) | (1.0 < x)),
>     0,
>     1
> )
>
> - or this:
>
> select(
>     -((0.0 <= x) & (x <= 1.0)),
>     1,
>     0
> )

But for that check select() isn't needed.
This should be sufficient:

((0.0 <= x) & (x <= 1.0))


--
Tor Olav
http://subcube.com
https://github.com/t-o-k

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 2/17/23 20:49, Tor Olav Kristensen wrote:
> >> Aside: You can use the 3 term select depending upon a boolean result in
> >> the first term test by doing something like:
> >>
> >> select(1-(2*((x<0.0) | (x>1.0))), 0, 1)
> >> ...
> > How about just this:
> >
> > select(
> >      -((x < 0.0) | (1.0 < x)),
> >      0,
> >      1
> > )
> >
> > - or this:
> >
> > select(
> >      -((0.0 <= x) & (x <= 1.0)),
> >      1,
> >      0
> > )
>
> :-)
>
> Very likely OK in practice, and cleaner in form than my three term select.
>
> What spooks me some is that -0 and +0 are real things in the IEEE
> floating point standard and as supported by C++. If a C++ coder has
> thought to test for -0 < 0, they can.

When you mention it, I think that I've actually have run into a problem with
negative zero in a version of POV-Ray.

IIRC I got different result when I used select() from what I got when I used <
or > in an #if statement.

So yes, it is scary.

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:

> In looking at your results I'm not at all sure why the max extent values
> for x and z are all zero? The HF max extent should be 1 or larger for x
> and z (always I think if not scaled) ?

This got me curious as well.

So I just threw some quick lines of code together.

The hf looks fine to me.   Typo in Ken's code?

#declare delta_hf = 1/pow (2, 16);
#debug concat ("1/pow (2, 16) = ", str (delta_hf, 0, 8), "\n")

#declare HF = height_field {
     function 800, 800 { 1 }
     }

#declare Min = min_extent (HF);
#declare Max = max_extent (HF);


-0.0 shows up as : -0.000000
+0.0 shows up as : 0.000000

Var negZero shows up as : -0.000000
Var posZero shows up as : 0.000000
Var hmmZero shows up as : -0.000000

select () interprets -0 as zero
sgn () interprets -0 as zero
Ternary interprets -0 as zero
#if interprets -0 as zero
1/pow (2, 16) = 0.00001526
Heightfield min_extent = = 0.00000000, 0.99998474, 0.00000000
Heightfield max_extent = = 1.00000000, 0.99998480, 1.00000000


Changing the function result to 0 yields:

Heightfield min_extent = = 0.00000000, -0.00000002, 0.00000000
Heightfield max_extent = = 1.00000000, 0.00000002, 1.00000000

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>
> > In looking at your results I'm not at all sure why the max extent values
> > for x and z are all zero? The HF max extent should be 1 or larger for x
> > and z (always I think if not scaled) ?
>
> This got me curious as well.
>
> So I just threw some quick lines of code together.
>
> The hf looks fine to me.   Typo in Ken's code?
>

Oooh, yet another one! You're absolutely right, I screwed up my #debug
statements, a cut-and-paste error from running  so many tests. I never actually
used my max_extent values. :-[  So sorry. That was a real whopper of a mistake.
My apologies to William P for 'chasing this down a rabbit hole'.

Using my now-corrected code, these are today's results:
function 500,500 {0}

MIN_EXT = <0.0000000000, -0.0000000153, 0.0000000000>

MAX_EXT = <1.0000000000, 0.0000000153, 1.0000000000>

--- BTW: For a somewhat quicker test, the HF could use   function 2,2 {0}
instead; the resulting planar HF still looks fine as an object, and also
produces the speckles vs. no-speckles comparison.


> 1/pow (2, 16) = 0.00001526

That's fascinating; I didn't realize that my 'jump' point had a computational
basis. Thanks!

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:

> Perhaps worth saying a little more than the above. Whether creating a
> height_field or internal image_map from a function in POV-Ray, any
> 'function return' values outside the [0-1] get 'wrapped' to a ramp wave
> as is the default with the majority of inbuilt patterns.
>
> So, function return values of:
> -0.1 --> 0.9
> -0.5 --> 0.5
> -0.9 --> 0.1.
> 1.1 --> 0.1
> 1.5 --> 0.5
> 1.9 --> 0.9

I will just point out that this is not currently documented anywhere.
https://wiki.povray.org/content/Reference:Maps
is blank.

If anyone wanted a quick 10-15 min project, writing a scene with a simple 0 --->
x color map and a loop, function, gradient pigment, or similar and showing that
the color_map value.x is modulo-wrapped would be great.
Numeric output via #debufg or file, or a graph showing Color.x would be nice.

- BE

Post a reply to this message

And actually, there seems to be some potentially conflicting information in the
documentation.

https://wiki.povray.org/content/Documentation:Tutorial_Section_2.2
"For every position in POV-space, a pattern returns a float value in the range
from zero to one. Values outside the zero to one range are ignored."

Presumably if a pigment pattern was wrapped in a function, one could then have
access to the actual values emitted, and either graph them or just run tests to
detect the presence of values <0 or >1.

- BE

Post a reply to this message