 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William F Pokorny <ano### [at] anonymous org> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> (*) - 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>
> // 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
