On 2/15/25 19:34, Bald Eagle wrote:
> It's the -inf that really has me puzzled!

Yes, it was that value which caused me to ask. :-)

What I remember is official POV-Ray had code, beyond the pattern-value 
modification code itself, which changed / mangled negative function 
return values ahead of the map handling. I don't remember the details.

It's possible there are differences in how the v3.8 executable you have 
was compiled. On the numerical fringes, compiler's and compiler settings 
can change quite a lot how odd values / NANs behave.

So as to better see what my working yuqk development compile does with 
the values, I changed the color_map to:

color_map {
     [-1.00 rgbt <1,1,0.3,1>]
     [0.00 rgb 0]
     [0.33 rgb x]
     [0.50-E rgb x]
     [0.50   rgbt 1]
     [0.50+E rgb y]
     [0.66 rgb y]
     [1.00 rgb z]
     [2.00 rgbt <1,1,0.6,1>]
}

I get:

Val(val("-inf")) = 0.000, 0.000, 0.000, 0.000, 0.000
Val(-0) = 0.000, 0.000, 0.000, 0.000, 0.000
Val(0) = 0.000, 0.000, 0.000, 0.000, 0.000
Val(+0) = 0.000, 0.000, 0.000, 0.000, 0.000
Val(E) = 0.000, 0.000, 0.000, 0.000, 0.000
Val(0.5-E) = 1.000, 0.013, 0.013, 0.000, 0.013
Val(0.5) = 1.000, 1.000, 1.000, 0.000, 1.000
Val(0.5+E) = 0.013, 1.000, 0.013, 0.000, 0.013
Val(1-E) = 0.000, 0.000, 1.000, 0.000, 0.000
Val(-0+1) = 0.000, 0.000, 1.000, 0.000, 0.000
Val(1) = 0.000, 0.000, 1.000, 0.000, 0.000
Val(+0+1) = 0.000, 0.000, 1.000, 0.000, 0.000
Val(val("+inf")) = 0.000, 0.000, 1.000, 0.000, 0.000
Val(val("-nan")) = 1.000, 1.000, 0.300, 0.000, 1.000
Val(val("nan")) = 1.000, 1.000, 0.300, 0.000, 1.000
Val(val("-0.33")) = 0.000, 0.971, 0.029, 0.000, 0.000

Adding yuqk's 'raw_wave' just below 'gradient x' I get:

Val(val("-inf")) = 1.000, 1.000, 0.300, 0.000, 1.000
Val(-0) = 0.000, 0.000, 0.000, 0.000, 0.000
Val(0) = 0.000, 0.000, 0.000, 0.000, 0.000
Val(+0) = 0.000, 0.000, 0.000, 0.000, 0.000
Val(E) = 0.000, 0.000, 0.000, 0.000, 0.000
Val(0.5-E) = 1.000, 0.013, 0.013, 0.000, 0.013
Val(0.5) = 1.000, 1.000, 1.000, 0.000, 1.000
Val(0.5+E) = 0.013, 1.000, 0.013, 0.000, 0.013
Val(1-E) = 0.000, 0.000, 1.000, 0.000, 0.000
Val(-0+1) = 0.000, 0.000, 1.000, 0.000, 0.000
Val(1) = 0.000, 0.000, 1.000, 0.000, 0.000
Val(+0+1) = 0.000, 0.000, 1.000, 0.000, 0.000
Val(val("+inf")) = 1.000, 1.000, 0.600, 0.000, 1.000
Val(val("-nan")) = 1.000, 1.000, 0.300, 0.000, 1.000
Val(val("nan")) = 1.000, 1.000, 0.300, 0.000, 1.000
Val(val("-0.33")) = 0.330, 0.330, 0.099, 0.000, 0.330

so the +-inf and -0.33 pattern results change with 'raw_wave' in yuqk.

When I run my v3.8 beta 2 compile and compare to yuqk without 
'raw_wave', I get the differences:

yuqk
----
Val(val("-inf")) = 0.000, 0.000, 0.000, 0.000, 0.000
Val(val("+inf")) = 0.000, 0.000, 1.000, 0.000, 0.000

v3.8 beta 2
-----------
Val(val("-inf")) = 0.000, 1.000, 0.000, 0.000, 0.000
Val(val("+inf")) = 0.000, 0.000, 0.000, 0.000, 0.000

Another issue potentially in play is that the official POV-Ray code had 
a small epsilon adder on the pattern return values meant to keep the 
values at 1.0 from snapping back to zero (some of the pattern 
implementations in POV-Ray proper defeated this code by doing their own 
clamping(*)). I don't recall the epsilon value used. The yuqk fork 
handles this 'essentially 1.0' condition with more care / precision.

(*) - I don't remember if gradient x was one of these. The yuqk code 
isn't clamping the gradient return values.

Bill P.

Post a reply to this message