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