In article <38D### [at] aolcom>, Lummox JR <Lum### [at] aolcom> wrote:

> > I would certainly be interested in the results. It would also be nice 
> > to
> > allow user defined functions to have a variable number of parameters,
> > how possible do you think that would be?
> 
> I'd really love to see that too. What would probably be a lot more
> useful, however, would be a set of functions to work on vectors.

Hmm, what would this syntax look like? Would it be possible to make a 
special sort of function which can handle vectors and colors and which 
outputs a color? Kind of a simplified shader, with functions like 
trace(), eval_pigment() and eval_pattern(), and possibly access to 
functions like reflect and diffuse, and maybe access to a list of light 
sources and the camera. It wouldn't be as complex as a real shader, but 
would be very close to what my "shader" patch is theoretically supposed 
to do(I never made a lot of progress and haven't worked on it lately, it 
might be better to work from the isosurface function code).


> These functions wouldn't really be user-accessible; the possibility of
> screwing things up is too great. The resulting code might or might not
> be longer--sometimes length will be saved, and other times the overhead
> of the extra numbers will take a toll.

This looks like a very good idea, and would be nearly(completely?) 
invisible to the user except as a speed increase.


> I dunno; I think "bozo" makes sense enough for the purpose. People
> writing a function aren't likely to confuse it with the pigment, which
> matches noise3d() anyway. I'd prefer a better name for it myself,
> though, so perhaps rnoise would be a very worthwhile change.

I just don't think it is a good idea to reuse that keyword in that way, 
just my opinion.
What if the patterns are someday added in as functions, so "bozo(x,y,z)" 
evaluates the bozo pattern at that position? Things like "method" make 
sense to reuse(for media method, isosurface solving method, proximity 
calculations, etc), but bozo doesn't(except for both being a noise 
function).


> I chose this one because it's a pain in the butt to add tokens to the 
> parser.

You must mean the isosurface parsing code, right? It only takes a line 
in tokenize.c and a line in parse.h to add a token, I wouldn't call 
those two lines a "pain in the butt". However, I have never added 
anything to the isosurface code, I don't know how difficult it is.


> Clamp() is explanatory, sure, although I think range() is equally
> explanatory in this case. Actually "range" was the first word that came
> to mind, since the goal is to constrain values to a specific range. The
> beauty of using range is that its purpose is fairly evident, and it
> already has a token in the parser. No token modifications required.

I think "range" implies more of scaling a value to fit in a certain 
range. It would be something like this:
range(value, source_min, source_max, dest_min, dest_max)
Values between source_min and source_max are scaled to between dest_min 
and dest_max.
The word "clamp" specifies what the function does, "clip()" would work 
just as well. Actually, I would name it ClipToRange(), but that is a bit 
long and doesn't fit with the naming conventions of POV-Ray. :-)


> I'd like some open critique of my function-optimization idea, really. 
> I haven't tested any of the code I have in mind, though when I 
> developed it I did a number of mental run-throughs. And of course 
> more can be done.
> I think any of these optimizations are possible and even desirable,
> however:
> ...
> 
> This basic design won't catch some simple things like (x-y)=-(y-x), but
> it's a good starting point. I'd be willing to bet that a lot of
> functions use the same complex expression more than once (mine often
> do), and as such any optimization at parse-time would be of enormous
> benefit down the line.

These sound like good ideas, and might clear up some of the 
inconsistancies with the function solving that have appeared(I can't 
think of any right now, but there were a couple threads in 
povray.unofficial.patches and/or .advanced-users.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message