On 10/3/21 7:05 PM, Kenneth wrote:
> My big discovery(??):
>  From experimenting, it looks like your integers (1,2,3) are pulling a
> *point-sample*  color  from  F1's  'continuous' bozo function,  from a specific
> location point in bozo's 3-D spatial pigment... the location being <1,2,3>.  And
> with the corresponding #debug results of  <0.000,1.000,0.000,0.000,0.000> as the
> color at that spatial point. Am I correct??

Close. When you make a function call to a function{pattern{}} or a 
function{pigment{}} you pass 3D positional values for x,y,z - always - 
to the pattern. In the example code this is the bozo pattern. The bozo 
pattern returns a single, continuous, scalar value in the [0..1)|] 
range. With functions, this single value can be returned directly - or 
it can be used as an index into a *_map and a vector of values from that 
map can be returned.

If you use function{pattern{bozo}}, you get the scalar pattern value and 
the function is considered a scalar function internal to POV-Ray.

If you use function{pigment{bozo}}, you get the 5D color vector from the 
*map at the map index of scalar value returned by the bozo pattern. 
Internal to POV_ray the function is then considered a vector function.

> 
> For example, by  giving your F1 and V1 functions some different values:
> #declare F1 = function{pigment{gradient x}}
> #declare V1 = F1(0.5,0,0);
> ..... the #debug result-- AND the resulting*single*  V1 color applied to a 1X1
> box
> as pigment{V1} )--  is  <0.500,0.500,0.500,0.000,0.000> -- the linear gray
> 'color' found halfway across the gradient x  map (which has a default grayscale
> color_map of its own).  Very neat!
> 
> (BTW, for animation tests, I can even do this:
> #declare V1 = F1(clock, 0.5 ,0.7) or whatever)
> 

Cool. Not something I've done and it could be useful. I've been toying 
with rtr/kla scenes as a way to document certain features - supposing I 
can get going some simple dynamic user control as the animation rolls 
ever onward...

> But going back to your original F1 and V1 functions:, I am curious about two of
> the #debug results:
> 
> Question 1:
>> v3.7/3.8 returns:
>> V1 = 0.000,1.000,0.000,0.000,0.000
> Yes, for me as well.
> 
>> The povr branch returns:
>> V1 = 0.421,0.421,0.421,0.000,0.000
>> (***) The povr branch defaults to rgb [0...1] color_maps for all
>> continuous patterns.
> *If*  I am correct about my analysis of function use as I described, your 0.421
> results are an interesting mystery to me-- especially for *all 3* red-green-blue
> channels, rather than just the green channel alone, as in Windows. The bozo
> pigment/pattern has discrete color areas that don't 'blend', AFAIK, so I'm
> curious as to which part(s) of your own color_map are producing that value...
> and for all 3 channels! My own logic tells me that the Windows and povr results
> should match-- that is, producing only a single value in the green channel,
> regardless of what that value might be.

The window / povr results would match except the povr branch uses a 
default color map of 0-1 for all continuous patterns - povr is set up 
differently so function{pigment{}} will often - but not always - return 
a different result.

> 
> Question 2:
> Your F3 function  is
>          #declare F3 = function { F0(x+1,y/2,z) }
> and the V3 function is
>          #declare V3 = F3(1,2,3);
> 
> Those have 3 components <x...,y...,z...>, yet your #debug for V3 uses just
> 'str' to pull out some kind of*single*  value (not 'vstr' to pull out all 3 or
> 5). I thought  str  would outright*fail*  with a 3-component function... yet it
> does not, interestingly. Is your F3 function 'continuous', or does it just
> create a single value? (Such distinctions are still a bit fuzzy to me.) But I'm
> equally curious as to where the final result of  0.489 comes from,
> mathematically (in 3-D space?). I can't figure that out, so far.

F3 is continuous because F0 is. F3 calls F0 which is defined as 
function{pattern{bozo}} as as such it is a scalar function - it returns 
a single value. F0 is continuous only because the bozo pattern is a 
continuous pattern. You could instead use the discrete checker pattern 
in F0 and it would then return discrete single values depending upon the 
3D location.

Aside: povr, at present, uses the default color maps as they are in 
POV-Ray proper for the half dozen or so discrete patters like checker, 
triangular, etc.

Hope my ramblings of some help.

Bill P.

Post a reply to this message