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