Chris Huff wrote:
> Ah, ok. I somehow had the impression you were using MegaPOV source as
> your base. I found the code neatly arranged in a single block starting
> with this:
> #ifdef IsoBlobPatch
> /* Functions added by Lummox JR, June 1999 */

Hmm. That's interesting; I'll have to check out the MegaPOV code at some
point.
I think the additional functions can easily be separated from the
isoblob sections at any rate, though. The isoblob code is fairly
independent of the function changes I made.

> > I really don't know how this could be included in the function code
> > without greatly modifying it, since the code wasn't intended to go past
> > 3 arguments per function. (The so-called 4-argument functions are
> > actually just a declared function number plus 3 more arguments.) I've
> > always wanted to see if that could be arbitrarily extended; the
> > challenge is definitely intriguing enough for me to take it up sometime.
> 
> 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.

Another change I've contemplated before is the addition of two new
functions: precalc() and expr(), which would basically be used to give
the function "local variables" of a sort. Each function could be
analyzed after parsing, and reorganized to do any repeated or
unnecessary calculations first. As an example of what I mean:

sqrt(x^2+y^2)+sqrt(x^2+z^2)+sqrt(y^2+z^2)

There are several very simple changes that can be made here:

- Any ^2 reference can be changed to sqr(), which will be faster.
  (Similarly, optimization can change things to sqrt() and cub().)
- sqr(x), sqr(y), and sqr(z) can all be precalculated and then used
  later.

The optimized expression, although it looks more complicated, would save
considerable evaluation time:

precalc(sqr(z),
  precalc(sqr(y),
    precalc(sqr(x),
      sqrt(expr(3)+expr(2))+sqrt(expr(3)+expr(1)+sqrt(expr(2)+expr(1))
  )))

And as you can see, expr(N) references the Nth cached value; basically
all the code has to do is check the very bottom of the stack and work
upward, since the precalc() function has already calculated the first
value. (Actually, the code I've got in mind is 0-based, not 1-based, but
you get the idea.)
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.
I've written some test code (which I haven't even looked at in months)
that will analyze the function for a repeated expression, keeping track
of whether it actually has a complete expression or not, and whether the
constants match, etc. It looks for the longest expressions first, to
maximize the savings. And if those can be further broken down, so be it. 

> > BTW, I've gone ahead and added the Noise_raw function to texture.c. I
> > gave it a function name "bozo", to avoid having to add one more keyword
> > to the parser.
> 
> Sounds interesting, although the use of "bozo" would have to be changed
> before it is distributed...
> Maybe call it rnoise()?

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 chose
this one because it's a pain in the butt to add tokens to the parser.

> > I added two new functions while I was in there:
> >
> > range(v,min,max)  -- basically a shortcut for min(max(v,min),max)
> 
> Why not call it "clamp()"? I think it is more explanatory.
> BTW, I use this code when I need this function, although having it hard
> coded is probably a good idea:
> #declare clamp = function {min(y, max(x, z))}
> clamp(value, minimum, maximum)

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'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:

- Any expression made more than once (or a function with all the same
  arguments) can be calculated once and re-used. The longer the
  expression or the more it is used, it will be more likely to save
  both space and time. (Testing for a complete expression is difficult,
  since you have to check on how each function affects the stack.)
- Any operations based solely on constants can be evalulated at
  optimization time and reduced to one single constant. Thus sqrt(2)
  and even a simple -(1) needn't be calculated each time.
- n+(-m) can be changed to n-m
- n*(a/m) can be changed to (n*a)/m by association
- n*(-1) or n/(-1) can be changed to (-n)
- n*a+n*b can be replaced with n*(a+b)
- n*n or n^2 can be replaced with sqr(n)
- sqr(n)*n or n^3 can be replaced with cub(n)
- n^a*n^b can be replaced with n^(a+b)

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.

Lummox JR

Post a reply to this message

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

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

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

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

I suppose this is probably the only feasible way to go...one alternative 
would be to have vector_function, float_function, color_function, etc as 
separate kinds of functions. There is just something I don't like about 
the multiple-function method, but it would be the easiest and simplest 
way of implementing this feature.


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

Well, what if that function gets added to the list of functions useable 
outside of isosurface functions?(I think everything available in 
isofunctions(?) should be available outside them as well, and most of 
what is available outside should be available inside them.)
Since the range keyword is already in use(I know it is used for photons, 
maybe also for other things), you would have the same function with 
different names depending on where it is used(it would be clamp or clip 
outside isofunctions, and range inside them). Bad idea.


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

Ok. I will look at the programming issues in .programming...

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

Post a reply to this message

On Sat, 18 Mar 2000 17:30:46 -0500, Chris Huff wrote:
>In article <38D### [at] aolcom>, Lummox JR <Lum### [at] aolcom> wrote:
>
>> Hmmm... I wonder if they're mine.
>
>Yep.
>
>
>> All those function changes I sent out to Ron Parker for the Superpatch.
>> The isoblob patch I don't think is in there, though.
>
>In where? MegaPOV, or the source changes you sent to Ron? The isoblob 
>patch is included in MegaPOV, if that is what you meant.

There's really no difference, y'know.  My Superpatch 3.1g was swallowed
whole by MegaPOV, including the isoblob and other patches Lummox JR 
sent me.

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

When creating an outdoor scene, "Floating Skyscrapers"  (unfinished, very!)
last year, i wanted nice rolling hills in the distance.  Not too symmetrical,
not too uniform, with ridges and hills and broad shallow depressions and
rises.     But most of all, I needed to know altitude(x,y) so I could place
buildings, cars, etc.

After expeimenting with some ideas, i settled on a mesh on an x,y grid with z
values determined by a hill(x,y) function.    This hill function is a sum of
many individual hill component functions.  It worked great - but due to a
compiler bug, didn't render right and I gave up.    Turns out that the
compiler bug was due to a hardware problem - almost everything ran 99.999% of
the time, but anyway that's a long story... (it may also explain the colour
dispersion bugs i had back when i was working on that.)


I gave the hill component function, a macro named bulge( ), lots of
parameters to give it variation and nonsymmetry.  I write these functions
intuitively, but it's based on a gaussian function   exp(-r^2).

 
I'll post a copy of my FSLAND.POVI  file in the scene-files group.




> I'm hoping to make an image which will mostly be a series of grassy 
> hills in the rain. I've got the clouds, I think, and the rain's a task 
> I'm willing to take a shot at. Grass will be a nightmare of its own and 
> obviously a lot of fudging is required. I've started working with the 
> hills, but that's where I've run into the first problems. 
> I really don't want to generate any height maps for this one. My 
> preference is to use an isosurface (I'm using the Superpatch) with a 
> kind of hilly function. I thought of multipying a couple of sine waves 
> together, but the results on that have so far been pretty terrible. 
> ... 
> Lummox JR 

-- 
Daren Scot Wilson
dar### [at] pipelineocm
www.newcolor.com

Post a reply to this message