 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The reference manual (section 3.3.1.8.3, or 2.3.1.8.3 in the wiki) gives
the following as a legal function definition:
#declare foo3 = function(k1, k2, z, y) { x + y * z + k1 * y + k2 }
The function body refers to x, even though x is not one of the declared
arguments. But the function still works, somehow. The following scene
----------[BEGIN SCENE]----------
#version max (3.5, min (3.8, version));
global_settings { assumed_gamma 1 }
#declare foo3 = function(k1, k2, z, y) { x + y * z + k1 * y + k2 }
#declare G = foo3 (1, 2, 3, 4);
#debug concat ("G = ", str (G, 0, 1), "\n")
-----------[END SCENE]-----------
yields the output:
G = 18.0
Manually working through the function yields
x + y * z + k1 * y + k2
= x + 4 * 3 + 1 * 4 + 2
= x + 12 + 4 + 2
= x + 18
This suggests that POV-Ray pre-assigned 0 to x. That this construction
is given as an example suggests that this is a significant feature
(however inadvisable to use), and not just a parser glitch. Shouldn't
there be some explanation of this feature?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Cousin Ricky <ric### [at] yahoo com> wrote:
> This suggests that POV-Ray pre-assigned 0 to x. That this construction
> is given as an example suggests that this is a significant feature
> (however inadvisable to use), and not just a parser glitch. Shouldn't
> there be some explanation of this feature?
https://www.povray.org/documentation/3.7.0/r3_3.html#r3_3_1_6_6
"All built-in vector identifiers never change value. They are defined as though
the following lines were at the start of every scene.
#declare x = <1, 0, 0>;
#declare y = <0, 1, 0>;
#declare z = <0, 0, 1>;
#declare t = <0, 0, 0, 1>;
#declare u = <1, 0>;
#declare v = <0, 1>;
It shouldn't be like you say. But by the trunk of the fifth elephant that it is.
B. Gimeno
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"B. Gimeno" <nomail@nomail> wrote:
> Cousin Ricky <ric### [at] yahoocom> wrote:
>
> > This suggests that POV-Ray pre-assigned 0 to x. That this construction
> > is given as an example suggests that this is a significant feature
> > (however inadvisable to use), and not just a parser glitch. Shouldn't
> > there be some explanation of this feature?
>
> https://www.povray.org/documentation/3.7.0/r3_3.html#r3_3_1_6_6
>
> "All built-in vector identifiers never change value. They are defined as though
> the following lines were at the start of every scene.
>
> #declare x = <1, 0, 0>;
> #declare y = <0, 1, 0>;
> #declare z = <0, 0, 1>;
> #declare t = <0, 0, 0, 1>;
> #declare u = <1, 0>;
> #declare v = <0, 1>;
>
>
> It shouldn't be like you say. But by the trunk of the fifth elephant that it is.
>
> B. Gimeno
Right, but those are if you're accessing those values from the regular parser.
When you access them from the _function parser / VM_, you get a different set of
values. I made a post about this once - and of course I can't find it ATM.
AFAIK, if you use all of those identifiers in a function, they will all return
zero until you assign them a value by passing a value into the function call
using that variable name.
As Ricky says, it's certainly a useful "feature", but could probably use a good
post, some example code, or at some point, a more detailed explanation in the
documentation.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/30/21 1:27 PM, Bald Eagle wrote:
> AFAIK, if you use all of those identifiers in a function, they will all return
> zero until you assign them a value by passing a value into the function call
> using that variable name.
Excepting 't'. In the function body use of 't' where it is otherwise not
defined results in:
File 'wham.inc' line 19:
Parse Error:
Expected 'operand', 't' found instead
Fatal error in parser: Cannot parse input.
Render failed
Aside: I've been playing with other stuff most of the day, but
we have too that function { pattern {} } mode where you don't - cannot -
specify an argument list for the function. In that case I expect all the
values are whatever was passed to 'pattern' for x|u,y|v,z. Should verify
u and v set to x and y I guess, but expect that the case.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2021-09-30 1:03 PM (-4), B. Gimeno wrote:
>
> "All built-in vector identifiers never change value. They are defined as though
> the following lines were at the start of every scene.
>
> #declare x = <1, 0, 0>;
> #declare y = <0, 1, 0>;
> #declare z = <0, 0, 1>;
> #declare t = <0, 0, 0, 1>;
> #declare u = <1, 0>;
> #declare v = <0, 1>;
This does not apply in the context of function parameters. Function
parameters are not vector constants, but variable scalars.
In the foo3 example in particular, you can see that the pre-declared
value of x is not used: 0 does not equal <1, 0, 0>.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2021-09-30 1:27 PM (-4), Bald Eagle wrote:
>
> As Ricky says, it's certainly a useful "feature",
Hardly. I think it's a horrible feature.
My point was that if it's significant enough to use in an example, then it
> [...] could probably use a good
> post, some example code, or at some point, a more detailed explanation in the
> documentation.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Cousin Ricky <ric### [at] yahoocom> wrote:
> On 2021-09-30 1:27 PM (-4), Bald Eagle wrote:
> >
> > As Ricky says, it's certainly a useful "feature",
>
> Hardly. I think it's a horrible feature.
A horribly useful feature then. :D
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William F Pokorny <ano### [at] anonymousorg> wrote:
> Aside: I've been playing with other stuff most of the day, but
> we have too that function { pattern {} } mode where you don't - cannot -
> specify an argument list for the function. In that case I expect all the
> values are whatever was passed to 'pattern' for x|u,y|v,z. Should verify
> u and v set to x and y I guess, but expect that the case.
Ah, yeah.
I've had to wrangle a lot with those too.
I'm forever trying to do things like:
#declare F0 = function {pattern {bozo}}
and then do something like F0 (x+1, y/2, z)
or F0 = function {pattern {bozo} / <2, 1, 1>}
Functions are certainly challenging in the current implementation. It takes a
while to get used to what you can and cannot do, and there are a lot of "tricks"
to getting the syntax and expressions worked out to accomplish what one wants.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>
> I'm forever trying to do things like:
> #declare F0 = function {pattern {bozo}}
>
> and then do something like F0 (x+1, y/2, z)
>
> or F0 = function {pattern {bozo} / <2, 1, 1>}
>
Using v3.8.0 beta 1 in Windows, the following is interesting... or maybe
strange?
#declare F0 = function {pattern {bozo}}
...throws a fatal error just by itself, "Expected 'Rvalue to declare', pattern
found instead"
But...
#declare F0 = function {pigment {bozo}}
...works fine.
I had assumed that they were the same basic kind of entity (except for a
grayscale version when using 'pattern'.)
But more on-topic: Given a pigment instead, your 1st example does run, if a
function wrapper is included (plus an optional color_map, simply to make the
results more visually understandable). AND with only a single argument(?) pulled
out of the function, using a dot operator. For example, I can do some crazy
things with it...
pigment{
function{F0 (max(x,.5),pow(y,1.3),sqrt(z)).red}
color_map {[0,rgb 0][1,rgb <1,0,0>]}
}
Or .x for the function instead of .red
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
---
What I had in mind when asking myself whether u & v were also set with
function{pattern{}} was the function{pattern{function{}}} usage. It's
what one does to enable all the pattern modifiers for the the pattern
wrapped function(a). The answer is the u and v values are indeed set to
the x and y values passed through the pattern mechanism.
// povr parse test
#declare Fn00 = function {
pattern { function { f_boom(x,y,z,u,v,0) }
// turbulence, warps... - can applied
}
}
#declare V00 = Fn00(1,2,3);
//---
Returns:
f_boom
1(x) -> 1,
2(y) -> 2,
3(z) -> 3,
4(0) -> 1, // u
5(1) -> 2, // v
6(2) -> 0
(a) - This is easier to do in the povr branch due the raw_wave and
function_interval pattern modifiers.
---
Posting too the following v3.7..v4.0 generic code to highlight a couple
other function {pattern | pigment} traps / concerns.
// 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"
//---
v3.7/v.38 returns:
------------------
V1 = 0.000,1.000,0.000,0.000,0.000 (*)
V2 = 0.421,0.421,0.421,0.421,0.421 (***)
V3 = 0.489
The povr branch returns:
------------------------
V1 = 0.421,0.421,0.421,0.000,0.000 (**)
V2 = 0.421,0.421,0.421,0.421,0.421 (***)
V3 = 0.489
(*) - POV-Ray proper has unique default color maps for each continuous
pattern. Be sure to always specify the color map you want!
(**) - The povr branch defaults to rgb [0..1] color maps for all
continuous patterns.
(***) - The function{pigment{}} mechanism uses a full 5D color vector
which, in all current versions of POV-Ray of which I'm aware, use only
single float channels; Making this mechanism to pass around values more
problematic - especially for isosurface / parametric function use. The
function{pattern{}} mechanism returns a double float and it's faster
than using function{pigment{}}.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2021-10-02 à 09:02, William F Pokorny a écrit :
> (*) - 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:
> Le 2021-10-02 à 09:02, William F Pokorny a écrit :
>
>> (*) - 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
|
|
| |
| |
|
|
|
|
| |
|
|
