Chris Huff wrote:
> > 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).

Therein lies the rub. Syntax would be a bear. How would such a function
work? How would you make up for the lack of support for simple
operations such as / or sin()?
Personally, I'd like to see a sort of function-aware color map that can
do the work. For example, imagine if you could code a pigment as such:

pigment {
	function rgb
	function {x-floor(x)}
	function {y-floor(y)}
	function {z-floor(z)}
	}

In other words, you could tell the pigment that it expects to see three
functions, representing red, green, and blue, respectively. I would
expect a similar syntax could handle rgbt, rgbf, etc.

> > 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.

Precisely. The code for function optimization is embryonic but needs a
lot of constructive criticism to get flying, so I'll be posting to
povray.programming with the specifics for that.

> > 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).

That's possible for most functions, but since the bozo pattern matches
noise3d() anyway, there'd be no point in making it a function.
Still I see your point. Certainly the only claim it has to being a good
choice for a keyword is that it's known to be a noise function, and its
usage is a little confusing and strange.

> > 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.

No, I meant the actual parser. Problem is, adding those two lines means
that just about every file has to be recompiled, and it just complicates
the parsing process to have that many more tokens.

> > 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. :-)

clip() would have been my first choice, but the token wasn't available.
I suppose if I'm changing bozo() to rnoise() then I could just add
"clip" anyway, but it seems a shame to waste a perfectly viable token
that's more or less clear enough for the purpose.

> > 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.

Probably a lot of those inconsistencies have to do with the fact that
int_func3d() was never properly coded before I took a whack at it; it
was really just an empty shell of a routine, and that shell was in fact
massively buggy. (One thing I didn't explore yet in the optimization
code was to inline short functions if possible, which would also have
dealt with that problem.)
I know I encountered one, though, with my normal-solving calculations
for atan2(), one of the functions I added. For some reason, the code,
although mathematically it was perfectly sound, screwed up dramatically
in a test scene, and I was never able to find the problem.

Anyway, more on this in povray.programming, since this has become more
of a programming discussion.

Lummox JR

Post a reply to this message