William F Pokorny <ano### [at] anonymousorg> wrote:
> On 2/25/23 03:58, jr wrote:
> 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)}
>
True your example is more efficient, But right now I was exploring what
functions can do. I wrote several and just grab one as an example, maybe not the
best. I use the pigment & color_map thinking I could change the color_map to any
of the several I have in stock. It might be interesting!
 I like your point about using the 0-1 color_map I hadn't really thought of it
that way. Just now I notice I didn't need the 1-PigFa(x,0,z).hf I could have
flipped the color_map and used PigFa(x,0,z).hf.
 This is fun!

Post a reply to this message