 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
"Leroy" <whe### [at] gmail com> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
