The following code can be used to explore the issue. I've not yet dug 
beyond what I tried in this posted scene.

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.

Bill P.

// Test scene
#version 3.7;
global_settings { assumed_gamma 1 }

camera
{ // location <1,1,1> * 2
   location <1.5,3,-2>
   look_at <.5,.3,0>
   angle 50
}

light_source { <10,10,10>, rgb <1,1,1> }

height_field {
   function 500, 500 { 0 } // Noisy result at y scale 0.3? Poof 0.5?
//function 500, 500 { 1 } // This is always OK no matter the scaling.
   smooth
//scale <1, 0.3, 1> // Zero Fn val Noisy
//scale <1, 0.5, 1> // Zero Fn val. HF now invisible ?
// and with no scaling also invisible.
   pigment { green 0.8 }
}

//----------

plane{y,0 pigment{rgb .2}}

Post a reply to this message

On 2/15/23 08:15, William F Pokorny wrote:
> 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.

:-) My first thoughts are so often mostly wrong...

The problem in this scene starts with a coincident surface! If the 
height_field mesh is entirely at 0.0 in y, it is coincident with the 
plane in the scene. Fix this issue and results are solid no matter the 
scaling in y.

Note. Inbuilt Patterns especially often clamp to the [0-1] range due 
numerical noise.

Bill P.


More detail
-----------
The coincident surface signature is different than I'm used to. Here it 
is tangled with auto bounding in an odd way based on scaling in y. If I 
turn bounding off with -mb, the cases which had previously disappeared 
completely on larger or no scaling in y, are cleanly there - which is 
also an odd coincident surface signature.

No bounding and the smaller scaling is more there and with a more 
typical (to my eye's experience anyhow) coincident surface appearance.

I don't understand why scaling is affecting results as it is, but, I'm 
not going to further chase this.

Post a reply to this message

On 2/15/23 05:34, William F Pokorny wrote:

[from a recent post in " Using a function in a height_field declaration" thread]

> Yes. Functions as used in height_fields never see called x,y values
> outside the [0-1] range.

> Forgot to plug a new povr function called f_boom() I believe should be
> in any v4.0 release.

> #include "functions.inc"
> #declare FnChkVals = function (x) {
>      select(((x<0.0) | (x>1.0)),
>          0,
>          0,
>          f_boom(x,2,3,4,5,6)
>      )
> }
>
> height_field {
>   function 500, 500 { FnChkVals(y) }

> A little ugly in that it throws after printing six values, but it offers
> a quick way for 'users' to test values in functions. Above we're testing
> that y as seen in the HF called function is never outside the [0,1]
> range.

I've been taking a look at this and playing around with it in a modified way--
leaving out  f_boom(...) and changing some values so that the construct itself
will work for me...

I didn't #include "functions.inc", just...

#declare FnChkVals = function (y) {
     select(((x<0.0) | (x>1.0)),
         0,
         0.3,
         0.6 // instead of f_boom
     )
}

height_field {
   function 500, 500 { FnChkVals(y) }
   }

As a result, I get a nice 'planar' height_field at y=0.3... so at least that's
my own 'sanity check', and that I can make it work in a basic way ;-)

But there is something about your construct that puzzles me, as I do not use
'select' very much. The documentation says, "Select compares the first argument
with zero, depending on the outcome it will return B, C or D."

The way I see
           select(((x<0.0) | (x>1.0))
is that it's basically a 'true/false' comparison(?) here. In other words, no
matter what the values of x might be, the result of the argument in parentheses
can only be a 'comparison against 0', by definition.

*If* that is the case, then the select() result can have only two states or
outcomes-- true or false (or 1 and zero). Which would then pick either argument
B or C, but never D(??) So, I am wondering if your f-boom macro will ever
actually be chosen by this select() set-up.

I assume that it *does* work for you, so I must have a misconception about
select() itself and how it operates here.

Post a reply to this message

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

>
> *If* that is the case, then the select() result can have only two states or
> outcomes-- true or false (or 1 and zero). Which would then pick either argument
> B or C, but never D(??) So, I am wondering if your f-boom macro will ever
> actually be chosen by this select() set-up.
>

Hmm. I think I muddied my question and my logic, sorry. I kind of mixed up what
happens in a 4-argument 'select' use.

But it would seem that only two of the three B-C-D select() results could be
chosen by your function, but not all three.

Post a reply to this message

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

> > #include "functions.inc"
> > #declare FnChkVals = function (x) {
> >      select(((x<0.0) | (x>1.0)),
> >          0,
> >          0,
> >          f_boom(x,2,3,4,5,6)
> >      )
> > }


Kenneth, I use select all the time.

This is how it works:

select (N, -1, 0, 1)

When your comparison function gets evaluated, it returns a Boolean state (in
POV-Ray it's a 0 or a 1).

So what he's doing, is checking if x is less than 0 or greater than 1.
If it is, then the Boolean result is true, which in POV-Ray is 1.
If it's not, then the result is false, or zero.
The negative option in the select statement never gets used - it's just there to
force the select function to have a zero option that's separate from the 1
option, since a 3-term select statement is divided into 2 results:  negative or
>= 0.

I hope that helps.

Post a reply to this message

On 2/16/23 19:56, Bald Eagle wrote:
> since a 3-term select statement is divided into 2 results:  negative or
 > ????.

Bill W (BE) explained well.

However, I'm going to re-state things because what showed up where I 
have ???? characters above looks different on the web than what I see in 
Thunderbird(a).

There are two forms of select(). The is a four term/argument version and 
a three term version. The four term allows 'actions' for negative, zero 
and positive input values. The three term one allows actions for 
negative and (zero or positive) values.

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.

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)

I think this form less clear and, FWIW, it's slower than the four term 
version.

Bill P.

(a) The leading '>' character got picked up as being an indication of 
text from a previous post and is displaying as a vertical bar '|' in 
Thunderbird.

Post a reply to this message

On 2/16/23 18:45, Kenneth wrote:
> Yes. Functions as used in height_fields never see called x,y values
> outside the [0-1] range.

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

In other words, there is a jump or discontinuity when returning values 
go negative or larger than 1. Further, there is no ability to to invoke 
wave(a) modifiers as is true with the pattern mechanism.

Function based image_maps and height_fields all end up in a [0-1] 
vertical/value range - even if your function itself returns values 
outside that range.

Bill P.

(a) - The povr fork offers some wave modification capability via new 
inbuilt functions like f_sine_wave().

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
>
> I'm going to re-state things because what showed up where I
> have ???? characters above looks different on the web than what I see in
> Thunderbird(a).

No problem at my end; I see the correct syntax in the web portal.

Sorry for my longer-than-usual-delay in responding; I had to think hard about
this 'negative option being ignored' thing, and the difference between a 3-part
vs. 4-part select(). I was still thinking about it when I feel asleep last
night! William P's function construct makes better sense to me now; I finally
had the 'flashing insight'.

docs for the 4-part select:
When used with four parameters, if A < 0 it will return B. If A = 0 it will
return C. Else it will return D (A > 0).

I had to work out my own rather pedantic 'truth table' of sorts, as I see it --
hopefully corrected this time--

-------
Given  ((x<0.0) | (x>1.0))  as the first argument 'A':
The boolean results in parentheses are only ever 0 or 1 (true or false).

if x is indeed less than 0.0 OR greater than 1.0, that produces boolean TRUE (or
1) in the parentheses. Compared against select's 'zero by definition' for A,  1
is 'greater than zero'.  So according to the rules, the outcome of select() will
be argument D-- the f_boom macro. Effectively, it doesn't matter if x exceeds
either limit; the result will be TRUE in either case.

If x is exactly 0.0  *or inside the given range*, the boolean operation in
parentheses produces FALSE (or 0). But, for select's argument A
comparison, 'zero equals zero' -- and argument C is chosen, which is 0.0 in
William P's code and 0.3 in mine.
-------

So far, argument B is never chosen; C and D take care of every possible outcome
of    ((x<0.0) | (x>1.0))

HOWEVER, I see now that a simpler 3-part select() would not work when using
argument A as written-- because of the 3-part rules: Argument B is only chosen
when argument A is *less than* 0, which never occurs with  ((x<0.0) | (x>1.0))

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> The boolean results in parentheses are only ever 0 or 1 (true or false).

The boolean results in parentheses are only ever 0 or 1 (false or true).

Oops.  ;-)

Post a reply to this message

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
)


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

Post a reply to this message