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

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.

Bill P.

Post a reply to this message

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

> 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.

Which raises the question about how the IEEE 754 gets implemented in POV-Ray's
source code, and if a user can test for -0 through SDL.

I actually just watched:

Fast Inverse Square Root — A Quake III Algorithm
https://www.youtube.com/watch?v=p8u_k2LIZyo

yesterday (it was in the sidebar when watching yesbird's animation), and they
went over some interesting points, and was also wondering if we could implement
something like this in POV-Ray SDL, and source, and if you'd find it useful or
are already using it in povr.

- BW

Post a reply to this message

On 2/18/23 08:33, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
>> 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.
> 
> Which raises the question about how the IEEE 754 gets implemented in POV-Ray's
> source code, and if a user can test for -0 through SDL.

So tempted to answer I don't know(a)... ;-)

For the floating point standard we mostly get what the C++ compilers 
give us depending upon options used while compiling. Excepting where in 
the POV-Ray source there might be hard coded behavior which is not 
strictly compliant or in days gone by was intended to handle things is 
some more compliant manner(b).

As for testing for -0 via SDL, I cannot think of any direct method...

On my development compiles using g++ 11.3 and the -ffast_math flag, I 
can code:

#declare negZero = -0.0;
#declare posZero = +0.0;
#declare hmmZero = 0.0/-1.0;

#debug concat("-0.0 shows up as : ",str(-0.0,0,-1)," \n")
#debug concat("+0.0 shows up as : ",str(+0.0,0,-1)," \n")

#debug concat("Var negZero shows up as : ",str(negZero,0,-1)," \n")
#debug concat("Var posZero shows up as : ",str(posZero,0,-1)," \n")
#debug concat("Var hmmZero shows up as : ",str(hmmZero,0,-1)," \n")

#error "\nStopping at end of parsing\n"

and see as a result:

-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

So maybe build up strings and do a string compare?

Aside: The C++ value comparison operators mirrored in SDL will - by 
default - ignore the sign of zero.

> 
> I actually just watched:
> 
> Fast Inverse Square Root — A Quake III Algorithm
> https://www.youtube.com/watch?v=p8u_k2LIZyo
> 
> yesterday (it was in the sidebar when watching yesbird's animation), and they
> went over some interesting points, and was also wondering if we could implement
> something like this in POV-Ray SDL, and source, and if you'd find it useful or
> are already using it in povr.
> 
Cool old stuff!

As for fast, clever algorithms... I've tried some tricks in povr and 
looked over quite a few, though not the particular one in the video. 
Most come with somewhat noisy behavior compared to standards compliant 
code. The noise is difficult to swallow given the end benefit(c) - 
floor() and ceil() fast equivalents, for example.

Bill P.

(a) I don't know it all - about anything. Where I do know a little, 
there's almost never a simple, complete answer.

(b) The radiosity code to this day has some complicated configurations 
related to the floating point math, for example. Unsure what all of this 
used or needed these days.

(c) The povr fork, while coding up new functions, did implement single 
and floating point flavors / options for many functions. Anywhere the 
single floating point code was significantly faster on my i3 hardware - 
at the expense of accuracy. Often single float accuracy in functions is 
OK depending on - stuff.

Measuring and tuning for performance is REALLY difficult these days 
given the hardware realities. For core functionality, the tuning job is 
best left to the compiler folks as a near hard rule.

Post a reply to this message

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