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