Warp wrote:
> slehar <sle### [at] gmailcom> wrote:
>> So it seems you can't do logical tests on the values of the parameters in a
>> function either!
> 
>   Any #-command is SDL. Any SDL-declared identifier is SDL. You can't use
> them in functions (except to build the function body).

To make things even more confusing, declared functions CAN be called by 
SDL during parse time.  For example:

#declare Foo = function(A) { A + 3 }
#declare Bar = Foo(6);

-- 
-The Mildly Infamous Blue Herring

Post a reply to this message

Blue Herring <pov### [at] bherringcotsenet> wrote:
> To make things even more confusing, declared functions CAN be called by 
> SDL during parse time.

  The function name, once #declared, is in the SDL namespace, and the SDL
can call that function. I don't think that's so confusing.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   The function name, once #declared, is in the SDL namespace, and the SDL
> can call that function. I don't think that's so confusing.

Never thought of it quite like that, that makes a lot of sense.

The distinction, like many other things, becomes largely second nature 
once you work with it enough, in my experience.

-- 
-The Mildly Infamous Blue Herring

Post a reply to this message

Hi all,

after some research, I finally found this discussion which talks about a subject
very close to my problem.

I am currently trying to generate a function that interpolates the values of a
physical parameter from a 3-dimensional array. I have the same kind of error
message as what has been posted here, when I use the following code (my array
is named SapceSample, and it has nx*ny*nz elements):

#declare ExtrapFunc=function(px,py,pz){

.... SpaceSample[floor(px)[floor(py)][floor(pz)] ...;

}

The error message is:

Parse Error: ... undeclared identifier 'px'.

So I suppose that when POV-Ray hits the '[', it goes back to the SDL language,
as Warp explained in message #4.

Does anyone know any simple means to go round this problem? Is the only solution
to get a continuous representation of my parameter to define nx*ny*nz functions?

Otherwise, I read some things about the 'density_file' and df3 files. It seems
like that kind of stuff could work for my interpolation, but also that it can
only be used in the scattering media. Is it possible to generate a function
from that?

Thanks a lot for your help,

Hibou

Post a reply to this message

CoucouHibou <wai### [at] yahoofr> wrote:
> Does anyone know any simple means to go round this problem?

  Currently user-defined functions do not support arrays. I don't think
there's any way around this limitation.

> Otherwise, I read some things about the 'density_file' and df3 files. It seems
> like that kind of stuff could work for my interpolation, but also that it can
> only be used in the scattering media. Is it possible to generate a function
> from that?

  You can create a pattern from a df3 file, and consequently you can create
a pattern function from one. You can then call this pattern function with
spatial coordinates and it will return the value of the df3 at those
coordinates (interpolated).

-- 
                                                          - Warp

Post a reply to this message

Wasn't it CoucouHibou who wrote:
>Hi all,
>
>after some research, I finally found this discussion which talks about
>a subject
>very close to my problem.
>
>I am currently trying to generate a function that interpolates the values of a
>physical parameter from a 3-dimensional array. I have the same kind of error
>message as what has been posted here, when I use the following code (my array
>is named SapceSample, and it has nx*ny*nz elements):
>
>#declare ExtrapFunc=function(px,py,pz){
>
>.... SpaceSample[floor(px)[floor(py)][floor(pz)] ...;
>
>}
>
>The error message is:
>
>Parse Error: ... undeclared identifier 'px'.
>
>So I suppose that when POV-Ray hits the '[', it goes back to the SDL language,
>as Warp explained in message #4.

Arrays are always evaluated at parse time, whereas px is only meaningful
at run time.

Inside functions, all you can do with arrays is things like this:
  http://www.econym.demon.co.uk/isotut/arrays.htm

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:

>   You can create a pattern from a df3 file, and consequently you can create
> a pattern function from one. You can then call this pattern function with
> spatial coordinates and it will return the value of the df3 at those
> coordinates (interpolated).

  That is what I did eventually. Thanks for your help.

  Hibou

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>
>   You can create a pattern from a df3 file, and consequently you can create
> a pattern function from one. You can then call this pattern function with
> spatial coordinates and it will return the value of the df3 at those
> coordinates (interpolated).

  Hi again,

  I have a little question now. Concerning the interpolate mode in the
density_file command: type 2 interpolation yields weird results! It creates
some big cubic holes in my pattern function while interpolate 1 is correct. I
thought the tricubic interpolation would be smoother and would not show this
mesh-like effect that we can see on the trilinear interpolation, but it seems
to have other defects that can not be compensated for.

  I do not know if this is normal as I do not know much about interpolation
weaknesses (maybe it is just that I have a tricky function, I actually did not
test this on spiral.df3). This is not crucial to my figure, as I compensate for
the lack of smooth interpolation by a higher resolution in the df3, but I am
just curious about it.

  Thanks for your answer,

  Hibou

Post a reply to this message

CoucouHibou nous illumina en ce 2008-10-03 11:57 -->
> Warp <war### [at] tagpovrayorg> wrote:
>>   You can create a pattern from a df3 file, and consequently you can create
>> a pattern function from one. You can then call this pattern function with
>> spatial coordinates and it will return the value of the df3 at those
>> coordinates (interpolated).
> 
>   Hi again,
> 
>   I have a little question now. Concerning the interpolate mode in the
> density_file command: type 2 interpolation yields weird results! It creates
> some big cubic holes in my pattern function while interpolate 1 is correct. I
> thought the tricubic interpolation would be smoother and would not show this
> mesh-like effect that we can see on the trilinear interpolation, but it seems
> to have other defects that can not be compensated for.
> 
>   I do not know if this is normal as I do not know much about interpolation
> weaknesses (maybe it is just that I have a tricky function, I actually did not
> test this on spiral.df3). This is not crucial to my figure, as I compensate for
> the lack of smooth interpolation by a higher resolution in the df3, but I am
> just curious about it.
> 
>   Thanks for your answer,
> 
>   Hibou
> 
> 
> 

This is a known bug. When the interpolation encounter a zero, it algorythm 
generate some negative values resulting in those ugly artefacts.

A workaround is to have a DF3 file with NO ZERO values, but small values. Then, 
you use a color_map to turn those small values to a zero density.
I've tryed spiral.df3 and interpolate 2, and the result is orrible.

If you want to try the 3.7 beta, it should be corrected.

-- 
Alain
-------------------------------------------------
If Barbie is so popular, why do you have to buy her friends?

Post a reply to this message

Alain <ele### [at] netscapenet> wrote:

> This is a known bug. When the interpolation encounter a zero, it algorythm
> generate some negative values resulting in those ugly artefacts.
>
> A workaround is to have a DF3 file with NO ZERO values, but small values. Then,
> you use a color_map to turn those small values to a zero density.
> I've tryed spiral.df3 and interpolate 2, and the result is orrible.
>
> If you want to try the 3.7 beta, it should be corrected.

  OK, thanks, it should be easy for me to generate a .df3 with no 0 value.
Concerning the 3.7 beta 28, I tried to compile it on my lab's computer, but
there were several errors which I could not correct as I do not know C... But
it is no big deal actually, what I have for the moment is really satisfactory.

  Thanks a lot,

  Hibou

Post a reply to this message