Hi folks,

yet another new version to test:

https://github.com/POV-Ray/povray/releases/tag/v3.7.1-alpha.8889454

This version adds a new pigment pattern:

    pigment {
      user_defined {
        function { RED_FUNCTION },
        function { GREEN_FUNCTION },
        function { BLUE_FUNCTION },
        function { FILTER_FUNCTION },
        function { TRANSMIT_FUNCTION }
      }
    }

Each function is optional, in which case the corresponding component is
set to 0. For example, the following sets the colour to rgbft <x,y,0,0,z>:

    pigment {
      user_defined {
        function { x },
        function { y },
        ,,
        function { z }
      }
    }


Aside from that, the version also includes the data container update as
well as the transmission-based highlights/reflections knockout update.

Post a reply to this message

On 11/25/2016 1:13 AM, clipka wrote:
> Hi folks,
>
> yet another new version to test:
>
> https://github.com/POV-Ray/povray/releases/tag/v3.7.1-alpha.8889454
>
> This version adds a new pigment pattern:
>
>     pigment {
>       user_defined {
>         function { RED_FUNCTION },
>         function { GREEN_FUNCTION },
>         function { BLUE_FUNCTION },
>         function { FILTER_FUNCTION },
>         function { TRANSMIT_FUNCTION }
>       }
>     }
>
> Each function is optional, in which case the corresponding component is
> set to 0. For example, the following sets the colour to rgbft <x,y,0,0,z>:
>
>     pigment {
>       user_defined {
>         function { x },
>         function { y },
>         ,,
>         function { z }
>       }
>     }
>
>
> Aside from that, the version also includes the data container update as
> well as the transmission-based highlights/reflections knockout update.
>

Does it work like a parametric? Can you input the same values?


Mike

Post a reply to this message

On 11/25/2016 1:39 AM, Mike Horvath wrote:
> On 11/25/2016 1:13 AM, clipka wrote:
>> Hi folks,
>>
>> yet another new version to test:
>>
>> https://github.com/POV-Ray/povray/releases/tag/v3.7.1-alpha.8889454
>>
>> This version adds a new pigment pattern:
>>
>>     pigment {
>>       user_defined {
>>         function { RED_FUNCTION },
>>         function { GREEN_FUNCTION },
>>         function { BLUE_FUNCTION },
>>         function { FILTER_FUNCTION },
>>         function { TRANSMIT_FUNCTION }
>>       }
>>     }
>>
>> Each function is optional, in which case the corresponding component is
>> set to 0. For example, the following sets the colour to rgbft
>> <x,y,0,0,z>:
>>
>>     pigment {
>>       user_defined {
>>         function { x },
>>         function { y },
>>         ,,
>>         function { z }
>>       }
>>     }
>>
>>
>> Aside from that, the version also includes the data container update as
>> well as the transmission-based highlights/reflections knockout update.
>>
>
> Does it work like a parametric? Can you input the same values?
>
>
> Mike

Never mind. Stupid question.

Mike

Post a reply to this message

On 11/25/2016 1:13 AM, clipka wrote:
> yet another new version to test:
>
> https://github.com/POV-Ray/povray/releases/tag/v3.7.1-alpha.8889454

this version causes a warning then an error with an include file that i 
use often ... message followed by offending line

Warning: Float value promoted to full color vector where both filter and 
transmit >0.0.

#local OTO_FMask = function{ pattern{ pigment_pattern{ checker 0, 1 
warp{planar} } } }


Error: Bad operands for period operator.

#local Pt1 = Vec + x*(OTO_Get_Offset(Vec).x) + y*(OTO_Get_Offset(Vec+x).y);

3.7.1-alpha.8789352 doesn't have this problem(s)

Post a reply to this message

Am 25.11.2016 um 15:29 schrieb Jim Holsenback:
> Error: Bad operands for period operator.
> 
> #local Pt1 = Vec + x*(OTO_Get_Offset(Vec).x) + y*(OTO_Get_Offset(Vec+x).y);

Need more input -- what is OTO_Get_Offset(..)?

Post a reply to this message

On 11/25/2016 10:21 AM, clipka wrote:
> Am 25.11.2016 um 15:29 schrieb Jim Holsenback:
>> Error: Bad operands for period operator.
>>
>> #local Pt1 = Vec + x*(OTO_Get_Offset(Vec).x) + y*(OTO_Get_Offset(Vec+x).y);
>
> Need more input -- what is OTO_Get_Offset(..)?
>
it's in sam's odd tiles marco ... attached is complete include

Post a reply to this message

Attachments:
Download 'otoc.inc.txt' (5 KB)

Am 25.11.2016 um 15:29 schrieb Jim Holsenback:
> Warning: Float value promoted to full color vector where both filter and
> transmit >0.0.
> 
> #local OTO_FMask = function{ pattern{ pigment_pattern{ checker 0, 1
> warp{planar} } } }

This has to be considered a flaw in the include file: Instead of

    checker 0, 1

it should use

    checker rgb 0, rgb 1


Just specifying a bare scalar where a colour is expected will promote
the scalar to all colour channels, including both filter and transmit,
which is rarely intended.

Post a reply to this message

Am 25.11.2016 um 16:30 schrieb Jim Holsenback:
> On 11/25/2016 10:21 AM, clipka wrote:
>> Am 25.11.2016 um 15:29 schrieb Jim Holsenback:
>>> Error: Bad operands for period operator.
>>>
>>> #local Pt1 = Vec + x*(OTO_Get_Offset(Vec).x) +
>>> y*(OTO_Get_Offset(Vec+x).y);
>>
>> Need more input -- what is OTO_Get_Offset(..)?
>>
> it's in sam's odd tiles marco ... attached is complete include

It's a bug in OTO_Get_Offset(), which had previously been lying somewhat
dormant, but has now been exposed.

The macro evaluates to something of the form

    V*S

where V is a vector expression and S is a scalar expression. It is used
in an expression of the form

    M().y

which evaluates to

    V*S.y

Since the dot operator binds stronger than the multiplication operator,
this should be equivalent to

    V*(S.y)

which is illegal, and has always been, since S only has a single dimension.

However, this was masked in earlier versions by an internal bug in
scalar-to-vector promotion (reported on GitHub as issue #130), which
caused POV-Ray to immediately promote S to a vector of the same
dimensions as V, when the correct behaviour should have been to first
evaluate (S.y) and then promote the result.


The proper solution would be to add more braces to the expression in
OTO_Get_Offset(), so that the macro expansion yields the proper desired
expression:

    (V*S).y


As a side note, the invoking statement is rather cumbersome, using an
expression of the form:

    x*(V1.x) + y*(V2.y)

This can easily be abbreviated to:

    x*V1 + y*V2

or

    <V1.x, V2.y>

(though the latter definitely requires the macro to be fixed).

Post a reply to this message

On 11/25/2016 11:20 AM, clipka wrote:
> Am 25.11.2016 um 16:30 schrieb Jim Holsenback:
>> On 11/25/2016 10:21 AM, clipka wrote:
>>> Am 25.11.2016 um 15:29 schrieb Jim Holsenback:
>>>> Error: Bad operands for period operator.
>>>>
>>>> #local Pt1 = Vec + x*(OTO_Get_Offset(Vec).x) +
>>>> y*(OTO_Get_Offset(Vec+x).y);
>>>
>>> Need more input -- what is OTO_Get_Offset(..)?
>>>
>> it's in sam's odd tiles marco ... attached is complete include
>
> It's a bug in OTO_Get_Offset(), which had previously been lying somewhat
> dormant, but has now been exposed.

come again ... are we looking at the same thing?

in the include file i'm seeing:

#macro OTO_Get_Offset(Cell)
   #local CX = Cell.x;
   #local CY = Cell.y;
   (1-Bev*2)*<1,1,0>*(.5-OTO_FOffs(CX,CY,0))
#end

Post a reply to this message

On 11/25/2016 11:41 AM, Jim Holsenback wrote:
> On 11/25/2016 11:20 AM, clipka wrote:
>> Am 25.11.2016 um 16:30 schrieb Jim Holsenback:
>>> On 11/25/2016 10:21 AM, clipka wrote:
>>>> Am 25.11.2016 um 15:29 schrieb Jim Holsenback:
>>>>> Error: Bad operands for period operator.
>>>>>
>>>>> #local Pt1 = Vec + x*(OTO_Get_Offset(Vec).x) +
>>>>> y*(OTO_Get_Offset(Vec+x).y);
>>>>
>>>> Need more input -- what is OTO_Get_Offset(..)?
>>>>
>>> it's in sam's odd tiles marco ... attached is complete include
>>
>> It's a bug in OTO_Get_Offset(), which had previously been lying somewhat
>> dormant, but has now been exposed.
>
> come again ... are we looking at the same thing?
>
> in the include file i'm seeing:
>
> #macro OTO_Get_Offset(Cell)
>   #local CX = Cell.x;
>   #local CY = Cell.y;
>   (1-Bev*2)*<1,1,0>*(.5-OTO_FOffs(CX,CY,0))
> #end

no help?!?

Post a reply to this message

On 11/26/2016 6:14 AM, Jim Holsenback wrote:
> On 11/25/2016 11:41 AM, Jim Holsenback wrote:
>> On 11/25/2016 11:20 AM, clipka wrote:
>>> Am 25.11.2016 um 16:30 schrieb Jim Holsenback:
>>>> On 11/25/2016 10:21 AM, clipka wrote:
>>>>> Am 25.11.2016 um 15:29 schrieb Jim Holsenback:
>>>>>> Error: Bad operands for period operator.
>>>>>>
>>>>>> #local Pt1 = Vec + x*(OTO_Get_Offset(Vec).x) +
>>>>>> y*(OTO_Get_Offset(Vec+x).y);
>>>>>
>>>>> Need more input -- what is OTO_Get_Offset(..)?
>>>>>
>>>> it's in sam's odd tiles marco ... attached is complete include
>>>
>>> It's a bug in OTO_Get_Offset(), which had previously been lying somewhat
>>> dormant, but has now been exposed.
>>
>> come again ... are we looking at the same thing?
>>
>> in the include file i'm seeing:
>>
>> #macro OTO_Get_Offset(Cell)
>>   #local CX = Cell.x;
>>   #local CY = Cell.y;
>>   (1-Bev*2)*<1,1,0>*(.5-OTO_FOffs(CX,CY,0))
>> #end
>
> no help?!?

if it's /in/ the OTO_Get_Offset macro then why does commenting out the 
.y and .x notation (after the call to macro) get rid of the error:

#if(OTO_Get_Mask(Vec)=1 )
      #local Pt1 = Vec + y*(OTO_Get_Offset(Vec)/*.y*/) + 
x*(OTO_Get_Offset(Vec+y)/*.x*/);
      #local Pt2 = Vec + y*(OTO_Get_Offset(Vec+x+y)/*.y*/) + 
x*(OTO_Get_Offset(Vec-y+x+y)/*.x*/) +x+y;
     #else
      #local Pt1 = Vec + x*(OTO_Get_Offset(Vec)/*.x*/) + 
(y*OTO_Get_Offset(Vec+x)/*.y*/);
      #local Pt2 = Vec + x*(OTO_Get_Offset(Vec+x+y)/*.x*/) + 
y*(OTO_Get_Offset(Vec-x+x+y)/*.y*/) +x+y;
     #end

Post a reply to this message

Am 26.11.2016 um 12:14 schrieb Jim Holsenback:
> On 11/25/2016 11:41 AM, Jim Holsenback wrote:
>> On 11/25/2016 11:20 AM, clipka wrote:
>>> Am 25.11.2016 um 16:30 schrieb Jim Holsenback:
>>>> On 11/25/2016 10:21 AM, clipka wrote:
>>>>> Am 25.11.2016 um 15:29 schrieb Jim Holsenback:
>>>>>> Error: Bad operands for period operator.
>>>>>>
>>>>>> #local Pt1 = Vec + x*(OTO_Get_Offset(Vec).x) +
>>>>>> y*(OTO_Get_Offset(Vec+x).y);
>>>>>
>>>>> Need more input -- what is OTO_Get_Offset(..)?
>>>>>
>>>> it's in sam's odd tiles marco ... attached is complete include
>>>
>>> It's a bug in OTO_Get_Offset(), which had previously been lying somewhat
>>> dormant, but has now been exposed.
>>
>> come again ... are we looking at the same thing?
>>
>> in the include file i'm seeing:
>>
>> #macro OTO_Get_Offset(Cell)
>>   #local CX = Cell.x;
>>   #local CY = Cell.y;
>>   (1-Bev*2)*<1,1,0>*(.5-OTO_FOffs(CX,CY,0))
>> #end
> 
> no help?!?

Give me a few moments -- I can't /always/ respond lightning-fast ;)

Post a reply to this message

On 11/26/2016 7:02 AM, Jim Holsenback wrote:
> On 11/26/2016 6:14 AM, Jim Holsenback wrote:
>> On 11/25/2016 11:41 AM, Jim Holsenback wrote:
>>> On 11/25/2016 11:20 AM, clipka wrote:
>>>> Am 25.11.2016 um 16:30 schrieb Jim Holsenback:
>>>>> On 11/25/2016 10:21 AM, clipka wrote:
>>>>>> Am 25.11.2016 um 15:29 schrieb Jim Holsenback:
>>>>>>> Error: Bad operands for period operator.
>>>>>>>
>>>>>>> #local Pt1 = Vec + x*(OTO_Get_Offset(Vec).x) +
>>>>>>> y*(OTO_Get_Offset(Vec+x).y);
>>>>>>
>>>>>> Need more input -- what is OTO_Get_Offset(..)?
>>>>>>
>>>>> it's in sam's odd tiles marco ... attached is complete include
>>>>
>>>> It's a bug in OTO_Get_Offset(), which had previously been lying
>>>> somewhat
>>>> dormant, but has now been exposed.
>>>
>>> come again ... are we looking at the same thing?
>>>
>>> in the include file i'm seeing:
>>>
>>> #macro OTO_Get_Offset(Cell)
>>>   #local CX = Cell.x;
>>>   #local CY = Cell.y;
>>>   (1-Bev*2)*<1,1,0>*(.5-OTO_FOffs(CX,CY,0))
>>> #end
>>
>> no help?!?
>
> if it's /in/ the OTO_Get_Offset macro then why does commenting out the
> .y and .x notation (after the call to macro) get rid of the error:
>
> #if(OTO_Get_Mask(Vec)=1 )
>      #local Pt1 = Vec + y*(OTO_Get_Offset(Vec)/*.y*/) +
> x*(OTO_Get_Offset(Vec+y)/*.x*/);
>      #local Pt2 = Vec + y*(OTO_Get_Offset(Vec+x+y)/*.y*/) +
> x*(OTO_Get_Offset(Vec-y+x+y)/*.x*/) +x+y;
>     #else
>      #local Pt1 = Vec + x*(OTO_Get_Offset(Vec)/*.x*/) +
> (y*OTO_Get_Offset(Vec+x)/*.y*/);
>      #local Pt2 = Vec + x*(OTO_Get_Offset(Vec+x+y)/*.x*/) +
> y*(OTO_Get_Offset(Vec-x+x+y)/*.y*/) +x+y;
>     #end

I'm working with the "corner finding" portion of the include. added the 
following:

#if(OTO_Get_Mask(Vec)=1 )
      #local Pt1 = Vec + y*(OTO_Get_Offset(Vec).y) + 
x*(OTO_Get_Offset(Vec+y).x);
      #local Pt2 = Vec + y*(OTO_Get_Offset(Vec+x+y).y) + 
x*(OTO_Get_Offset(Vec-y+x+y).x) +x+y;
     #else
      #local Pt1 = Vec + x*(OTO_Get_Offset(Vec)/*.x*/) + 
(y*OTO_Get_Offset(Vec+x)/*.y*/);
      #debug concat ("\nResults: <", vstr(3, Pt1,",",5,6),">\n")
      #local Pt2 = Vec + x*(OTO_Get_Offset(Vec+x+y).x) + 
y*(OTO_Get_Offset(Vec-x+x+y).y) +x+y;
     #end

debug echos a 3-way vector ... so what's wrong with the expectation of 
getting the dot product using the notation given. the while loop that 
encloses the above conditional eventually sends it through both branches 
and begins to render after commenting  out all the offending notation. 
quick visual inspection doesn't reveal any problems with the odd tiles

Post a reply to this message

Am 26.11.2016 um 13:02 schrieb Jim Holsenback:

>>>> It's a bug in OTO_Get_Offset(), which had previously been lying
>>>> somewhat
>>>> dormant, but has now been exposed.
>>>
>>> come again ... are we looking at the same thing?
>>>
>>> in the include file i'm seeing:
>>>
>>> #macro OTO_Get_Offset(Cell)
>>>   #local CX = Cell.x;
>>>   #local CY = Cell.y;
>>>   (1-Bev*2)*<1,1,0>*(.5-OTO_FOffs(CX,CY,0))
>>> #end
>>
>> no help?!?
> 
> if it's /in/ the OTO_Get_Offset macro then why does commenting out the
> ..y and .x notation (after the call to macro) get rid of the error:
> 
> #if(OTO_Get_Mask(Vec)=1 )
>      #local Pt1 = Vec + y*(OTO_Get_Offset(Vec)/*.y*/) +
> x*(OTO_Get_Offset(Vec+y)/*.x*/);
>      #local Pt2 = Vec + y*(OTO_Get_Offset(Vec+x+y)/*.y*/) +
> x*(OTO_Get_Offset(Vec-y+x+y)/*.x*/) +x+y;
>     #else
>      #local Pt1 = Vec + x*(OTO_Get_Offset(Vec)/*.x*/) +
> (y*OTO_Get_Offset(Vec+x)/*.y*/);
>      #local Pt2 = Vec + x*(OTO_Get_Offset(Vec+x+y)/*.x*/) +
> y*(OTO_Get_Offset(Vec-x+x+y)/*.y*/) +x+y;
>     #end

The problem is rooted in how POV-Ray macros work: They're not
/functions/, but essentially "SDL code generators".

So if I have a macro

    #macro OTO_Get_Offset(Cell)
      #local CX = Cell.x;
      #local CY = Cell.y;
      (1-Bev*2)*<1,1,0>*(.5-OTO_FOffs(CX,CY,0))
    #end

then the macro invocation

    y*(OTO_Get_Offset(Vec).y)

does /not/ first compute the macro and then take the y component of the
result:

    // intended result
    y*((  (1-Bev*2)*<1,1,0>*(.5-OTO_FOffs(CX,CY,0))  ).y)

Instead, the body of the macro is essentially just pasted in:

    // actual result
    y*(  (1-Bev*2)*<1,1,0>*(.5-OTO_FOffs(CX,CY,0))  .y)

which -- obviously, once you format it a bit differently -- is something
entirely different:

    y*(  (1-Bev*2)  *  <1,1,0>  *  (.5-OTO_FOffs(CX,CY,0)).y  )


Now if you drop the `.y`, what you get is:

    y*(  (1-Bev*2)  *  <1,1,0>  *  (.5-OTO_FOffs(CX,CY,0))  )

which /happens/ to give exactly the same result as the intended
function, because given a vector V,

    y*(V.y)

aka

    <0,1,0>*(V.y)

scalar-to-vector promotion turns this into:

    <0,1,0>*<V.y,V.y,V.y>

which results in

    <0,V.y,0>

which happens to be the same as

    <0,1,0>*<V.x,V.y,V.z>

which is equivalent to

    <0,1,0>*V

aka

    y*V


The proper solution is to redefine the macro to include the intended
parentheses:

    #macro OTO_Get_Offset(Cell)
      #local CX = Cell.x;
      #local CY = Cell.y;
      (  (1-Bev*2)*<1,1,0>*(.5-OTO_FOffs(CX,CY,0))  )
    #end

Post a reply to this message

Am 26.11.2016 um 14:30 schrieb clipka:

> The proper solution is to redefine the macro to include the intended
> parentheses:
> 
>     #macro OTO_Get_Offset(Cell)
>       #local CX = Cell.x;
>       #local CY = Cell.y;
>       (  (1-Bev*2)*<1,1,0>*(.5-OTO_FOffs(CX,CY,0))  )
>     #end

... or use the "result variable" idiom:

    #macro OTO_Get_Offset(Cell)
      #local CX = Cell.x;
      #local CY = Cell.y;
      #local result = (1-Bev*2)*<1,1,0>*(.5-OTO_FOffs(CX,CY,0));
      result
    #end

Post a reply to this message

On 11/26/2016 8:35 AM, clipka wrote:
> Am 26.11.2016 um 14:30 schrieb clipka:
>
>> The proper solution is to redefine the macro to include the intended
>> parentheses:
>>
>>     #macro OTO_Get_Offset(Cell)
>>       #local CX = Cell.x;
>>       #local CY = Cell.y;
>>       (  (1-Bev*2)*<1,1,0>*(.5-OTO_FOffs(CX,CY,0))  )
>>     #end
>
> ... or use the "result variable" idiom:
>
>     #macro OTO_Get_Offset(Cell)
>       #local CX = Cell.x;
>       #local CY = Cell.y;
>       #local result = (1-Bev*2)*<1,1,0>*(.5-OTO_FOffs(CX,CY,0));
>       result
>     #end
>

yes that's what i ended up doing, but got distracted (woof) with 
something else before i could reply. i'm trying to make sure i 
understand the pathology here ... earlier in this thread a bug was 
mentioned. the array/dictionary changes exposed the issue? devils 
advocate would say that this should be documented as a {{Change}} ... 
i'm guessing somewhere in the array talk page that's been currently 
reworked?

Post a reply to this message

Am 26.11.2016 um 16:13 schrieb Jim Holsenback:

> yes that's what i ended up doing, but got distracted (woof) with
> something else before i could reply. i'm trying to make sure i
> understand the pathology here ... earlier in this thread a bug was
> mentioned. the array/dictionary changes exposed the issue? devils
> advocate would say that this should be documented as a {{Change}} ...
> i'm guessing somewhere in the array talk page that's been currently
> reworked?

No, the array/dictionary changes are not to blame (not for this at any
rate; despite the dictionary syntax also happening to use dot notation).

Instead, the change that "broke" it was commit fa4a158, "Fix promotion
bug (#130)", which fixed this bug:

http://news.povray.org/3c4bb31d$1@news.povray.org


In my opinion there is no {{Change}} to be documented: The new behaviour
matches what has always been in the docs, and what people have always
been expecting -- if it wasn't for the mucking around with macros; it is
the fundamental way macros work (which hasn't changed a jot) that
constitutes the only potentially surprising element in this context. It
is the same mechanism that has always been the potential source of
surprise in coce such as:

    #macro Sum(A,B,C)
      A+B+C
    #end
    #declare X = Sum(1,2,3)*3;

That thing has never worked as intended, so why should anyone expect the
`.y` operator to behave any different in this respect?

Post a reply to this message

On 11/26/2016 11:25 AM, clipka wrote:
> In my opinion there is no {{Change}} to be documented:

hmmm ... well i guess then we are left with agreeing to disagree

Post a reply to this message

Am 27.11.2016 um 13:35 schrieb Jim Holsenback:
> On 11/26/2016 11:25 AM, clipka wrote:
>> In my opinion there is no {{Change}} to be documented:
> 
> hmmm ... well i guess then we are left with agreeing to disagree

What change, in particular, would you be documenting then?

Post a reply to this message