>
> // povray +mv3.8 +iThisParseTest.inc
> #declare F0 = function {pattern {bozo}}
> #declare F1 = function {pigment {bozo}}
> #declare F2 = function {pigment {bozo
>          color_map {[0,rgbft 0][1,rgbft 1]}
>      }}
> #declare F3 = function { F0(x+1,y/2,z) }
> //#declare V0 = F0(x+1,y/2,z);
> // Parse Error: Float expected but vector or color expression found.
> #declare V1 = F1(1,2,3);
> #declare V2 = F2(1,2,3);
> #declare V3 = F3(1,2,3);
> #debug concat("\nV1 = ",vstr(5,V1,",",1,3),"\n")
> #debug concat("V2 = ",vstr(5,V2,",",1,3),"\nV3 = ",str(V3,1,3),"\n\n")
>
> #error "Parse Test. Stop early"
> //---
>

Hi again!

I've been looking at your code examples in detail for several days, and running
animation tests(!) while varying some of the function parameters (my usual
method of 'discovery' when I do not fully understand how certain code constructs
work... to *visually* see what's going on.) I am actually learning some new and
basic things about functions and their uses, that always mystified me--
specifically, plugging integers (or even floats) into a function, like your
      #declare V1 = F1(1,2,3);

In the past, Bald Eagle has valiantly tried to beat such stuff into my brain,
but I've been kind of a dunce and just didn't grasp it. :-\  Well, I think I've
finally had one of those 'eureka' moments.

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

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)

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.

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.

I apologize if a lot of this is off-topic-- but it's all fascinating and
instructive.

Post a reply to this message