At first I mis-read the docs and thought I could have 6-component vectors, and
address them x, y, z, t, u, v.

I trimmed that to 5, and thought that maybe x, y, z, u, v was the way to go, but
I should have known better.

I need to use those last 2 values - what are they called?

Thanks!

Post a reply to this message

Le 07/07/2016 15:30, Bald Eagle a écrit :
> At first I mis-read the docs and thought I could have 6-component vectors, and
> address them x, y, z, t, u, v.
> 
> I trimmed that to 5, and thought that maybe x, y, z, u, v was the way to go, but
> I should have known better.
> 
> I need to use those last 2 values - what are they called?
> 

Bad, bad wiki (In the mood of "Bad, bad zoot", of "Monty Python and the Holy Grail")
You can access the component of 5D vector as a colour: red, green, blue, filter,
transmit

Yes, in that order. Which mean that .t == .filter, not .transmit

Post a reply to this message

So,
after more coffee, and more reading, and piecing together the breadcrumbs, and
recalling doing something like this in 2013,

I deduced that with

#declare Vector = <1, 2, 3>;

individual components can be addressed as:

Vector.x, Vector.y, and Vector.z
but also as
Vector.u, Vector.v, and Vector.t

the 4th "TERM" in a 4-term vector is filter, since POV-Ray interprets this as a
color expression.
so it's addressed as
Vector.filter (not Vector.f)
and a 5th term is transmit
so it's addressed as
Vector.transmit (not Vector.t - that would be Term 3)


Search terms (for future reference)
..x .y .z .t .u .v .filter .transmit
4-component vector
5-component vector
4-term vector
5-term vector
4-term color expression
5-term color expression

Post a reply to this message

Sorry, I was hasty and in error.
The following ought to be correct,
with a short scene file appended to demonstrate how it works.

> #declare Vector = <1, 2, 3>;
>
> individual components can be addressed as:
>
> Vector.x, Vector.y, and Vector.z
> but also as
> Vector.u, Vector.v, and Vector.z
>
> the 4th "TERM" in a 4-term vector is filter, since POV-Ray interprets this as a
> color expression.
> so it's addressed as
> Vector.filter (not Vector.f) or Vector.t
> and a 5th term is transmit
> so it's addressed as
> Vector.transmit (not Vector.t - that would be Term 4)
>
>
> Search terms (for future reference)
> .x .y .z .t .u .v .filter .transmit
> 4-component vector
> 5-component vector
> 4-term vector
> 5-term vector
> 4-term color expression
> 5-term color expression

########################################################################

#version 3.7;
global_settings {assumed_gamma 1.0}
#include "debug.inc"
  Set_Debug (true)

#declare Vector = <1, 2, 3, 4, 5>;

#debug concat( "Vector.x =        ", str(Vector.x, 3, 0), "\n")
#debug concat( "Vector.u =        ", str(Vector.u, 3, 0), "\n\n")
#debug concat( "Vector.y =        ", str(Vector.y, 3, 0), "\n")
#debug concat( "Vector.v =        ", str(Vector.v, 3, 0), "\n\n")
#debug concat( "Vector.z =        ", str(Vector.z, 3, 0), "\n\n")
#debug concat( "Vector.t =        ", str(Vector.t, 3, 0), "\n")
#debug concat( "Vector.filter =   ", str(Vector.filter, 3, 0), "\n\n")
#debug concat( "Vector.transmit = ", str(Vector.transmit, 3, 0), "\n\n")

Post a reply to this message

Le 07/07/2016 17:02, Bald Eagle a écrit :
> Sorry, I was hasty and in error.
> The following ought to be correct,
> with a short scene file appended to demonstrate how it works.
> 

Please see http://wiki.povray.org/content/Reference_Talk:Vector_Expressions

x,u,red -> 1st

y,v,green -> 2nd

z,blue -> 3rd

t,filter -> 4th

transmit -> 5th

>> #declare Vector = <1, 2, 3>;
>>
>> individual components can be addressed as:
>>
>> Vector.x, Vector.y, and Vector.z
>> but also as
>> Vector.u, Vector.v, and Vector.z
>>
>> the 4th "TERM" in a 4-term vector is filter, since POV-Ray interprets this as a
>> color expression.
>> so it's addressed as
>> Vector.filter (not Vector.f) or Vector.t
>> and a 5th term is transmit
>> so it's addressed as
>> Vector.transmit (not Vector.t - that would be Term 4)
>>
>>
>> Search terms (for future reference)
>> .x .y .z .t .u .v .filter .transmit
>> 4-component vector
>> 5-component vector
>> 4-term vector
>> 5-term vector
>> 4-term color expression
>> 5-term color expression
> 
> ########################################################################
> 
> #version 3.7;
> global_settings {assumed_gamma 1.0}
> #include "debug.inc"
>   Set_Debug (true)
> 
> #declare Vector = <1, 2, 3, 4, 5>;
> 
> #debug concat( "Vector.x =        ", str(Vector.x, 3, 0), "\n")
> #debug concat( "Vector.u =        ", str(Vector.u, 3, 0), "\n\n")
> #debug concat( "Vector.y =        ", str(Vector.y, 3, 0), "\n")
> #debug concat( "Vector.v =        ", str(Vector.v, 3, 0), "\n\n")
> #debug concat( "Vector.z =        ", str(Vector.z, 3, 0), "\n\n")
> #debug concat( "Vector.t =        ", str(Vector.t, 3, 0), "\n")
> #debug concat( "Vector.filter =   ", str(Vector.filter, 3, 0), "\n\n")
> #debug concat( "Vector.transmit = ", str(Vector.transmit, 3, 0), "\n\n")
> 
>

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:

> Please see http://wiki.povray.org/content/Reference_Talk:Vector_Expressions

> x,u,red -> 1st
> y,v,green -> 2nd
> z,blue -> 3rd
> t,filter -> 4th
> transmit -> 5th

Aha!   Yes, and I forgot about .red, .green, .blue, and especially .gray  :O

Also:
[F1] help (Windows) brings me this when I search for "gray":

3.3.1.7.5 Color Operators
Color vectors may be combined in expressions the same as float or vector values.
Operations are performed on a component by component basis. For example rgb
<1.0,0.5,0.2>*0.9 evaluates the same as rgb<1.0,0.5,0.2>*<0.9,0.9,0.9> or
rgb<0.9,0.45,0.18>. Other operations are done on a similar component by
component basis.

You may use the dot operator to extract a single component from a color. Suppose
the identifier Shade was previously defined as a color. Then Shade.red is the
float value of the red component of Shade. Similarly Shade.green, Shade.blue,
Shade.filter and Shade.transmit extract the float value of the other color
components. shade.gray returns the gray value of the color vector.

Post a reply to this message

On 7/7/2016 10:37 AM, Le_Forgeron wrote:
> Le 07/07/2016 15:30, Bald Eagle a écrit :
>> At first I mis-read the docs and thought I could have 6-component vectors, and
>> address them x, y, z, t, u, v.
>>
>> I trimmed that to 5, and thought that maybe x, y, z, u, v was the way to go, but
>> I should have known better.
>>
>> I need to use those last 2 values - what are they called?
>>
>
> Bad, bad wiki (In the mood of "Bad, bad zoot", of "Monty Python and the Holy Grail")
> You can access the component of 5D vector as a colour: red, green, blue, filter,
transmit
>
> Yes, in that order. Which mean that .t == .filter, not .transmit
>

OK ... so please be a bit more specific. What /exactly/ is "bad" and 
needs clarification. Comment on the talk page and I'll work it into the 
docs.

Post a reply to this message

Jim Holsenback <spa### [at] nothanksnet> wrote:

> OK ... so please be a bit more specific. What /exactly/ is "bad" and
> needs clarification. Comment on the talk page and I'll work it into the
> docs.

Jerome posted at
http://wiki.povray.org/content/Reference_Talk:Vector_Expressions

"The page Vector sends to Numeric Expression, but that one dismiss any details
about DOT_ITEM by sending back to Vector / Colour Pages, none of which cover the
subject."

I think that addressing the following ought to explicitly, clearly and
unambiguously describe what the values are as well as show examples of their
usage.

(I'm assuming that Vector.gray = (Vector.red + Vector.green + Vector.blue)/3
and that would be a helpful tidbit in the docs as well. )

#version 3.7;
global_settings {assumed_gamma 1.0}
#include "debug.inc"
  Set_Debug (true)

#declare Vector = <1, 2, 3, 4, 5>;

#debug concat( "Vector.x =        ", str(Vector.x, 3, 0), "\n")
#debug concat( "Vector.red =      ", str(Vector.red, 3, 0), "\n")
#debug concat( "Vector.u =        ", str(Vector.u, 3, 0), "\n\n")

#debug concat( "Vector.y =        ", str(Vector.y, 3, 0), "\n")
#debug concat( "Vector.green =    ", str(Vector.green, 3, 0), "\n")
#debug concat( "Vector.v =        ", str(Vector.v, 3, 0), "\n\n")

#debug concat( "Vector.blue =     ", str(Vector.blue, 3, 0), "\n")
#debug concat( "Vector.z =        ", str(Vector.z, 3, 0), "\n\n")

#debug concat( "Vector.t =        ", str(Vector.t, 3, 0), "\n")
#debug concat( "Vector.filter =   ", str(Vector.filter, 3, 0), "\n\n")

#debug concat( "Vector.transmit = ", str(Vector.transmit, 3, 0), "\n\n")

#debug concat( "Vector.gray = ", str(Vector.gray, 3, 0), "\n\n")

Post a reply to this message

Le 07/07/2016 19:16, Jim Holsenback a écrit :
> On 7/7/2016 10:37 AM, Le_Forgeron wrote:
>> Le 07/07/2016 15:30, Bald Eagle a écrit :
>>> At first I mis-read the docs and thought I could have 6-component vectors, and
>>> address them x, y, z, t, u, v.
>>>
>>> I trimmed that to 5, and thought that maybe x, y, z, u, v was the way to go, but
>>> I should have known better.
>>>
>>> I need to use those last 2 values - what are they called?
>>>
>>
>> Bad, bad wiki (In the mood of "Bad, bad zoot", of "Monty Python and the Holy
Grail")
>> You can access the component of 5D vector as a colour: red, green, blue, filter,
transmit
>>
>> Yes, in that order. Which mean that .t == .filter, not .transmit
>>
> 
> OK ... so please be a bit more specific. What /exactly/ is "bad" and needs
clarification. Comment on the talk page and I'll work it into the docs.

As stated in the talk page of Vector Expressions:
The page Vector sends to Numeric Expression, but that one dismiss any details about
DOT_ITEM by sending back to Vector / Colour Pages, none of which cover the subject.

In Numerics Expressions page, we have "The DOT_ITEM syntax is actually a vector or
color operator but it returns a float value. See Vector Operators or Color Operators
for details".

It reminds me of the house that get you mad, in Asterix (The twelve tasks of Asterix,
8th task): To get permit A38, you need the blue sheet... to get the blue sheet, you
need to apply with the pink and green ...

Here the loop is smaller, but no one would give a newbie the information about getting
a component from a vector (or colour).

I would suggest to leave "Numeric_Expressions" as it is so far, and adding, in both
"Vector_Expressions" and "Colour_Expressions", a dedicated section about getting
individual component out of a vector and colour.

In that section, the illustration of dot item with a basic example. Such as:

#declare Vector = < 1, 2, 3, 4, 5>;
#declare First_Component_1 = Vector.red;// 1
#declare First_Component_2 = Vector.u;// 1
#declare First_Component_3 = Vector.x;// 1
#declare Second_Component_1 = Vector.green;// 2
#declare Second_Component_2 = Vector.v;// 2
#declare Second_Component_3 = Vector.y;// 2
#declare Third_Component_1 = Vector.blue;// 3
#declare Third_Component_2 = Vector.z;// 3
#declare Fourth_Component_1 = Vector.filter;// 4
#declare Fourth_Component_2 = Vector.t;// 4
#declare Fifth_Component = Vector.transmit;// 5

(and repeat with a Colour= rgbtf <...> )

The section need a visible title (visible in Table of content)

// Above text was also added into the talk page. Best regards.

Post a reply to this message

Le 07/07/2016 19:39, Bald Eagle a écrit :
> (I'm assuming that Vector.gray = (Vector.red + Vector.green + Vector.blue)/3
> and that would be a helpful tidbit in the docs as well. )

Sorry to disappoint you, but gray formula is more complex (the weight of each of the 3
components are different)

It is documented at least in
http://wiki.povray.org/content/Documentation:Tutorial_Section_3.2

but it might be useful to repeat it in the "Colour_Expressions" page.

gray value = Red*29.7% + Green*58.9% + Blue*11.4%

Post a reply to this message

Please also note that is, and must be (currently) .grAy, not .grEy

> #debug concat( "Vector.gray = ", str(Vector.gray, 3, 0), "\n\n")


I'm sure these are part of the black magic that takes place in the POV-Ray
internals.  Perhaps .grEy could be added for those folks who prefer that
spelling.

Also note that "spelling" does not denote the casting of POV-Ray black magic
spells, nor does "casting" denote programmatically redefining the variable type
in the hazy and uncharted Void that is the POV-Ray SDL Parser.

Thank you.

Post a reply to this message

On 7/7/2016 1:48 PM, Le_Forgeron wrote:
> I would suggest to leave "Numeric_Expressions" as it is so far, and adding, in both
"Vector_Expressions" and "Colour_Expressions", a dedicated section about getting
individual component out of a vector and colour.

OK ... that's something I can work with, thanks for the clarification :-)

> In that section, the illustration of dot item with a basic example. Such as:
>
> #declare Vector = < 1, 2, 3, 4, 5>;
> #declare First_Component_1 = Vector.red;// 1
> #declare First_Component_2 = Vector.u;// 1
> #declare First_Component_3 = Vector.x;// 1
> #declare Second_Component_1 = Vector.green;// 2
> #declare Second_Component_2 = Vector.v;// 2
> #declare Second_Component_3 = Vector.y;// 2
> #declare Third_Component_1 = Vector.blue;// 3
> #declare Third_Component_2 = Vector.z;// 3
> #declare Fourth_Component_1 = Vector.filter;// 4
> #declare Fourth_Component_2 = Vector.t;// 4
> #declare Fifth_Component = Vector.transmit;// 5
>
> (and repeat with a Colour= rgbtf <...> )
>
> The section need a visible title (visible in Table of content)
>
> // Above text was also added into the talk page. Best regards.
>

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:

> Sorry to disappoint you,

Not at all - very interesting and great to learn and get a link.

Of course, while we're on the topic, can we address .hf ?
I tried Vector.hf and POV-Ray was sad and made the Founding Coders cry.
Does this need an include file of some sort to work?

Note: The .hf operator is experimental and will generate a warning.
fn_Pigm( ).gray to get the gray value of the color vector
gray value = Red*29.7% + Green*58.9% + Blue*11.4%

fn_Pigm( ).hf to get the height_field value of the color vector
hf value = (Red + Green/255)*0.996093

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:

> It is documented at least in
http://wiki.povray.org/content/Documentation:Tutorial_Section_3.2

Also,
That wiki link has incorrect information, leading an unsuspecting person to
believe that

fn_Pigm( ).x | fn_Pigm( ).u | fn_Pigm( ).red
to get the red value of the color vector
fn_Pigm( ).y | fn_Pigm( ).v | fn_Pigm( ).green
to get the green value of the color vector
fn_Pigm( ).z | fn_Pigm( ).blue
to get the blue value of the color vector
fn_Pigm( ).filter | fn_Pigm( ).f
to get the filter value of the color vector
fn_Pigm( ).transmit | fn_Pigm( ).t
to get the transmit value of the color vector

When:
there is no .f,
..t is for filter,
and .transmit is the only dot notation to access the 5th term.

Edit or delete that, or add an erratum note?

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:

> It reminds me of the house that get you mad, in Asterix (The twelve tasks of
Asterix, 8th task): To get permit A38, y
ou need the blue sheet... to get the blue sheet, you need to apply with the pink and
green ...

Well lookee here: !
The original 1976 animated film in its entirety  :)
https://www.youtube.com/watch?v=JOhRhq6Pr6g

Post a reply to this message

Le 07/07/2016 20:06, Bald Eagle a écrit :
> Le_Forgeron <jgr### [at] freefr> wrote:
> 
>> It is documented at least in
http://wiki.povray.org/content/Documentation:Tutorial_Section_3.2
> 
> Also,
> That wiki link has incorrect information, leading an unsuspecting person to
> believe that
> 
> fn_Pigm( ).x | fn_Pigm( ).u | fn_Pigm( ).red
> to get the red value of the color vector
> fn_Pigm( ).y | fn_Pigm( ).v | fn_Pigm( ).green
> to get the green value of the color vector
> fn_Pigm( ).z | fn_Pigm( ).blue
> to get the blue value of the color vector
> fn_Pigm( ).filter | fn_Pigm( ).f
> to get the filter value of the color vector
> fn_Pigm( ).transmit | fn_Pigm( ).t
> to get the transmit value of the color vector
> 
> When:
> there is no .f,
> ..t is for filter,
> and .transmit is the only dot notation to access the 5th term.
> 
> Edit or delete that, or add an erratum note?

Add a note in the talk page, at the end of it. If possible, provide also the text you
would like to see.

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:

> Add a note in the talk page, at the end of it. If possible, provide also the text
you would like to see.

I don't have a login for the wiki pages.
I suppose I need to create an account and a login if you want me to post things
over there, and it's not clear how to do that.

Post a reply to this message

On 7/7/2016 2:56 PM, Bald Eagle wrote:
> Le_Forgeron <jgr### [at] freefr> wrote:
>
>> Add a note in the talk page, at the end of it. If possible, provide also the text
you would like to see.
>
> I don't have a login for the wiki pages.
> I suppose I need to create an account and a login if you want me to post things
> over there, and it's not clear how to do that.
>
>
just post here ... turned off account creation a while ago due to 
excessive spamming

Post a reply to this message

Suggested language for that section:

This is a vector function, since it returns a 5-component color vector of the
rgbft type which can then be used in other functions to generate isosurfaces.
The function must be declared before the vector data can be accessed.
Any individual component of the rgbft vector can then be used just like any
other variable.  When using the vector component identifiers, you have to
specify exactly which component of the color vector should be used, and that is
done with the "dot notation."

For the examples below, refer to the above pigment function: fn_Pigm(x,y,z)

When the pigment function is evaluated for any <x, y, z>, it returns a color
vector as a result
That color vector has five "terms" or "components" which define the pigment in
3D space for every x, y, and z.
Several components have equivalent and interchangeable "dot" notations which is
useful depending upon what the vector is describing - a point in space, a color,
or uv-mapped points.

To specify these individual vector components, use the following "dot" types:

fn_Pigm( ).x | fn_Pigm( ).u | fn_Pigm( ).red
to get the red value of the color vector
(or the first term of _any_ 3, 4, or 5-term vector)
All 3 dot notations for the vector component refer to the same value and so give
the same result.  All of the below notations work in an analogous manner.

fn_Pigm( ).y | fn_Pigm( ).v | fn_Pigm( ).green
to get the green value of the color vector
(or the second term of _any_ 3, 4, or 5-term vector)

fn_Pigm( ).z | fn_Pigm( ).blue
to get the blue value of the color vector
(or the third term of _any_ 3, 4, or 5-term vector)

fn_Pigm( ).filter | fn_Pigm( ).t
to get the filter value of the color vector
(or the fourth term of _any_ 4 or 5-term vector)
[*For clarity, note that this is .filter, spelled-out, or .t _not_ .f]

fn_Pigm( ).transmit
to get the transmit value of the color vector
(or the fifth term of _any_ 5-term vector)
[*For clarity, note that this is .transmit, spelled-out, _not_ .t]

There is also a special-purpose operator, which returns a weighted grayscale
value:

fn_Pigm( ).gray to get the gray value of the color vector
The internal formula for calculating this gray value is as follows:
gray value = Red*0.297 + Green*0.589 + Blue*0.114

[The alternate spelling, ".grey", and .g are not supported as of version 3.7]

[Also, POV-Ray calculates heightfield values from vector data. Although that
value cannot currently be accessed with dot notation like the grayscale values,
the formula for calculating a heightfield value is:  hf value = (Red +
Green/255)*0.996093]

Post a reply to this message

On 7/7/2016 1:48 PM, Le_Forgeron wrote:
> I would suggest to leave "Numeric_Expressions" as it is so far, and adding, in both
"Vector_Expressions" and "Colour_Expressions", a dedicated section about getting
individual component out of a vector and colour.

http://wiki.povray.org/content/Documentation:Reference_Table_of_Contents#Scene_Description_Language

Post a reply to this message

Jim Holsenback <spa### [at] nothanksnet> wrote:

http://wiki.povray.org/content/Documentation:Reference_Table_of_Contents#Scene_Description_Language

That works.
Just a few small things-

"Fourth", not "Forth"

Perhaps mention .gray?

(curious - Was .hf eliminated, or was it never implemented?)

The errors here:
http://wiki.povray.org/content/Documentation:Tutorial_Section_3.2
Still exist (about halfway down the page)

Post a reply to this message

Le 10/07/2016 02:32, Jim Holsenback a écrit :
> On 7/7/2016 1:48 PM, Le_Forgeron wrote:
>> I would suggest to leave "Numeric_Expressions" as it is so far, and adding, in both
"Vector_Expressions" and "Colour_Expressions", a dedicated section about getting
individual component out of a vector and colour.
> 
>
http://wiki.povray.org/content/Documentation:Reference_Table_of_Contents#Scene_Description_Language
> 

nice.
On the Vector Expression page, I like the "Dot Item Access for Colors", yet I would
add a note in parenthesis after that link about 5D vector that can be considered as
color. Because the head of the page states that Vector can be 5D for colors, and
actually the vector in
Spline can also be 5D (as well as some vector functions can return up to 5 terms), so
it is not fully limited to colors.

Now, the single letter (x,y,z,t) is a nice sequence which could enjoy a fifth letter,
but I do not know the usage in math for 5D. Obviously u & v are already disqualified.

Post a reply to this message

Le 10/07/2016 05:16, Bald Eagle a écrit :
> Jim Holsenback <spa### [at] nothanksnet> wrote:
> 
>
http://wiki.povray.org/content/Documentation:Reference_Table_of_Contents#Scene_Description_Language
> 
> That works.
> Just a few small things-
> 
> "Fourth", not "Forth"
> 
> Perhaps mention .gray?
> 
> (curious - Was .hf eliminated, or was it never implemented?)
> 

No, .hf is still present, but it was always only available in the function{} section,
nowhere else.
.gray is both available for function{} and on usual colours.
There is an interest for .gray, to get an evaluation of the luminosity. I hardly see
an interest for .hf outside function{}.

> The errors here:
> http://wiki.povray.org/content/Documentation:Tutorial_Section_3.2
> Still exist (about halfway down the page)
> 
>

No error for that page, as it is a page about function{}. Just you cannot use .hf
outside of function{}.

Post a reply to this message

Am 10.07.2016 um 05:16 schrieb Bald Eagle:
> (curious - Was .hf eliminated, or was it never implemented?)

In the 3.6 docs, it is only mentioned in the isosurface tutorial, where
it is labeled "experimental", and in the source code it is even labeled
as unofficial, for MegaPOV compatibility only.

In fact, `.hf` is only available within functions; also, it is intended
to produce an "experimental feature" warning (but currently doesn't).

Post a reply to this message

Le 10/07/2016 12:41, clipka a écrit :
> Am 10.07.2016 um 05:16 schrieb Bald Eagle:
>> (curious - Was .hf eliminated, or was it never implemented?)
> 
> In the 3.6 docs, it is only mentioned in the isosurface tutorial, where
> it is labeled "experimental", and in the source code it is even labeled
> as unofficial, for MegaPOV compatibility only.
> 
> In fact, `.hf` is only available within functions; also, it is intended
> to produce an "experimental feature" warning (but currently doesn't).
> 

The code which set the flag is in comment in fncode.cpp ("// TODO
FIXME		Experimental_Flag |= EF_ISOFN;")

Now, should it remains an experimental feature... I do not know.

Post a reply to this message

On 07/09/2016 08:32 PM, Jim Holsenback wrote:
> On 7/7/2016 1:48 PM, Le_Forgeron wrote:
>> I would suggest to leave "Numeric_Expressions" as it is so far, and
>> adding, in both "Vector_Expressions" and "Colour_Expressions", a
>> dedicated section about getting individual component out of a vector
>> and colour.
>
>
http://wiki.povray.org/content/Documentation:Reference_Table_of_Contents#Scene_Description_Language
>
On the page:

http://wiki.povray.org/content?title=Reference:Color_Expressions

wondering about the brackets around rgbft? I think there is no reason 
for them.

COLOR_VECTOR:
     rgb <3_Term_Vector>    |
     rgbf <4_Term_Vector>   |
     rgbt <4_Term_Vector>   |
     [ rgbft ] <5_Term_Vector> |
     srgb <3_Term_Vector>   |
     srgbf <4_Term_Vector>  |
     srgbt <4_Term_Vector>  |
     srgbft <5_Term_Vector>

Bill P.

Post a reply to this message

Le 10/07/2016 14:30, William F Pokorny a écrit :
> On 07/09/2016 08:32 PM, Jim Holsenback wrote:
>> On 7/7/2016 1:48 PM, Le_Forgeron wrote:
>>> I would suggest to leave "Numeric_Expressions" as it is so far, and
>>> adding, in both "Vector_Expressions" and "Colour_Expressions", a
>>> dedicated section about getting individual component out of a vector
>>> and colour.
>>
>>
http://wiki.povray.org/content/Documentation:Reference_Table_of_Contents#Scene_Description_Language
>>
> On the page:
> 
> http://wiki.povray.org/content?title=Reference:Color_Expressions
> 
> wondering about the brackets around rgbft? I think there is no reason for them.
> 
> COLOR_VECTOR:
>     rgb <3_Term_Vector>    |
>     rgbf <4_Term_Vector>   |
>     rgbt <4_Term_Vector>   |
>     [ rgbft ] <5_Term_Vector> |
>     srgb <3_Term_Vector>   |
>     srgbf <4_Term_Vector>  |
>     srgbt <4_Term_Vector>  |
>     srgbft <5_Term_Vector>
> 
> Bill P.

Actually, they are meaningful : a 5D vector would be interpreted as a rgbft colour
when nothing else is present (aka rgbft is implict).

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:

> Actually, they are meaningful : a 5D vector would be interpreted as a rgbft colour
when nothing else is present (aka 
rgbft is implict).

Then shouldn't that actually be said - explicitly, right there in the
documentation, right at that spot, where it belongs?
Even if it's "redundant"?
Because the documentation's purpose is to illuminate the reader - at the time of
reading.

*** And I'll bet that if someone like Bill P. found it confusing, then that
means that thousands of others likely will, or they will attach no special
meaning and implication to it. To me, that's not "documentation".



Also - forgive me, but I don't understand what you're trying to say.
What do you mean by "when nothing else is present"?
A 5D vector would have to have SOME kind of context, correct?
It doesn't just float in an otherwise empty .pov file.

                      <1, 2, 3, 4, 5>

Even if it's one line out of 10,000 (#declare Vector = <1, 2, 3, 4, 5>;) does it
really have any "implicit meaning"?

I understand that lesser vector quantities may get automatically "promoted" to
5D vectors by the parser because the parser - or the person(s) who program(med)
the parser had that in mind.  So, in that sense, the _promotion_ has an implied
purpose and meaning, but until the 5D vector is actually used for something,
it's just - 5 numbers.  Isn't it?

I'm currently using them as convenient little 5-element arrays that I don't have
to initialize.  The first three values are spatial coordinates, and those last 2
values have nothing whatsoever to do with color.

Post a reply to this message

Am 10.07.2016 um 15:20 schrieb Bald Eagle:
> Le_Forgeron <jgr### [at] freefr> wrote:
> 
>> Actually, they are meaningful : a 5D vector would be interpreted
>> as a rgbft colour when nothing else is present (aka
>> rgbft is implict).
> 
> Then shouldn't that actually be said - explicitly, right there in the
> documentation, right at that spot, where it belongs?

Well, it does, exactly there, by virtue of those very square brackets.
It's the notation we use in all the syntax boxes in the reference
section: Like the vertical bar or three consecutive dots, square
brackets have a special meaning there.

> Even if it's "redundant"?
> Because the documentation's purpose is to illuminate the reader - at the time of
> reading.

And that's why the documentation later goes into more detail about
"Color Vectors", where it explicitly states: "Under some circumstances,
if the vector expression is a 5 component expression or there is a color
identifier in the expression then the rgbft keyword is optional."


> Also - forgive me, but I don't understand what you're trying to say.
> What do you mean by "when nothing else is present"?
> A 5D vector would have to have SOME kind of context, correct?
> It doesn't just float in an otherwise empty .pov file.

The context is described in the syntax box. In a nutshell, the box says
(among other things) that wherever POV-Ray expects or allows a COLOR, it
specifically allows a raw 5-term vector with no preceding `rgbft`.

Note that the syntax box technically doesn't say anything about the
/semantics/ of specifying a raw 5-term vector where a COLOR is allowed.
Most notably, it doesn't say anything about what happens if both a COLOR
and a VECTOR would be allowed, as is the case on the right-hand side of
a `#declare` statement. (As a matter of fact, a raw 5-term vector is
only interpreted as a colour when POV-Ray specifically /expects/ a COLOR.)

Post a reply to this message

On 07/10/2016 08:37 AM, Le_Forgeron wrote:
> Le 10/07/2016 14:30, William F Pokorny a écrit :
>> On 07/09/2016 08:32 PM, Jim Holsenback wrote:
>>> On 7/7/2016 1:48 PM, Le_Forgeron wrote:
>>>> I would suggest to leave "Numeric_Expressions" as it is so far, and
>>>> adding, in both "Vector_Expressions" and "Colour_Expressions", a
>>>> dedicated section about getting individual component out of a vector
>>>> and colour.
>>>
>>>
http://wiki.povray.org/content/Documentation:Reference_Table_of_Contents#Scene_Description_Language
>>>
>> On the page:
>>
>> http://wiki.povray.org/content?title=Reference:Color_Expressions
>>
>> wondering about the brackets around rgbft? I think there is no reason for them.
>>
>> COLOR_VECTOR:
>>      rgb <3_Term_Vector>    |
>>      rgbf <4_Term_Vector>   |
>>      rgbt <4_Term_Vector>   |
>>      [ rgbft ] <5_Term_Vector> |
>>      srgb <3_Term_Vector>   |
>>      srgbf <4_Term_Vector>  |
>>      srgbt <4_Term_Vector>  |
>>      srgbft <5_Term_Vector>
>>
>> Bill P.
>
> Actually, they are meaningful : a 5D vector would be interpreted as a rgbft colour
when nothing else is present (aka rgbft is implict).
>
OK. If the optionality is what we are trying to indicate, I think we 
probably want something like :

COLOR_VECTOR:
      [rgb] float            | (promoted to 3 value vector)
      [rg0] <2 Term Vector>  |
      [rgb] <3_Term_Vector>  |
      [rgbf] <4_Term_Vector> |
      rgbt <4_Term_Vector>   |
      [ rgbft ] <5_Term_Vector> |
      srgb <3_Term_Vector>   |
      srgbf <4_Term_Vector>  |
      srgbt <4_Term_Vector>  |
      srgbft <5_Term_Vector>

Bill P.

Post a reply to this message

On 07/10/2016 11:30 AM, William F Pokorny wrote:
> On 07/10/2016 08:37 AM, Le_Forgeron wrote:
...
> OK. If the optionality is what we are trying to indicate, I think we
> probably want something like :
>
> COLOR_VECTOR:
>       [rgb] float            | (promoted to 3 value vector)
>       [rg0] <2 Term Vector>  |
>       [rgb] <3_Term_Vector>  |
>       [rgbf] <4_Term_Vector> |
>       rgbt <4_Term_Vector>   |
>       [ rgbft ] <5_Term_Vector> |
>       srgb <3_Term_Vector>   |
>       srgbf <4_Term_Vector>  |
>       srgbt <4_Term_Vector>  |
>       srgbft <5_Term_Vector>
>
> Bill P.

Argh... Just popped into my head the line:

[rg0] <2 Term Vector>  |

is more like:

[rgb] <2 Term Vector>  | (blue is zero in this case)

there is of course no "rg0". :-)

Bill P.

Post a reply to this message

Am 10.07.2016 um 17:30 schrieb William F Pokorny:

> OK. If the optionality is what we are trying to indicate, I think we
> probably want something like :
> 
> COLOR_VECTOR:
>      [rgb] float            | (promoted to 3 value vector)
>      [rg0] <2 Term Vector>  |
>      [rgb] <3_Term_Vector>  |
>      [rgbf] <4_Term_Vector> |
>      rgbt <4_Term_Vector>   |
>      [ rgbft ] <5_Term_Vector> |
>      srgb <3_Term_Vector>   |
>      srgbf <4_Term_Vector>  |
>      srgbt <4_Term_Vector>  |
>      srgbft <5_Term_Vector>

Since floats and less-than-5-term vectors are automatically promoted to
5-term vectors this is not necessary. To the contrary, what you suggest
might be misinterpreted to imply that e.g. `rgbft <4_Term_Vector>` would
be invalid, when in fact it is perfectly legal.

Also, there is no `rg0` keyword, so that's plain nonsense right there.

Post a reply to this message

On 07/10/2016 11:50 AM, clipka wrote:
> Am 10.07.2016 um 17:30 schrieb William F Pokorny:
>
>> OK. If the optionality is what we are trying to indicate, I think we
>> probably want something like :
>>
>> COLOR_VECTOR:
>>       [rgb] float            | (promoted to 3 value vector)
>>       [rg0] <2 Term Vector>  |
>>       [rgb] <3_Term_Vector>  |
>>       [rgbf] <4_Term_Vector> |
>>       rgbt <4_Term_Vector>   |
>>       [ rgbft ] <5_Term_Vector> |
>>       srgb <3_Term_Vector>   |
>>       srgbf <4_Term_Vector>  |
>>       srgbt <4_Term_Vector>  |
>>       srgbft <5_Term_Vector>
>
> Since floats and less-than-5-term vectors are automatically promoted to
> 5-term vectors this is not necessary. To the contrary, what you suggest
> might be misinterpreted to imply that e.g. `rgbft <4_Term_Vector>` would
> be invalid, when in fact it is perfectly legal.
>
> Also, there is no `rg0` keyword, so that's plain nonsense right there.
>
(Indeed. I'm about half nonsensical in any given moment. ;-) See my own, 
earlier correction to rg0)

The block under discussion is in the section:

http://wiki.povray.org/content?title=Reference:Color_Expressions

where we describe how a user can specify color as in:

pigment { color .... }

In this context it seems to me we care not that a 5 term vector is 
otherwise treated by POV-Ray as a color vector by default, but whether 
we need to specify the rgb... whatever string in the color 
specification. In the latter context I think what I have written is what 
happens. All these are today valid ways to specify color:

color 1           // We get white
color <1,1>       // We get yellow
color <1,1,1>     // White
color <1,1,1,1>   // Clear by filter
color <1,1,1,1,1> // Again clear

Bill P.

Post a reply to this message

Le 10/07/2016 17:49, William F Pokorny a écrit :
> On 07/10/2016 11:30 AM, William F Pokorny wrote:
>> On 07/10/2016 08:37 AM, Le_Forgeron wrote:
> ...
>> OK. If the optionality is what we are trying to indicate, I think we
>> probably want something like :
>>
>> COLOR_VECTOR:
>>       [rgb] float            | (promoted to 3 value vector)
>>       [rg0] <2 Term Vector>  |
>>       [rgb] <3_Term_Vector>  |
>>       [rgbf] <4_Term_Vector> |
>>       rgbt <4_Term_Vector>   |
>>       [ rgbft ] <5_Term_Vector> |
>>       srgb <3_Term_Vector>   |
>>       srgbf <4_Term_Vector>  |
>>       srgbt <4_Term_Vector>  |
>>       srgbft <5_Term_Vector>
>>
>> Bill P.
> 
> Argh... Just popped into my head the line:
> 
> [rg0] <2 Term Vector>  |
> 
> is more like:
> 
> [rgb] <2 Term Vector>  | (blue is zero in this case)
> 
> there is of course no "rg0". :-)
> 
> Bill P.

IMHO, you are missing that, at another level, the missing terms are automatically
created from existing input when needed.

float get promoted to 3D, 2D get completed to 3D with 0 as the last term and so on
(including 2D expended to 4D and 5D when needed)... but some too-short expression can
give you a warning (such as "Suspicious expression after rgbf.")
On the same line, providing a 5D for a 4D (e.g. rgbf) will also give you a warning
(that's not a promotion/extension, rather a reduction).
Yet, it is valid syntax. (even if the 5th term get ignored).

On the same line, when "<N_Term_Vector>" is used, it can be any expression (including
+,-,* and /... and even some within ?: ternary operator ) which result in such values,
at the end.
You are going to have very hard to have a readable syntax if you want to list all
possible cases for just "rgb xxxxx"

Post a reply to this message

Am 10.07.2016 um 18:21 schrieb William F Pokorny:

> The block under discussion is in the section:
> 
> http://wiki.povray.org/content?title=Reference:Color_Expressions
> 
> where we describe how a user can specify color as in:
> 
> pigment { color .... }
> 
> In this context it seems to me we care not that a 5 term vector is
> otherwise treated by POV-Ray as a color vector by default, but whether
> we need to specify the rgb... whatever string in the color
> specification. In the latter context I think what I have written is what
> happens. All these are today valid ways to specify color:
> 
> color 1           // We get white
> color <1,1>       // We get yellow
> color <1,1,1>     // White
> color <1,1,1,1>   // Clear by filter
> color <1,1,1,1,1> // Again clear

If you look at it that way, you forget

  color rgb 1
  color rgb <1,1>
  color rgb <1,1,1>
  color rgbf 1
  color rgbf <1,1>
  color rgbf <1,1,1>
  color rgbf <1,1,1,1>
  color rgbt 1
  color rgbt <1,1>
  color rgbt <1,1,1>
  color rgbt <1,1,1,1>
  color rgbft 1
  color rgbft <1,1>
  color rgbft <1,1,1>
  color rgbft <1,1,1,1>
  color rgbft <1,1,1,1,1>
  color srgb 1
  color srgb <1,1>
  color srgb <1,1,1>
  color srgbf 1
  color srgbf <1,1>
  color srgbf <1,1,1>
  color srgbf <1,1,1,1>
  color srgbt 1
  color srgbt <1,1>
  color srgbt <1,1,1>
  color srgbt <1,1,1,1>
  color srgbft 1
  color srgbft <1,1>
  color srgbft <1,1,1>
  color srgbft <1,1,1,1>
  color srgbft <1,1,1,1,1>

Also, you forget

  color rgb <1,1,1,1>
  color rgb <1,1,1,1,1>
  color rgbf <1,1,1,1,1>
  color rgbt <1,1,1,1,1>
  color srgb <1,1,1,1>
  color srgb <1,1,1,1,1>
  color srgbf <1,1,1,1,1>
  color srgbt <1,1,1,1,1>

which are also accepted (even though they raise a warning).

You don't really want to list all these special cases individually in
the syntax box for COLOR (or at least I /hope/ you don't want to ;)).

As for the factoid that "a 5 term vector is otherwise treated by POV-Ray
as a color vector by default", this is technically wrong.

The truth is that `.x`, `.y`, `.z` ect., as well as `.red`, `.green",
`.blue` etc., are all allowed for both vectors and colours, and both
colours and vectors can be used interchangeably, so the difference
between the two is pretty obscure (which is a property of POV-Ray's SDL
that I have always detested).

As for the `rgbft` being optional in a colour statement, this also does
/not/ mean that 5-term vectors are treated as colours by default.
Instead, it means that if the parser /specifically/ expects a colour, an
arbitrary vector is also legal (and is the very mechanism by which
vectors can be used in place of colours).

Post a reply to this message

Am 10.07.2016 um 13:03 schrieb Le_Forgeron:
> Le 10/07/2016 12:41, clipka a écrit :
>> Am 10.07.2016 um 05:16 schrieb Bald Eagle:
>>> (curious - Was .hf eliminated, or was it never implemented?)
>>
>> In the 3.6 docs, it is only mentioned in the isosurface tutorial, where
>> it is labeled "experimental", and in the source code it is even labeled
>> as unofficial, for MegaPOV compatibility only.
>>
>> In fact, `.hf` is only available within functions; also, it is intended
>> to produce an "experimental feature" warning (but currently doesn't).
>>
> 
> The code which set the flag is in comment in fncode.cpp ("// TODO
FIXME		Experimental_Flag |= EF_ISOFN;")
> 
> Now, should it remains an experimental feature... I do not know.

The code is bogus (the constant 0.996093 in the formula is not only a
"magic" value, but most certainly wrong), so it sure as hell shouldn't
become canonical in its current form.

Post a reply to this message

On 07/10/2016 12:32 PM, Le_Forgeron wrote:
> Le 10/07/2016 17:49, William F Pokorny a écrit :
>> On 07/10/2016 11:30 AM, William F Pokorny wrote:
>>> On 07/10/2016 08:37 AM, Le_Forgeron wrote:
>> ...
>>> OK. If the optionality is what we are trying to indicate, I think we
>>> probably want something like :
>>>
>>> COLOR_VECTOR:
>>>        [rgb] float            | (promoted to 3 value vector)
>>>        [rg0] <2 Term Vector>  |
>>>        [rgb] <3_Term_Vector>  |
>>>        [rgbf] <4_Term_Vector> |
>>>        rgbt <4_Term_Vector>   |
>>>        [ rgbft ] <5_Term_Vector> |
>>>        srgb <3_Term_Vector>   |
>>>        srgbf <4_Term_Vector>  |
>>>        srgbt <4_Term_Vector>  |
>>>        srgbft <5_Term_Vector>
>>>
>>> Bill P.
>>
>> Argh... Just popped into my head the line:
>>
>> [rg0] <2 Term Vector>  |
>>
>> is more like:
>>
>> [rgb] <2 Term Vector>  | (blue is zero in this case)
>>
>> there is of course no "rg0". :-)
>>
>> Bill P.
>
> IMHO, you are missing that, at another level, the missing terms are automatically
created from existing input when needed.
>
> float get promoted to 3D, 2D get completed to 3D with 0 as the last term and so on
(including 2D expended to 4D and 5D when needed)... but some too-short expression can
give you a warning (such as "Suspicious expression after rgbf.")
> On the same line, providing a 5D for a 4D (e.g. rgbf) will also give you a warning
(that's not a promotion/extension, rather a reduction).
> Yet, it is valid syntax. (even if the 5th term get ignored).
>
> On the same line, when "<N_Term_Vector>" is used, it can be any expression
(including +,-,* and /... and even some within ?: ternary operator ) which result in
such values, at the end.
> You are going to have very hard to have a readable syntax if you want to list all
possible cases for just "rgb xxxxx"
>
(Christoph, I saw your response too, but will respond just here)

I think I generally understand the promotion and demotion going on when 
colors are expected and we have various floats or vectors as the 
starting point/right-hand-argument.

When I originally questioned the line:

[ rgbft ] <5_Term_Vector> |

it was because our saying rgbft was optional per the brackets in just 
the five term vector case did not make sense to me for a syntax 
specification.

That "...the missing terms are automatically created from existing input 
when needed" is the point.

The rgb string is also optional for a float and multiple vector 
specifications. Why is it we are not showing the user it is optional 
with brackets as in [rgb], but doing it for rgbft and the 5 term vector 
case?

It seems to me for a syntax specification for color vectors we should be 
completely truthful about whether the string is optional, or always 
vague, listing just the various ".rgb.." strings.

Bill P.

Post a reply to this message

Le 10/07/2016 19:43, clipka a écrit :
> Am 10.07.2016 um 13:03 schrieb Le_Forgeron:
>> Le 10/07/2016 12:41, clipka a écrit :
>>> Am 10.07.2016 um 05:16 schrieb Bald Eagle:
>>>> (curious - Was .hf eliminated, or was it never implemented?)
>>>
>>> In the 3.6 docs, it is only mentioned in the isosurface tutorial, where
>>> it is labeled "experimental", and in the source code it is even labeled
>>> as unofficial, for MegaPOV compatibility only.
>>>
>>> In fact, `.hf` is only available within functions; also, it is intended
>>> to produce an "experimental feature" warning (but currently doesn't).
>>>
>>
>> The code which set the flag is in comment in fncode.cpp ("// TODO
FIXME		Experimental_Flag |= EF_ISOFN;")
>>
>> Now, should it remains an experimental feature... I do not know.
> 
> The code is bogus (the constant 0.996093 in the formula is not only a
> "magic" value, but most certainly wrong), so it sure as hell shouldn't
> become canonical in its current form.
> 

IIRC, the heigth field interpretation of the color (when coming from indexed picture)
was & is also bogus (kept as such for backward compatibility)

(0.996093 looks like 255/256 : .99609375000000000000000000000000000000000000000000)

(See imageutil.cpp, image_height_at() function, due to history an 8 bit value bbbbbbbb
is promoted into 16 bits as bbbbbbbb00000000, making 65535 an unreachable value;
Notice that 0xFF00 / 0x10000 is also the same magic value)



Looking at the code of fncode.cpp,
the operations would resume to (r+g/255)*255/256

For r=g=1.0 (max normal value), it result in 1.0 (also the expected max value).
Excepted that the constant is truncated at the 7th significant decimal digit, which is
also the usual precision of double.
So, it is probably always bad, but nobody would be able to see it at that precision,
and because it is truncated to a lower multiplier, there is no overflow, and rounding
error might get you a 1.0 (not tested).

Post a reply to this message

Le 10/07/2016 20:50, Le_Forgeron a écrit :
>  which is also the usual precision of double.

My bad, 7th decimal digit is the precision of float, not double.

Post a reply to this message

Am 10.07.2016 um 20:50 schrieb Le_Forgeron:

>>>> In fact, `.hf` is only available within functions; also, it is intended
>>>> to produce an "experimental feature" warning (but currently doesn't).
>>>>
>>>
>>> The code which set the flag is in comment in fncode.cpp ("// TODO
FIXME		Experimental_Flag |= EF_ISOFN;")
>>>
>>> Now, should it remains an experimental feature... I do not know.
>>
>> The code is bogus (the constant 0.996093 in the formula is not only a
>> "magic" value, but most certainly wrong), so it sure as hell shouldn't
>> become canonical in its current form.
>>
> 
> IIRC, the heigth field interpretation of the color (when coming from indexed
picture)
> was & is also bogus (kept as such for backward compatibility)

Yup. Not directly related though.

> (0.996093 looks like 255/256 : .99609375000000000000000000000000000000000000000000)

That's what I think, too.

Post a reply to this message

Am 10.07.2016 um 20:32 schrieb William F Pokorny:

> I think I generally understand the promotion and demotion going on when
> colors are expected and we have various floats or vectors as the
> starting point/right-hand-argument.
> 
> When I originally questioned the line:
> 
> [ rgbft ] <5_Term_Vector> |
> 
> it was because our saying rgbft was optional per the brackets in just
> the five term vector case did not make sense to me for a syntax
> specification.
> 
> That "...the missing terms are automatically created from existing input
> when needed" is the point.
> 
> The rgb string is also optional for a float and multiple vector
> specifications. Why is it we are not showing the user it is optional
> with brackets as in [rgb], but doing it for rgbft and the 5 term vector
> case?

Because this allows to put a bit of semantic information between the
lines: If none of the colour keywords is specified at all, behaviour is
as if `rgbft` was used.

The only sensible alternatives (and the ones most closely matching the
actual internal processing) would be to specify either

COLOR_VECTOR:
     rgb <3_Term_Vector>    |
     rgbf <4_Term_Vector>   |
     rgbt <4_Term_Vector>   |
     rgbft <5_Term_Vector>  |
     srgb <3_Term_Vector>   |
     srgbf <4_Term_Vector>  |
     srgbt <4_Term_Vector>  |
     srgbft <5_Term_Vector> |
     <5_Term_Vector>

which loses that between-the-lines information about the semantics, or

COLOR_VECTOR:
     [ rgb | rgbf | rgbt | rgbft | srgb | srgbf | srgbt |
     srgbft ] VECTOR

which discards even more information about the semantics.

Post a reply to this message

On 07/10/2016 05:14 PM, clipka wrote:
> Am 10.07.2016 um 20:32 schrieb William F Pokorny:
>>
>> The rgb string is also optional for a float and multiple vector
>> specifications. Why is it we are not showing the user it is optional
>> with brackets as in [rgb], but doing it for rgbft and the 5 term vector
>> case?
>
> Because this allows to put a bit of semantic information between the
> lines: If none of the colour keywords is specified at all, behaviour is
> as if `rgbft` was used.
>
> The only sensible alternatives (and the ones most closely matching the
> actual internal processing) would be to specify either
>
> COLOR_VECTOR:
>       rgb <3_Term_Vector>    |
>       rgbf <4_Term_Vector>   |
>       rgbt <4_Term_Vector>   |
>       rgbft <5_Term_Vector>  |
>       srgb <3_Term_Vector>   |
>       srgbf <4_Term_Vector>  |
>       srgbt <4_Term_Vector>  |
>       srgbft <5_Term_Vector> |
>       <5_Term_Vector>
>
> which loses that between-the-lines information about the semantics, or
>
> COLOR_VECTOR:
>       [ rgb | rgbf | rgbt | rgbft | srgb | srgbf | srgbt |
>       srgbft ] VECTOR
>
> which discards even more information about the semantics.
>
Alright. Thanks everyone for the time spent due my question.

Bill P.

Post a reply to this message

> No error for that page, as it is a page about function{}. Just you cannot use .hf
outside of function{}.


Sorry to keep this thing going for this long, but perhaps someone can post some
working code to clarify HOW to use .hf "IN" (a) function.

I tried to implement the (partial) example code on the referenced documentation
page by issuing the directive:

#debug concat( "fn_Pigm(1, 2, 3).hf  = ", str(fn_Pigm(1, 2, 3).hf, 3, 0),
"\n\n")

[ At first I used it literally, as:

#debug concat( "fn_Pigm().hf  = ", str(fn_Pigm().hf, 3, 0), "\n\n")

even though I expected, and got, an error:
....VectorComponents.pov" line 44: Parse Error: Expected 'numeric expression', )
found instead

so the docs should clarify the need for a vector argument]

and got:

.... VectorComponents.pov" line 41: Parse Error: Expected 'x, y, z or color
component', undeclared identifier 'hf' found instead

doing:

#declare Pigment =
 pigment {
  agate
  color_map {
   [0 color rgb 0]
   [1 color rgb 1]
  } // end color map
 } // end pigment

#declare fn_Pigm =
function {
pigment {Pigment}
} // end function

I cannot do:

#declare fn_Pigm =
function {
pigment {Pigment}.hf
} // end function

.... VectorComponents.pov" line 41: Parse Error: No matching } in '{', . (period)
found instead

or:

#declare fn_Pigm =
function {
pigment {Pigment.hf}
} // end function

.... VectorComponents.pov" line 41: Parse Error: No matching } in 'pigment', .
(period) found instead


Since so much has been covered and clarified, I just wanted to address this one
last (?) loose thread.

Post a reply to this message

Am 16.07.2016 um 14:47 schrieb Bald Eagle:

> I tried to implement the (partial) example code on the referenced documentation
> page by issuing the directive:
> 
> #debug concat( "fn_Pigm(1, 2, 3).hf  = ", str(fn_Pigm(1, 2, 3).hf, 3, 0),
> "\n\n")
> 
> [ At first I used it literally, as:
> 
> #debug concat( "fn_Pigm().hf  = ", str(fn_Pigm().hf, 3, 0), "\n\n")
> 
> even though I expected, and got, an error:
> .....VectorComponents.pov" line 44: Parse Error: Expected 'numeric expression', )
> found instead
> 
> so the docs should clarify the need for a vector argument]

Uh... there is nothing missing in the docs there. fn_Pigm() is a
function, and therefore requires parameters when invoked. Simple as that.

> and got:
> 
> ..... VectorComponents.pov" line 41: Parse Error: Expected 'x, y, z or color
> component', undeclared identifier 'hf' found instead

That is to be expected; as mentioned before, '.hf' is only available in
functions.


> I cannot do:
> 
> #declare fn_Pigm =
> function {
> pigment {Pigment}.hf
> } // end function

You need to do:

#declare fn_Pigm = function { pigment { Pigment } }
#declare fn_Hf = function { fn_Pigm(x,y,z).hf }

The first line declares a pigment function, which returns a colour
(well, actually I think it's a vector; but since I haven't examined the
code closely, I'm not exactly sure).

The second line invokes the function, computes the .hf value from the
resulting colour, and returns it as a scalar.

Post a reply to this message

On 16-7-2016 14:47, Bald Eagle wrote:
> Sorry to keep this thing going for this long, but perhaps someone can post some
> working code to clarify HOW to use .hf "IN" (a) function.
>

I have an example right at hand. Two steps:

//step 1:
#declare F_HF_00 =
function {
   pigment {
     image_map {
       tga "MyOwn.tga" gamma 1.0
       map_type 0
       interpolate 2
     }
     warp {repeat x}
     warp {repeat y}
     scale 50
     warp {
       turbulence <1.5, 9, 1.5>
       octaves 1 //[6]
       lambda 1  //[2]
       omega 0.2 //[0.5]
     }
     scale 1/50
   }
}

//step 2:
#declare Landscape =
height_field {
   function 2000, 2000 {F_HF_00(x,y,z).hf}
   //smooth
   translate <-0.5, -0.5, -0.5>
   scale <-1, 1, 1>
   scale <MyScale, 100, MyScale>
   clipped_by {
     box {
       <-0.5, -0.5, -0.5>, <0.5, 0.5, 0.5>
       scale <MyScale, 1, MyScale> * <0.99, 500, 0.99>
     }
   }
}

Note: The clipped_by line might be necessary to cut out the artefacts 
generated by the function at the borders of the height_field.


-- 
Thomas

Post a reply to this message

Bald Eagle wrote:
> At first I mis-read the docs and thought I could have 6-component vectors, and
> address them x, y, z, t, u, v.
>
> I trimmed that to 5, and thought that maybe x, y, z, u, v was the way to go, but
> I should have known better.
>
> I need to use those last 2 values - what are they called?
>
> Thanks!
>
>

Betcha thought you were asking a totally simple question.  :)

Sherry "Been Doing This For Twenty-Plus Years and Never Cease To Be 
Enlightened, Educated, and Amazed" Shaw

-- 
#macro T(E,N)sphere{x,.4rotate z*E*60translate y*N pigment{wrinkles scale
.3}finish{ambient 1}}#end#local I=0;#while(I<5)T(I,1)T(1-I,-1)#local I=I+
1;#end camera{location-5*z}plane{z,37 pigment{granite color_map{[.7rgb 0]
[1rgb 1]}}finish{ambient 2}}//                                   TenMoons

Post a reply to this message