Please see my previous post "Problem in pigment_pattern
with bozo/f_noise3d:" for a set of code illustrating
this issue.

After thoroughly reviewing the docs, Mike Williams' excellent tutorial,
several posts, and lots of personal research, I've decided what I wanted
to do just can't be done. If I'm wrong maybe someone here can set me
straight. :)

Take the following code snippet:
//-------------------------------

#declare Fn_AmbMap = function{ pigment{
       pigment_pattern {bozo scale 0.5}
                   color_map {
        [0.00 color rgb <0,0,0> ]
        [1.00 color rgb <1,1,1> ]
      }
   }
}//end function
.
.
.
texture{ pigment {function{Fn_AmbMap(x,y,z).gray}scale 0.5 }
         finish {diffuse pow((Fn_AmbMap(x.x,y.y,z.z).gray),1)}
  }
//----------------------------------

It shows a function definition and two uses of the function
in two different contexts: as a pigment and as a user defined
float function. Of note here are the two different forms the
parameters are required to take. This has been a source of some
confusion, usually resulting in an explanation of the differences
between floats and vectors.The real issue however has to do with
context, since the statement above is perfectly legal.

However, it does not do what I was hoping it would; vary the
diffusion across the surface. The reason, it seems, is there is no
way to 'explicitly' pass in the vector coordinates of the current
ray-intersection point. This is done 'implicitly' in the context
of the pigment, normal, isosurface, and (depending on final usage context)
possibly also other function declarations.

Without this explicit mechanism, the function is fully evaluated at
parse time and if called during render time by the pseudo-code engine
redundantly returns the same value at each call. It is unnecessary
overhead then, since, ( as I understand it ) with respect to functions the only
thing to change during the render are the vector coordinates of the current
point under evaluation. A macro or something would be more
appropriate here if only to save render overhead.

Is it possible to:
    A) Add an explicit mechanism for passing the current point under
evaluation as a parameter by a keyword like ray (ray.x, ray.y ray.z)
that defaults to <1,1,1> during parse and takes the current point during
render. . .

or  B) Add a zero_parameter internal function that returns the current point
under 'any' context (i.e. f_ray().x f_ray().y, etc.)

or  C) Expand the current 'implicit' form of the syntax to be used under
anyplace it is legal to use a function. . .

or  D) Add some clarification to the docs regarding the where functions are
allowed to receive the current point and the resultant implications of their
use (and the overhead they incur) elsewhere ?


--
Batronyx ^"^
bat### [at] cadronhsacom
http://www.batronyx.com

Post a reply to this message

Wasn't it Batronyx who wrote:
>Please see my previous post "Problem in pigment_pattern
>with bozo/f_noise3d:" for a set of code illustrating
>this issue.
>
>After thoroughly reviewing the docs, Mike Williams' excellent tutorial,
>several posts, and lots of personal research, I've decided what I wanted
>to do just can't be done. If I'm wrong maybe someone here can set me
>straight. :)
>
>Take the following code snippet:
>//-------------------------------
>
>#declare Fn_AmbMap = function{ pigment{
>       pigment_pattern {bozo scale 0.5}
>                   color_map {
>        [0.00 color rgb <0,0,0> ]
>        [1.00 color rgb <1,1,1> ]
>      }
>   }
>}//end function
>.
>.
>.
>texture{ pigment {function{Fn_AmbMap(x,y,z).gray}scale 0.5 }
>         finish {diffuse pow((Fn_AmbMap(x.x,y.y,z.z).gray),1)}
>  }
>//----------------------------------
>
>It shows a function definition and two uses of the function
>in two different contexts: as a pigment and as a user defined
>float function. Of note here are the two different forms the
>parameters are required to take. This has been a source of some
>confusion, usually resulting in an explanation of the differences
>between floats and vectors.The real issue however has to do with
>context, since the statement above is perfectly legal.

Actually, I believe that this is the critical point.

The problem is that "x" can have two possible meanings. One meaning is
the float value of the x-coordinate of the point that the function is
currently evaluating, and the other is the unit vector <1,0,0>. At parse
time, only the unit vector interpretation is meaningful.

In this case, POV has decided that "x" in this context means <1,0,0>,
which happens to not be the interpretation that you desire.

Wherever "x." is meaningful, it will always mean the x component of
<1,0,0>, i.e. the value 1. Similarly "x.x,y.y,z.z" is the point <1,1,1>.
So "(Fn_AmbMap(x.x,y.y,z.z).gray" always evaluates the function at the
point <1,1,1>.

(Quick check: Your scene does render identically with x.x,y.y,z.z
replaced throughout with 1,1,1.)


>However, it does not do what I was hoping it would; vary the
>diffusion across the surface. The reason, it seems, is there is no
>way to 'explicitly' pass in the vector coordinates of the current
>ray-intersection point. This is done 'implicitly' in the context
>of the pigment, normal, isosurface, and (depending on final usage context)
>possibly also other function declarations.

I think that there may well be a syntax that does this explicitly, but
you can only use it where it is allowed, and it doesn't happen to be
currently allowed after "diffuse". If it were allowed it would look like
this
  finish {diffuse function{F(x,y,z)}}
rather than
  finish {diffuse F(x,y,z)}

It looks to me that if you use a function without outside a "function{}"
envelope, then it gets evaluated at parse time. e.g.
     pigment {rgb Fn_AmbMap(1,1,1)}


>Without this explicit mechanism, the function is fully evaluated at
>parse time and if called during render time by the pseudo-code engine
>redundantly returns the same value at each call. It is unnecessary
>overhead then, since, ( as I understand it ) with respect to functions the only
>thing to change during the render are the vector coordinates of the current
>point under evaluation. A macro or something would be more
>appropriate here if only to save render overhead.

I understood that functions were faster than macros.


-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

Batronyx <bat### [at] cadronhsacom> wrote:
: #declare Fn_AmbMap = function{ pigment{
:        pigment_pattern {bozo scale 0.5}
:                    color_map {
:         [0.00 color rgb <0,0,0> ]
:         [1.00 color rgb <1,1,1> ]
:       }
:    }
: }//end function

  Perhaps a bit unrelated, but I don't understand why it has to be that
complicated. Why not just:

#declare Fn_AmbMap = function { pattern { bozo scale .5 } }


-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message news:3bab0c9a@news.povray.org...
> Batronyx <bat### [at] cadronhsacom> wrote:
> : #declare Fn_AmbMap = function{ pigment{
> :        pigment_pattern {bozo scale 0.5}
> :                    color_map {
> :         [0.00 color rgb <0,0,0> ]
> :         [1.00 color rgb <1,1,1> ]
> :       }
> :    }
> : }//end function
>
>   Perhaps a bit unrelated, but I don't understand why it has to be that
> complicated. Why not just:
>


You're right. It doesn't have to be that complicated. In trying different work-
arounds though, I discovered a bug in the pigment_pattern using bozo. This
snippet is just cut'n'paste from my previous post as a matter of convenience.

--
Batronyx ^"^
bat### [at] cadronhsacom
http://www.batronyx.com

Post a reply to this message

"Mike Williams" <mik### [at] nospamplease> wrote in message
news:tPq### [at] econymdemoncouk...
> Wasn't it Batronyx who wrote:
> >Please see my previous post "Problem in pigment_pattern
> >with bozo/f_noise3d:" for a set of code illustrating
> >this issue.
> >
> I think that there may well be a syntax that does this explicitly, but
> you can only use it where it is allowed, and it doesn't happen to be
> currently allowed after "diffuse". If it were allowed it would look like
> this
>   finish {diffuse function{F(x,y,z)}}
> rather than
>   finish {diffuse F(x,y,z)}
>
> It looks to me that if you use a function without outside a "function{}"
> envelope, then it gets evaluated at parse time. e.g.
>      pigment {rgb Fn_AmbMap(1,1,1)}

I hadn't considered this possibility.

>
> >Without this explicit mechanism, the function is fully evaluated at
> >parse time and if called during render time by the pseudo-code engine
> >redundantly returns the same value at each call. It is unnecessary
> >overhead then, since, ( as I understand it ) with respect to functions the
only
> >thing to change during the render are the vector coordinates of the current
> >point under evaluation. A macro or something would be more
> >appropriate here if only to save render overhead.
>
> I understood that functions were faster than macros.

If the absence of the "function{}" envelope precludes a call to the function
at render time, then you are very likely correct about the speed.

Drat! Well, the clarity is worth something at least :)


--
Batronyx ^"^
bat### [at] cadronhsacom
http://www.batronyx.com

Post a reply to this message