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