POV-Ray : Newsgroups : povray.general : Fuctions, My two cents Server Time
29 Mar 2024 07:25:00 EDT (-0400)
  Fuctions, My two cents (Message 1 to 10 of 32)  
Goto Latest 10 Messages Next 10 Messages >>>
From: Leroy
Subject: Fuctions, My two cents
Date: 24 Feb 2023 20:25:00
Message: <web.63f9632653db63fbba5ca48bf712fc00@news.povray.org>
While playing with functions came upon this:
 you can create a macro that outputs a function with other #local functions
supporting that function and you call that macro several times for different
outputs.

Like this example:

#macro Gf_waves(r,c,d,V)
  #local g=radians(r);
  #local h=V*<1,1,1>+<.5,0,.5>;
  #local q=<c,1,d>;
  #local PigFa= function {pigment {waves color_map{[0,rgb 0][1,rgb 1]} scale q
        rotate y*r translate h}};
  #local PigF0= function {1-PigFa(x,0,z).hf}
  function(x,z){PigF0(x,0,z)}

#end

Used like this:

#declare Small_Waves=Gf_waves(0,1,1,0)
#declare Mid_Waves=Gf_waves(0,2,2,0)
#declare Big_Waves=Gf_waves(0,9,9,0)

The neat part is that you can used the #local function names in another macros
without conflict.

and you can combine functions like this

#declare Ground=function(x,z){Mat(x,z)*Dirt(x,z)}

I use version 3.7 haven't try it on any of the other versions.


Post a reply to this message

From: jr
Subject: Re: Fuctions, My two cents
Date: 25 Feb 2023 04:00:00
Message: <web.63f9cdb5f28769a3816b7cd96cde94f1@news.povray.org>
hi,

"Leroy" <whe### [at] gmailcom> wrote:
> While playing with functions came upon this:
> ...
>   #local PigF0= function {1-PigFa(x,0,z).hf}
> ...
> I use version 3.7 haven't try it on any of the other versions.

the macro parses ok on 3.8 beta.2, but WFP's 'povr' chokes on the '.hf'
("Invalid member access").  as it should, perhaps, can't find it in the
documentation.

<https://wiki.povray.org/content/Reference:Vector_Expressions#Dot_Item_Access_for_Vectors>
<https://wiki.povray.org/content/Reference:Color_Expressions#Dot_Item_Access_for_Colors>


regards, jr.


Post a reply to this message

From: Bald Eagle
Subject: Re: Fuctions, My two cents
Date: 25 Feb 2023 07:35:00
Message: <web.63f9ffb3f28769a31f9dae3025979125@news.povray.org>
"jr" <cre### [at] gmailcom> wrote:

> the macro parses ok on 3.8 beta.2, but WFP's 'povr' chokes on the '.hf'
> ("Invalid member access").  as it should, perhaps, can't find it in the
> documentation.

There was a Loooooooooooooooooooooong discussion of this over here:

http://news.povray.org/povray.advanced-users/message/%3C578a31c0%241%40news.povray.org%3E/#%3C578a31c0%241%40news.povra
y.org%3E

There are also height_field macros in shapes.inc, so maybe there is something
there that will bear fruit.

- BW


Post a reply to this message

From: William F Pokorny
Subject: Re: Fuctions, My two cents
Date: 25 Feb 2023 07:39:29
Message: <63fa0181$1@news.povray.org>
On 2/25/23 03:58, jr wrote:
> hi,
> 
> "Leroy" <whe### [at] gmailcom> wrote:
>> While playing with functions came upon this:
>> ...
>>    #local PigF0= function {1-PigFa(x,0,z).hf}
>> ...
>> I use version 3.7 haven't try it on any of the other versions.
> 
> the macro parses ok on 3.8 beta.2, but WFP's 'povr' chokes on the '.hf'
> ("Invalid member access").  as it should, perhaps, can't find it in the
> documentation.
> 
>
<https://wiki.povray.org/content/Reference:Vector_Expressions#Dot_Item_Access_for_Vectors>
>
<https://wiki.povray.org/content/Reference:Color_Expressions#Dot_Item_Access_for_Colors>
> 

Yes. I removed the .hf option in povr at some point. In part because it 
was an undocumented feature.

As best my memory serves...

The larger reason is it was a kind of on the cheap grey scale conversion 
used only for <= 8 bit channel deep color images which creates a 16 bit 
deep value from the red and green color channels(a). We should today 
always be using Greyscale() / .gray where we have color from which we 
want a single grey / luminosity value(b)

Bill P.

--- There is more for those wanting to run this particular rabbit hole...

(a) - The method treats green as the most significant 8 bits and red as 
the least significant 8 bits for 16 bits total - (HF_VAL)s. It is STILL 
in all POV-Ray, including povr, as the (undocumented too, I believe) 
method used when converting image_map '8 bit color image' pixel 
positions to a 16 bit deep, height_field height. It looks to me to 
always have been somewhat of a cheat to get 16 bits of depth in the only 
8 bit channel (or indexed) image days.

So you ask, what happens with height field color images with a bit depth 
of >8 <=16. Well, here we get Greyscale(). This, for example, means 
users playing with bit depths - as they now can in several POV-Ray 
outputs with v3.8+ - will see behavior they cannot easily understand for 
<=8 bits and .gray otherwise when using .hf or the still existing 
image_map Green/Red conversion. Users in prior versions are exposed to 
confusion too, if they are working with 8 and 16 bit color channel depths.

Functions return double float values. The values are clipped/confined to 
a 0-1 range as a ramp wave. This always so in POV-Ray releases. It's 
true by default in povr, but other ranges are allowed as options.

Let's think about what is really going on in Leroy's example. He's 
already converted to grey by using a 0-1 color_map. The expedient thing 
to do is use one of the .r, .g or .b channels directly. What happens 
with .hf is we end up with a least significant byte, 'grey echo' from 
the red channel on top of the most significant high order byte green 
channel's value. In other words, it is not real 16 bit grey resolution 
or even a clean 8.

Further, while Leroy's the code is perfectly valid in creating a pigment 
based function, it would be more efficient here to use the pattern 
mechanism directly.

The code:

#local PigFa= function {pigment {
     waves color_map{[0,rgb 0][1,rgb 1]}
     scale q rotate y*r translate h}};
#local PigF0= function {1-PigFa(x,0,z).hf}

would be more efficient as (I didn't run this...):

#local PatFa= function {pattern { waves
     scale q rotate y*r translate h}}
#local PatF0= function {1-PatFa(x,0,z)}

(b) - The internal .Greyscale() method in POV-Ray proper is close to, 
but not quite, ITU-R 601. It works fairly well when using the older 
assumed_gamma 2.2 internal gamma correction on non-linear textures / 
materials. Better for assumed_gamma 1.0 and the default sRGB output is 
ITU-R 709 (c) and povr has converted to this option as the default color 
to grey scale conversion. The povr fork is configurable with about a 
half dozen color to luminosity options including the old non-standard 
POV-Ray method. Related: V3.8 added image gamma options in the bt709 and 
bt2020 keywords.

An Alert! Related to (b), and my memory is foggy, but some number of 
official v3.8 releases, and over some period of time on github, the 
color to grey scale conversion in certain situations had a significant bug.

(c) - Cousin Ricky created SDL macros for the ITU-R 709 color to 
greyscale conversion some time back. Sorry, I don't have a link handy.


Post a reply to this message

From: Bald Eagle
Subject: Re: Fuctions, My two cents
Date: 25 Feb 2023 08:25:00
Message: <web.63fa0c06f28769a31f9dae3025979125@news.povray.org>
William F Pokorny <ano### [at] anonymousorg> wrote:

> An Alert! Related to (b), and my memory is foggy, but some number of
> official v3.8 releases, and over some period of time on github, the
> color to grey scale conversion in certain situations had a significant bug.

All I remember is that some folks commented that there was the 255 256 division
issue:
http://news.povray.org/5782990f%40news.povray.org

I found a color conversion equation someone was using (probably for a shader)
that claimed to take into account the differnce in eye response to the different
color wavelengths:
(Y = 0.2126R + 0.7152G + 0.0722B).

POV-Ray color conversion equations:
http://news.povray.org/web.577e98cbff0686005e7df57c0%40news.povray.org

clipka says .hf is mentioned in the isosurface tutorial
http://news.povray.org/57822645%241%40news.povray.org
And so it is, about halfway down, at the bottom of noise and pigment functions

https://wiki.povray.org/content/Documentation:Tutorial_Section_3.2


Here was my take:
http://news.povray.org/web.577ee122ff0686005e7df57c0%40news.povray.org

- BW


Post a reply to this message

From: William F Pokorny
Subject: Re: Fuctions, My two cents
Date: 25 Feb 2023 08:29:16
Message: <63fa0d2c$1@news.povray.org>
On 2/25/23 07:39, William F Pokorny wrote:



> Functions return double float values. The values are clipped/confined to 
> a 0-1 range as a ramp wave. This always so in POV-Ray releases. It's 
> true by default in povr, but other ranges are allowed as options.

On grabbing my first coffee it hit me the above statement is a mess. 
Plus I flipped the red and green significance of the .hf kind of grey 
conversion while writing...

---

Functions return one float value or float vectors. The components of the 
float vectors are doubles too - except for (5d) color vectors, which end 
up as single floats. Functions can return any valid double, but 
downstream consumers may not be able to make use of values outside the 
0-1 range.

I believe the vector component values are clamped to a 0-1 range. 
However, as I write this I'm not 100% sure... Can we get a vector 
component value of say 100.0 function to vector and visa versa?

As used in a height_field or image_map the values would end up with the 
ramp_wave (mod) kind of wrapping, but is that happening in the function 
vector return mechanism or elsewhere...?

The wrapping is happening elsewhere!

If I code up:

#declare Fn00 = function { pigment { rgb <222,333,444> } }
#declare Fn01 = function { Fn00(0,0,0).gray }
#declare Fn02 = function { Fn00(0,0,0).hf }

#debug concat("_pt=<", vstr(3, Fn00(0,0,0), ",", 0, 3), ">\n")
#debug concat("_pt=<", vstr(3,
<Fn00(0,0,0).x,Fn00(0,0,0).y,Fn00(0,0,0).z>, ",", 0, 3), ">\n")

#debug concat("Fn00(0,0,0).grey : ",str(Fn01(0,0,0),0,-1)," \n")
#debug concat("Fn00(0,0,0).hf : ",str(Fn02(0,0,0),0,-1)," \n")

and run it in v3.8 beta 2 I get:

Fn00 : 222.000,333.000,444.000>
Fn00 .x .y .z : 222.000,333.000,444.000>
Fn00(0,0,0).grey : 312.687000
Fn00(0,0,0).hf : 222.433426

Interesting. I learned something new.

Bill P.


Post a reply to this message

From: ingo
Subject: Re: Fuctions, My two cents
Date: 25 Feb 2023 08:30:00
Message: <web.63fa0c4df28769a317bac71e8ffb8ce3@news.povray.org>
William F Pokorny <ano### [at] anonymousorg> wrote:

> Yes. I removed the .hf option in povr at some point. In part because it
> was an undocumented feature.

Not where it should be: 2.3.3.3.7 Noise and pigment functions

quote:

And two special purpose operators, their supported dot types to access these
operators are:

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



ingo


Post a reply to this message

From: William F Pokorny
Subject: Re: Fuctions, My two cents
Date: 25 Feb 2023 08:38:03
Message: <63fa0f3b@news.povray.org>
On 2/25/23 08:24, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
>> An Alert! Related to (b), and my memory is foggy, but some number of
>> official v3.8 releases, and over some period of time on github, the
>> color to grey scale conversion in certain situations had a significant bug.
> 
> All I remember is that some folks commented that there was the 255 256 division
> issue:
> http://news.povray.org/5782990f%40news.povray.org
> 
> I found a color conversion equation someone was using (probably for a shader)
> that claimed to take into account the differnce in eye response to the different
> color wavelengths:
> (Y = 0.2126R + 0.7152G + 0.0722B).
> 
> POV-Ray color conversion equations:
> http://news.povray.org/web.577e98cbff0686005e7df57c0%40news.povray.org
> 
> clipka says .hf is mentioned in the isosurface tutorial
> http://news.povray.org/57822645%241%40news.povray.org
> And so it is, about halfway down, at the bottom of noise and pigment functions
> 
> https://wiki.povray.org/content/Documentation:Tutorial_Section_3.2
> 
> 
> Here was my take:
> http://news.povray.org/web.577ee122ff0686005e7df57c0%40news.povray.org
> 
> - BW
> 

Not the issue I was remembering... Can I find it. Ah the updated, paid, 
google search did turn it up!

https://news.povray.org/povray.unix/thread/%3C60144c97%241%40news.povray.org%3E/

Guess I wasn't sure about the bug-ness on initially posting and it ended 
up in p.unix.

Thanks for the references! I need to run, but I'll look them over later.

Bill P.


Post a reply to this message

From: jr
Subject: Re: Fuctions, My two cents
Date: 25 Feb 2023 10:00:00
Message: <web.63fa223ef28769a3816b7cd96cde94f1@news.povray.org>
hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> ...
> There was a Loooooooooooooooooooooong discussion of this over here:

:-)  interesting thread.  thanks.


@WFP

thanks for clarification + input(s); re the red-green thing, confused by "height
field color images", thought they were always just grayscale.


regards, jr.


Post a reply to this message

From: Leroy
Subject: Re: Fuctions, My two cents
Date: 25 Feb 2023 11:45:00
Message: <web.63fa3aedf28769a3ba5ca48bf712fc00@news.povray.org>
William F Pokorny <ano### [at] anonymousorg> wrote:
> On 2/25/23 07:39, William F Pokorny wrote:
>

> If I code up:
>
> #declare Fn00 = function { pigment { rgb <222,333,444> } }
> #declare Fn01 = function { Fn00(0,0,0).gray }
> #declare Fn02 = function { Fn00(0,0,0).hf }
>
> #debug concat("_pt=<", vstr(3, Fn00(0,0,0), ",", 0, 3), ">\n")
> #debug concat("_pt=<", vstr(3,
> <Fn00(0,0,0).x,Fn00(0,0,0).y,Fn00(0,0,0).z>, ",", 0, 3), ">\n")
>
> #debug concat("Fn00(0,0,0).grey : ",str(Fn01(0,0,0),0,-1)," \n")
> #debug concat("Fn00(0,0,0).hf : ",str(Fn02(0,0,0),0,-1)," \n")
>
> and run it in v3.8 beta 2 I get:
>
> Fn00 : 222.000,333.000,444.000>
> Fn00 .x .y .z : 222.000,333.000,444.000>
> Fn00(0,0,0).grey : 312.687000
> Fn00(0,0,0).hf : 222.433426
>
> Interesting. I learned something new.
>
> Bill P.

The code works on v3.7 also!


Post a reply to this message

Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.