POV-Ray : Newsgroups : povray.documentation.inbuilt : Mysterious function argument Server Time
5 Dec 2021 22:03:06 EST (-0500)
  Mysterious function argument (Message 11 to 20 of 20)  
<<< Previous 10 Messages Goto Initial 10 Messages
From: Kenneth
Subject: Re: Mysterious function argument
Date: 2 Oct 2021 15:35:00
Message: <web.6158b39c3ec630374cef624e6e066e29@news.povray.org>
William F Pokorny <ano### [at] anonymousorg> wrote:
> On 10/1/21 3:13 PM, Kenneth wrote:
>
>#declare F0 = function {pattern {bozo}}
> ..throws a fatal error just by itself, "Expected 'Rvalue to declare', pattern
> found instead"
>
>
> Hmm. Do others on windows see this sort of fail?
>
> The code parses for me with v3.7 and v3.8.
>

Good question. I just ran that 'pattern' version in v3.7.0 (Windows), and it
fails there too, same error message. I have a faint recollection that it parsed
OK in some earlier version of POV-ray like v3.6; but I could be wrong. It seems
to be a strange result in the Windows version nevertheless.


Post a reply to this message

From: Kenneth
Subject: Re: Mysterious function argument
Date: 2 Oct 2021 22:40:00
Message: <web.615917b73ec630374cef624e6e066e29@news.povray.org>
"Kenneth" <kdw### [at] gmailcom> wrote:
>
> #declare F0 = function {pattern {bozo}}
>  ..throws a fatal error just by itself, "Expected 'Rvalue to declare', pattern
>  found instead"
>
[and...]
> I just ran that 'pattern' version in v3.7.0 (Windows), and it
> fails there too, same error message...

MY ERROR! I mixed up my various tests :-\  Those two #declared functions DO
parse OK in Windows, in both v3.7.0 and v3.8.0 beta 1. Very sorry for the
confusion.

What I actually *tested* was this comparison, by mistake (but still interesting,
and maybe odd- but certainly off-topic here):

#declare PATT =
pattern{bozo}
... which fails parsing

or..

#declare PATT =
pigment{bozo}
...which parses successfully


Post a reply to this message

From: William F Pokorny
Subject: Re: Mysterious function argument
Date: 3 Oct 2021 08:23:06
Message: <6159a0aa$1@news.povray.org>
On 10/2/21 10:38 PM, Kenneth wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>>
>> #declare F0 = function {pattern {bozo}}
>>   ..throws a fatal error just by itself, "Expected 'Rvalue to declare', pattern
>>   found instead"
>>
> [and...]
>> I just ran that 'pattern' version in v3.7.0 (Windows), and it
>> fails there too, same error message...
> 
> MY ERROR! I mixed up my various tests :-\  Those two #declared functions DO
> parse OK in Windows, in both v3.7.0 and v3.8.0 beta 1. Very sorry for the
> confusion.
> 
> What I actually *tested* was this comparison, by mistake (but still interesting,
> and maybe odd- but certainly off-topic here):
> 
> #declare PATT =
> pattern{bozo}
> ... which fails parsing
> 
> or..
> 
> #declare PATT =
> pigment{bozo}
> ...which parses successfully
> 

Ah, good. Thanks for following up.

---
Aside: In my tcl wrapper for SDL, I have functions which allow me to 
declare Patterns, Warps, Radiosity, and other blocks(1) by name so they 
can just be references later by name as needed(1). The capability to 
pre-declare certain blocks by ID unfortunately isn't / wasn't 
implemented for some features of POV-Ray's SDL.

(1) - Underneath it creates macros which then are, repeatedly, inserted 
as needed.

The missing declare ability I trip over frequently, when writing raw 
SDL, is: #declare Warp00 = warp{...}.

Bill P.


Post a reply to this message

From: Bald Eagle
Subject: Re: Mysterious function argument
Date: 3 Oct 2021 12:10:00
Message: <web.6159d5353ec630371f9dae3025979125@news.povray.org>
William F Pokorny <ano### [at] anonymousorg> wrote:
> On 10/2/21 10:38 PM, Kenneth wrote:
> > "Kenneth" <kdw### [at] gmailcom> wrote:

I've gotten tripped up with the pattern vs pigment issue myself on numerous
occasions.  I suppose that's another thing that will have to be clarified with
some example scenes, etc.

> The missing declare ability I trip over frequently, when writing raw
> SDL, is: #declare Warp00 = warp{...}.

I might have tried that in the past, but the other one (IIRC) that I was
surprised at was the inability to predeclare a matrix for use in transforms.

There are a lot of things in SDL that have similar structures, but are
separate/isolated from each other.  matrices, splines, prisms --- it would be
nice if their internal data were all addressable/accessible like arrays.


Post a reply to this message

From: Alain Martel
Subject: Re: Mysterious function argument
Date: 3 Oct 2021 13:02:37
Message: <6159e22d$1@news.povray.org>


> (*) - POV-Ray proper has unique default color maps for each continuous 
> pattern. Be sure to always specify the color map you want!

> Bill P.
> 

Not quite accurate. Several continuous patterns do have an unique 
default colour_map, but not all.
Those don't have a specific default map, unless this counts as a 
specific colour_map
colour_map{[0 rgb 0][1 rgb 1]}
  :
bumps, spotted, leopard, quilted, ripples, waves, granite, crackle, 
marble, dents, spherical, boxed, cylindrical, planar.

Those have continuous gradients, but they repeat abruptly, and don't 
have default colour map :
gradient, onion.

The first two are identical to a bozo pattern, but without the colour_map.


Post a reply to this message

From: William F Pokorny
Subject: Re: Mysterious function argument
Date: 3 Oct 2021 17:33:45
Message: <615a21b9$1@news.povray.org>
On 10/3/21 1:02 PM, Alain Martel wrote:

> 
>> (*) - POV-Ray proper has unique default color maps for each continuous 
>> pattern. Be sure to always specify the color map you want!
> 
>> Bill P.
>>
> 
> Not quite accurate. Several continuous patterns do have an unique 
> default colour_map, but not all.
> Those don't have a specific default map, unless this counts as a 
> specific colour_map
> colour_map{[0 rgb 0][1 rgb 1]}

> bumps, spotted, leopard, quilted, ripples, waves, granite, crackle, 
> marble, dents, spherical, boxed, cylindrical, planar.
> 
> Those have continuous gradients, but they repeat abruptly, and don't 
> have default colour map :
> gradient, onion.
> 
> The first two are identical to a bozo pattern, but without the colour_map.

Thank you for the correction Alain.

Bill P.


Post a reply to this message

From: Kenneth
Subject: Re: Mysterious function argument
Date: 3 Oct 2021 19:10:00
Message: <web.615a364e3ec630374cef624e6e066e29@news.povray.org>
>
> // 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

From: Kenneth
Subject: Re: Mysterious function argument
Date: 3 Oct 2021 19:30:00
Message: <web.615a3c0e3ec630374cef624e6e066e29@news.povray.org>
"Bald Eagle" <cre### [at] netscapenet> wrote:

>
> ..the other one (IIRC) that I was
> surprised at was the inability to predeclare a matrix for use in transforms.
>

Works for me! (With a transform wrapper)

#declare VIRGINIA =
transform{
matrix < 1, 1, 0,
       0, 1, 0,
       0, 0, 1,
       0, 0, 0 >
       }

box{0,1
transform{VIRGINIA}
}


Post a reply to this message

From: William F Pokorny
Subject: Re: Mysterious function argument
Date: 4 Oct 2021 04:42:18
Message: <615abe6a$1@news.povray.org>
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

From: Kenneth
Subject: Re: Mysterious function argument
Date: 4 Oct 2021 14:55:00
Message: <web.615b4d143ec630374cef624e6e066e29@news.povray.org>
William F Pokorny <ano### [at] anonymousorg> wrote:
> On 10/3/21 7:05 PM, Kenneth wrote:
> >
> > 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?
>
> 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.

Ah! That's the 'missing piece of the puzzle' for me, in TWO ways:
1) It explains the successful  str  use in #debug-- because function F0 (the
bozo PATTERN) is a *scalar* function, not a multi-component color function. I
have always assumed that such pigment 'patterns', even though grayscale, still
contain 3 (or maybe 5) color components like <.3,.3,.3,0,0>. But they are just a
SINGLE value like .3.  Thanks! That clears up a long-standing misconception for
me.

2) It also explains to me why F0 (and F3), when actually used (as they are),
cannot have a dot operator like .gray added-- because the function is *scalar*
with only one component; the dot operator 'mechanism' assumes that there or 2 or
more components, and fails.

Much food for thought! I'm still 'putting all of the pieces together'...


Post a reply to this message

<<< Previous 10 Messages Goto Initial 10 Messages

Copyright 2003-2021 Persistence of Vision Raytracer Pty. Ltd.