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