Is there any way to get the value of a function directly?  I know about
eval_pigment/pattern, which don't work.  What I want is this:

#local var = function(x,y,z);

Ie, given a function, and coordinants, return the value of that function.  I
didn't see anything in the Megapov code to do this, and I'd really like to.

Anyway, help?

Geoff

Post a reply to this message

In article <3a3bbf8c@news.povray.org>, Geoff Wedig 
<wed### [at] darwinepbicwruedu> wrote:

> Is there any way to get the value of a function directly? 

This is a feature which I have wanted for a long time...I have done a 
little work on implementing it, but haven't really tried. The syntax 
would be:
#declare FuncName = function {...}
#declare FuncVal = FuncName(XVal, YVal, ZVal);


> I know about eval_pigment/pattern, which don't work.

Uh, they don't? The eval_pattern() function should be perfect for this...

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote:

> In article <3a3bbf8c@news.povray.org>, Geoff Wedig 
> <wed### [at] darwinepbicwruedu> wrote:

>> Is there any way to get the value of a function directly? 

> This is a feature which I have wanted for a long time...I have done a 
> little work on implementing it, but haven't really tried. The syntax 
> would be:
> #declare FuncName = function {...}
> #declare FuncVal = FuncName(XVal, YVal, ZVal);

That's what I tried at first.  It makes sense, at least to me.  Eventually I
created a function and a macro, both with the same equation.  Not ideal, but
workable in my case.

>> I know about eval_pigment/pattern, which don't work.

> Uh, they don't? The eval_pattern() function should be perfect for this...

No, it gave me an error.  I don't have the code here, so I can't tell what
error it was, but once I saw that, I began to wonder what eval_pattern() was
for in the first place, since it wasn't for that.

Anyway, problem (mostly) solved (see above), so it's no big deal.

Geoff

Post a reply to this message

In article <3a3e0bb8@news.povray.org>, Geoff Wedig 
<wed### [at] darwinepbicwruedu> wrote:

> No, it gave me an error.  I don't have the code here, so I can't tell 
> what error it was, but once I saw that, I began to wonder what 
> eval_pattern() was for in the first place, since it wasn't for that.

The eval_pattern() function returns the float value of a pattern at a 
specific point...for a function pattern, this should be the result of 
evaluating the function at that point, at least as long as the result is 
in the 0-1 range and you don't have any special waveforms, 
transformations, or warps applied. If you post the problem code I will 
try to figure out what's wrong...
Something like this macro *should* work for most cases:
#macro Eval_Func(Func, X, Y, Z)
    eval_pattern(function {Func}, < X, Y, Z>)
#end
Of course, that could also be written:
#macro Eval_Func(Func, Pt)
    eval_pattern(function {Func}, Pt)
#end
Where Pt is a 3D vector.

The problem might be in the implementation of the isosurface 
functions...I don't understand the code very well, but it uses a lot of 
global variables, and may only work at render time...I've had problems 
with it before, trying to get a function pigment to work(specifying 3 
functions, for red, green, and blue).

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote:

> In article <3a3e0bb8@news.povray.org>, Geoff Wedig 
> <wed### [at] darwinepbicwruedu> wrote:

>> No, it gave me an error.  I don't have the code here, so I can't tell 
>> what error it was, but once I saw that, I began to wonder what 
>> eval_pattern() was for in the first place, since it wasn't for that.

> The eval_pattern() function returns the float value of a pattern at a 
> specific point...for a function pattern, this should be the result of 
> evaluating the function at that point, at least as long as the result is 
> in the 0-1 range and you don't have any special waveforms, 
> transformations, or warps applied. If you post the problem code I will 
> try to figure out what's wrong...
> Something like this macro *should* work for most cases:
> #macro Eval_Func(Func, X, Y, Z)
>     eval_pattern(function {Func}, < X, Y, Z>)
> #end
> Of course, that could also be written:
> #macro Eval_Func(Func, Pt)
>     eval_pattern(function {Func}, Pt)
> #end
> Where Pt is a 3D vector.

> The problem might be in the implementation of the isosurface 
> functions...I don't understand the code very well, but it uses a lot of 
> global variables, and may only work at render time...I've had problems 
> with it before, trying to get a function pigment to work(specifying 3 
> functions, for red, green, and blue).

Hmm, this is a deformation formula, so it ranges quite far (much further
than [0..1].  I'll check to see what error it gave when I get the chance.

Geoff

Post a reply to this message

In article <3a3e4b5e@news.povray.org>, Geoff Wedig 
<wed### [at] darwinepbicwruedu> wrote:

> Hmm, this is a deformation formula, so it ranges quite far (much further
> than [0..1].  I'll check to see what error it gave when I get the chance.

Ah, than this bit of code:
  value = ((value > 1.0) ? fmod(value, 1.0) : value);
will cause you some problems...it shouldn't make an error though, it 
will just make it repeat the [0, 1] range.

I'm thinking of modifying the pattern feature to allow values outside of 
[0, 1] to let these "special cases" work properly, it shouldn't be a big 
problem for older scenes. Also, I did write up a bit of code for 
allowing functions to be evaluated directly, but I never tested it. I 
posted it here or in povray.programming...maybe I will get back to work 
on it.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote:

> In article <3a3e4b5e@news.povray.org>, Geoff Wedig 
> <wed### [at] darwinepbicwruedu> wrote:

>> Hmm, this is a deformation formula, so it ranges quite far (much further
>> than [0..1].  I'll check to see what error it gave when I get the chance.

> Ah, than this bit of code:
>   value = ((value > 1.0) ? fmod(value, 1.0) : value);
> will cause you some problems...it shouldn't make an error though, it 
> will just make it repeat the [0, 1] range.

> I'm thinking of modifying the pattern feature to allow values outside of 
> [0, 1] to let these "special cases" work properly, it shouldn't be a big 
> problem for older scenes. Also, I did write up a bit of code for 
> allowing functions to be evaluated directly, but I never tested it. I 
> posted it here or in povray.programming...maybe I will get back to work 
> on it.

That would be the perfect solution, but creation a function and macro pair
isn't *too* awful, I've found.  This code was originally intended to
automatically calculate the bounding box of an isosurface based upon a
distorted coordinant space.  In fact, I need both forms of transformation
(to/from the new coordinants), so I couldn't have used the same function as
it eventually turned out, and ended up having to write the macros.

Geoff

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote:

> In article <3a3e0bb8@news.povray.org>, Geoff Wedig 
> <wed### [at] darwinepbicwruedu> wrote:

>> No, it gave me an error.  I don't have the code here, so I can't tell 
>> what error it was, but once I saw that, I began to wonder what 
>> eval_pattern() was for in the first place, since it wasn't for that.

> The eval_pattern() function returns the float value of a pattern at a 
> specific point...for a function pattern, this should be the result of 
> evaluating the function at that point, at least as long as the result is 
> in the 0-1 range and you don't have any special waveforms, 
> transformations, or warps applied. If you post the problem code I will 
> try to figure out what's wrong...
> Something like this macro *should* work for most cases:
> #macro Eval_Func(Func, X, Y, Z)
>     eval_pattern(function {Func}, < X, Y, Z>)
> #end
> Of course, that could also be written:
> #macro Eval_Func(Func, Pt)
>     eval_pattern(function {Func}, Pt)
> #end
> Where Pt is a 3D vector.

What you wrote works, but if you have:

#declare test_function = function { Func }

eval_pattern(test_function, Pt)

I get the following:  "error: numeric expression expected but func_id found
instead."

So it sortof works.

Geoff

Post a reply to this message

In article <3a3f7c6f@news.povray.org>, Geoff Wedig 
<wed### [at] darwinepbicwruedu> wrote:

> What you wrote works, but if you have:
> 
> #declare test_function = function { Func }
> 
> eval_pattern(test_function, Pt)

That won't work because you are just passing the function identifier. 
The eval_pattern() function takes a *pattern*. Use this instead:
eval_pattern(function {test_function(x, y, z)}, Pt)
The "function {}" is necessary, because that is what tells POV it is a 
function pattern.


Oh, and a partial workaround for the range problem:
#macro Eval_Func(Func, MaxRange, X, Y, Z)
    eval_pattern(function {Func(x, y, z)/MaxRange}, < X, Y, Z>)*MaxRange
#end

A slightly more complex macro could be written to handle any range, you 
just need to tell it what range your function will be using.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote:

> In article <3a3f7c6f@news.povray.org>, Geoff Wedig 
> <wed### [at] darwinepbicwruedu> wrote:

>> What you wrote works, but if you have:
>> 
>> #declare test_function = function { Func }
>> 
>> eval_pattern(test_function, Pt)

> That won't work because you are just passing the function identifier. 
> The eval_pattern() function takes a *pattern*. Use this instead:
> eval_pattern(function {test_function(x, y, z)}, Pt)
> The "function {}" is necessary, because that is what tells POV it is a 
> function pattern.


> Oh, and a partial workaround for the range problem:
> #macro Eval_Func(Func, MaxRange, X, Y, Z)
>     eval_pattern(function {Func(x, y, z)/MaxRange}, < X, Y, Z>)*MaxRange
> #end

> A slightly more complex macro could be written to handle any range, you 
> just need to tell it what range your function will be using.

Aha!  Thanks, Chris.  You've managed to solve two major problems for me in
as many days.

Kudos.

Geoff

Post a reply to this message