Related to the post above.. Why was eval_pigment dropped? Why not expand it?
If not kept as a built in function, why not put it in one of the include files?

Have Fun?

Post a reply to this message

"Leroy" <whe### [at] gmailcom> wrote:
> Related to the post above.. Why was eval_pigment dropped? Why not expand it?
> If not kept as a built in function, why not put it in one of the include files?
>
> Have Fun?

eval_pigment is a macro in the functions.inc file.

It is, as has been pointed out in the past, simply a wrapper for a pigment
function.


#macro eval_pigment(pigm, vec)
    #local fn = function { pigment { pigm } }
    #local result = (fn(vec.x, vec.y, vec.z));
    result
#end

You plug in your <x, y, z> vector, and out pops the <r, g, b> color vector at
that point in the pattern, image_map, etc.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Leroy" <whe### [at] gmailcom> wrote:
> > Related to the post above.. Why was eval_pigment dropped? Why not expand it?
> > If not kept as a built in function, why not put it in one of the include files?
> >
> > Have Fun?
>
> eval_pigment is a macro in the functions.inc file.
>
> It is, as has been pointed out in the past, simply a wrapper for a pigment
> function.
>
>
> #macro eval_pigment(pigm, vec)
>     #local fn = function { pigment { pigm } }
>     #local result = (fn(vec.x, vec.y, vec.z));
>     result
> #end
>
> You plug in your <x, y, z> vector, and out pops the <r, g, b> color vector at
> that point in the pattern, image_map, etc.

Hi

Naming functions is often problematic.
So suggest that that macro is rewritten, e.g. like this:


#include "vectors.inc"  // https://github.com/t-o-k/Useful-POV-Ray-macros


#macro EvalPigment(Pigment, v0)

    FunctionValue(
        function {
            pigment { Pigment }
        },
        v0
    )

#end // macro EvalPigment


--
Tor Olav
http://subcube.com
https://github.com/t-o-k

Post a reply to this message

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:

> Naming functions is often problematic.

It is.   But masking the true nature of what the macro does, and probably
slowing down the scene seems (to me) to be far worse.

Would not a simple one line

function {pigment { Pigment }}

be perfectly adequate, easily enough understood, and encourage greater education
and understanding about how _so many_ thing in POV-Ray really work?

I learned so much, and understood so much more, when I made all the connections
between functions, pigment patterns, isosurfaces, parametrics, and uv-mapping.

Even the recent question about interpolating color_map values is something I
would have never been able to adequately answer, if at all, only a few years
ago.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
>
> > Naming functions is often problematic.
>
> It is.   But masking the true nature of what the macro does, and probably
> slowing down the scene seems (to me) to be far worse.

I don't think that what I suggesting is trying to mask anything. It is just an
attempt to make robust macros that doesn't create strange problems for the
users.

And understanding how to pass arguments to macros and functions is something
that I think a lot of POV-Ray users will benefit from understanding. (Sorry,
that was probably not good English language.)


> Would not a simple one line
>
> function {pigment { Pigment }}
>
> be perfectly adequate, easily enough understood, and encourage greater education
> and understanding about how _so many_ thing in POV-Ray really work?

Yes, in user created code, like the code you just posted, I think it is all ok
to name functions. I think your code was relatively easy to understand. But in
include files for use by many others I think we should be careful.


> I learned so much, and understood so much more, when I made all the connections
> between functions, pigment patterns, isosurfaces, parametrics, and uv-mapping.
>
> Even the recent question about interpolating color_map values is something I
> would have never been able to adequately answer, if at all, only a few years
> ago.

Yes it's hard work and takes a lot of reading and experimenting.

Today, after you posted your code in the "colors map interpolation" thread, I
learnt a new thing about splines. I was about to suggest that this code be used
to return color vectors corresponding to the colors in the color map:

#declare VectorSpline =
    spline {
        linear_spline
        0.00, <1.00, 0.00, 0.00>,
        0.50, <1.00, 1.00, 0.00>,
        1.00, <0.00, 0.00, 1.00>
    }

But I found that the interpolation in splines, does not happen in the same way
as in color maps.

This spline:

#declare VectorSpline =
    spline {
        linear_spline
        0.00, <1.00, 0.00, 0.00>,
        0.50, <1.00, 1.00, 1.00>,
        0.50, <1.00, 1.00, 0.00>,
        1.00, <0.00, 0.00, 1.00>
    }

- results in different colors than this color map:

color_map {
    [ 0.00 rgb < 1.00, 0.00, 0.00> ]
    [ 0.50 rgb < 1.00, 1.00, 1.00> ]
    [ 0.50 rgb < 1.00, 1.00, 0.00> ]
    [ 1.00 rgb < 0.00, 0.00, 1.00> ]
}

It seems that splines can only deal with one value or vector for each "knot".

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

Post a reply to this message

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:

> I don't think that what I suggesting is trying to mask anything. It is just an
> attempt to make robust macros that doesn't create strange problems for the
> users.

The masking is just something that happens incidentally - people know if
eval_pigment, but have no idea how it works.  It becomes POV-Ray magic by
default.


> Yes, in user created code, like the code you just posted, I think it is all ok
> to name functions. I think your code was relatively easy to understand. But in
> include files for use by many others I think we should be careful.

Indeed.   Bill Pokorny, jr, myself, and others have run into that namespace
problem.


> Today, after you posted your code in the "colors map interpolation" thread, I
> learnt a new thing about splines. I was about to suggest that this code be used
> to return color vectors corresponding to the colors in the color map:
>
> #declare VectorSpline =
>     spline {
>         linear_spline
>         0.00, <1.00, 0.00, 0.00>,
>         0.50, <1.00, 1.00, 0.00>,
>         1.00, <0.00, 0.00, 1.00>
>     }
>
> But I found that the interpolation in splines, does not happen in the same way
> as in color maps.

Try again, but be aware that POV-Ray uses different types of interpolation with
the different blend modes.

https://wiki.povray.org/content/Reference:Color_Map

I'm sure your spline is using linear interpolation, whereas the default might be
 in sRGB space.  It's extremely confusing until you get how all the "color math"
works in context, and even then I tend to run into problems or get it completely
backwards.

Post a reply to this message

"Leroy" <whe### [at] gmailcom> wrote:
> Related to the post above.. Why was eval_pigment dropped? Why not expand it?
> If not kept as a built in function, why not put it in one of the include files?
>
> Have Fun?

My Bad.. What I thought was 'eval_pigment' was drop. The real problem was
documentation.
 The help file on my POV 3.7 RC7 didn't have 'eval_pigment' in the Index. I
still have 3.6 and 3.5 on my computer, they still have it. But the page they
take you to had nothing about being in 'functions.inc'. That information is
several pages away and I never did find it.
 As soon I found out that 'eval_pigment' was in 'functions.inc". I went to the
POV3.7 and found that the Help Contents lead me to 'eval_pigment' through
'functions.inc" ( the same page that's in POV3.6 & 3.5)

 Now that's taken care of, While I was waiting for replies, I wrote my own
'Eval_pigment' & 'Eval_Cmap' &'Eval_ObjPig' macros.

#macro Eval_Pig(Pig,V)
 #local V=V*<1,1,1>;
 #local Fna=function{pigment{Pig}}
 Fna(V.x,V.y,V.z)
#end
#macro Eval_Cmap(Cmapp,V)
 #local V=V*<1,1,1>;
 #local Pig=pigment{gradient x color_map{Cmapp}}
 #local Fna=function{pigment{Pig}}
 Fna(V.x,V.y,V.z)
#end

// Obj - object with pigment
// Pig - pigment seperate from object but translated with object
// N   - trace intersect normal to center of object
#macro Eval_Obj_Pig(Obj,Pig,N)
  #local Mx=max_extent(Obj);
  #local Mn=min_extent(Obj);
  #local Mc=(Mx+Mn)/2;
 #local Norm = <0, 0, 0>;
 #local Start =vlength(Mx-Mn)*N+Mc;
 #local V = trace (Obj,Start,-N,Norm );
 #if (Norm.x != 0 | Norm.y != 0 | Norm.z != 0)
  #local Fna=function{pigment{Pig}}
  #local R=Fna(V.x,V.y,V.z);
 #else
  #local R=<0,0,0>;// default color
 #end

 R

#end

Thanks for the help!

Have Fun!

Post a reply to this message

"Leroy" <whe### [at] gmailcom> wrote:

>...

>  Now that's taken care of, While I was waiting for replies, I wrote my own
> 'Eval_pigment' & 'Eval_Cmap' &'Eval_ObjPig' macros.

>...

> #macro Eval_Obj_Pig(Obj,Pig,N)
>   #local Mx=max_extent(Obj);
>   #local Mn=min_extent(Obj);
>   #local Mc=(Mx+Mn)/2;
>  #local Norm = <0, 0, 0>;
>  #local Start =vlength(Mx-Mn)*N+Mc;
>  #local V = trace (Obj,Start,-N,Norm );
>  #if (Norm.x != 0 | Norm.y != 0 | Norm.z != 0)
>   #local Fna=function{pigment{Pig}}
>   #local R=Fna(V.x,V.y,V.z);
>  #else
>   #local R=<0,0,0>;// default color
>  #end
>
>  R
>
> #end

Hi Leroy

If you want a faster macro then you'll probably find that this statement:

    #if (vlength(Norm) > 0)

executes faster (and is easier to read) than this:

    #if (Norm.x != 0 | Norm.y != 0 | Norm.z != 0)


--
Tor Olav
http://subcube.com
https://github.com/t-o-k

Post a reply to this message

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
> "Leroy" <whe### [at] gmailcom> wrote:
>
> >...
>
> >  Now that's taken care of, While I was waiting for replies, I wrote my own
> > 'Eval_pigment' & 'Eval_Cmap' &'Eval_ObjPig' macros.
>
> >...
>
> > #macro Eval_Obj_Pig(Obj,Pig,N)
> >   #local Mx=max_extent(Obj);
> >   #local Mn=min_extent(Obj);
> >   #local Mc=(Mx+Mn)/2;
> >  #local Norm = <0, 0, 0>;
> >  #local Start =vlength(Mx-Mn)*N+Mc;
> >  #local V = trace (Obj,Start,-N,Norm );
> >  #if (Norm.x != 0 | Norm.y != 0 | Norm.z != 0)
> >   #local Fna=function{pigment{Pig}}
> >   #local R=Fna(V.x,V.y,V.z);
> >  #else
> >   #local R=<0,0,0>;// default color
> >  #end
> >
> >  R
> >
> > #end
>
> Hi Leroy
>
> If you want a faster macro then you'll probably find that this statement:
>
>     #if (vlength(Norm) > 0)
>
> executes faster (and is easier to read) than this:
>
>     #if (Norm.x != 0 | Norm.y != 0 | Norm.z != 0)
>
>
> --
> Tor Olav
> http://subcube.com
> https://github.com/t-o-k

Yes I know got lazy & use trace from
the insert that came with POV3.7 win

Post a reply to this message