Hallo,

I have a problem concerning the use of array indices inside
a function.
Let me explain what I'm trying to do and what the problem is:

I have a 3D-grid with density values in a 3D-array called
Cube and must use this as density inside a media statement.
Beside a interpolation between these grid points,
ultimately POV-ray needs something like

   #declare F_DensPoint = function(x,y,z)
   { Cube[int((x-X0)/StepX)]
         [int((y-Y0)/StepY)]
         [int((z-Z0)/StepZ)] }

   (X0,Y0,Z0 is the origin of the density grid and
    StepX, StepY and StepZ are the grid distances)

to get values from the 3D-array.
If you use this function you get the error massage:
'Float expected but vector or color expression found'

This has clearly something to do with the array indices
control of the parser, because

  #declare F_Ix = function(x,y,z)
  { int((x-X0)/StepX) }

does NOT give an error message and returns a float and not a
vector.
I thought I found a workaround with

  #declare F_Ix = function(x,y,z){ int((x - X0)/StepX) }
  #declare F_Iy = function(x,y,z){ int((y - Y0)/StepY) }
  #declare F_Iz = function(x,y,z){ int((z - Z0)/StepZ) }

  #declare F_Cube =
  function(x,y,z,NX,NY,NZ) { Cube[NX][NY][NZ] }
  #declare F_DensPoint = function(x,y,z)
  { F_Cube(x,y,z, F_Ix(x,y,z), F_Iy(x,y,z), F_Iz(x,y,z)) }

but this gives the error message

'Expected 'numeric expression', undeclared identifier 'NX'
found instead'.

*#@!@^& .. the parser doesn't accept function parameters
as array indices!

I've tried several other possibilities, but that doesn't
work because you have to pass over x,y,z somewhere and the
parser stops when it finds this vector. You can use
functions as indices, but they may not contain x,y,z in the
parameter section and that is essential to find the correct
indices in the array.

My question is:
  Is there a way to circumvent this problem
  or if not
  is it possible to raise one of the blockages of the parser.

I've been working for months to develop interpolation
functions with matrices and they work perfectly, but now I
stumble over a not expected problem that blocks everything.

...help please...

Jaap Frank

Post a reply to this message

Jaap Frank wrote:
> 
> [...]
> 
> My question is:
>   Is there a way to circumvent this problem

No, arrays are a parse time language element in POV-Ray and can not be
used in (render time) user defined functions.  This is a very common
misunderstanding about user defined functions.  Although they look similar
in syntax to the normal script they are completely different.  An 'sqrt()'
in a function for example has nothing to do with an 'sqrt()' elsewhere in
SDL.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

On Fri, 2 May 2003 14:15:13 +0200, "Jaap Frank" <jjf### [at] xs4allnl> wrote:
> I have a 3D-grid with density values in a 3D-array called
> Cube and must use this as density inside a media statement.

I assume using density file format is not possible in your case ?
Perhaps maps are the solution you are looking for. I mean array:

#local A=array[2][2];
#local A[0][0]=0;
#local A[0][1]=.1;
#local A[1][0]=.2;
#local A[1][1]=.3;

can be expressed as

#local C=array[2];
#local C[0]=pigment{
  gradient y
  pigment_map{
    [0 color rgb A[0][0]]
    [1 color rgb A[0][1]]
  }
}
#local C[1]=pigment{
  gradient y
  pigment_map{
    [0 color rgb A[1][0]]
    [1 color rgb A[1][1]]
  }
}
#local P=pigment{
  gradient x
  pigment_map{
    [0 C[0]]
    [1 C[0]]
  }
}

and then
A[0,0]=P(0,0,0)
A[0,1]=P(0,1,0)
A[1,0]=P(1,0,0)
A[1,1]=P(1,1,0)

Of course this can be easy extended into 3 dimensions and coded with smart loops
but I would leave it for you because you are using 'advanced' group for post :-)

AVX

Post a reply to this message

On Fri, 02 May 2003 14:42:08 +0200, ABX <abx### [at] abxartpl> wrote:
>    [0 C[0]]
>    [1 C[0]]

   [0 C[0]]
   [1 C[1]]

ABX

Post a reply to this message

> ultimately POV-ray needs something like
> 
>    #declare F = function(x)
>    { Cube[int((x-X0)/StepX)]  }

I might get killed for proposing something so inefficient, but:
(I only treat one-dimensional array, the rest (including optimization
correction of errors, introduction of interpolation,...) I leave to you)

#declare F = function(x)
{
   #local I=1;
   #while (I<Max)

     select (x-X0-I*StepX, Cube[I-1],

     #local I=I+1;
   #end

   Cube[Max-1]

   #local I=1;
   #while (I<Max)

     )

     #local I=I+1:
   #end
}

-- 
merge{#local i=-11;#while(i<11)#local
i=i+.1;sphere{<i*(i*i*(.05-i*i*(4e-7*i*i+3e-4))-3)10*sin(i)30>.5}#end
pigment{rgbt 1}interior{media{emission x}}hollow}//  Mark Weyer

Post a reply to this message

On Fri, 02 May 2003 15:51:59 +0200, Mark Weyer
<wey### [at] informatikuni-freiburgde> wrote:
> I might get killed for proposing something so inefficient

Inefficent indeed. First of all there is a limited number of tokens to be used
in one function. You can split function into subfunctions but number of
constants used in functions is also limited in whole scene. Maps are also
limited in size IIRC, but their number in scenes is not so limited I think.
Moreover evaluation of function even if done with JIT compiler seems not as fast
as precompiled code of map evaluation. But measurement and comparison could be
interesting and (who knows?) perhaps surprised.

ABX

Post a reply to this message

> Jaap Frank wrote:
> >   Is there a way to circumvent this problem
>
> No, arrays are a parse time language element in POV-Ray and can not be
> used in (render time) user defined functions.  This is a very common
> misunderstanding about user defined functions.  Although they look similar
> in syntax to the normal script they are completely different.  An 'sqrt()'
> in a function for example has nothing to do with an 'sqrt()' elsewhere in
> SDL.

If you take this literally then this means you can't use arrays inside functions,
but I know that you can use them because my interpolation functions are
full with them, but they all have fixed indices.
I suppose you mean that POV-ray needs to know what the array indices are
at parse time and that it is not possible to fill in the correct indices on the
fly
during rendering.

I remember -it was in the seventies that I coded in machine language on a
Z80 processor (I know it's ancient, but I doubt that the principal is changed)
- that this can be done on the fly using indirect referencing a variable where
the indirect address gives the offset in the variable field. Maybe this was a
speciality of this processor, because I've heard that the famous 8086
processor that came later was not so advanced compared to this processor.
I suppose that the modern processors have this possibility too, but that the
way the arrays are reached in memory, this is already in use and we need
now indirect indirect referencing or something like that to do this.

But never the less, thanks for your reaction,

Jaap Frank

Post a reply to this message

On Fri, 2 May 2003 18:46:31 +0200, "Jaap Frank" <jjf### [at] xs4allnl> wrote:
> I suppose that the modern processors have this possibility too, but that the
> way the arrays are reached in memory, this is already in use and we need
> now indirect indirect referencing or something like that to do this.

It seems you have mistaken something. POV-Ray Scene Description Language is not
low-level language. It does not base on architecture of processor (even if there
was 'architecture' topic in last POV related image contest :-). The design
describes what functions can do. AFAIK current design does not include run-time
operations on arrays just like it does not allow vectors, strings or objects
there.

ABX

Post a reply to this message

Jaap Frank wrote:
> 
> If you take this literally then this means you can't use arrays inside functions,
> but I know that you can use them because my interpolation functions are
> full with them, but they all have fixed indices.
> I suppose you mean that POV-ray needs to know what the array indices are
> at parse time and that it is not possible to fill in the correct indices on the
> fly
> during rendering.

No, functions really don't support arrays.  They just support float
constants which can be array elements.  This is an important thing to
understand when working with functions.  Thinking 'it needs to know what
the indices are at parse time' leads into the wrong direction.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

"ABX" <abx### [at] abxartpl> wrote in message
news:v1p4bvcfgdeb7a2jvf79p7k1b2e9vkv9nr@4ax.com...
> I assume using density file format is not possible in your case ?
> Perhaps maps are the solution you are looking for. I mean array:
>
> #local A=array[2][2];
> #local A[0][0]=0;
> #local A[0][1]=.1;
> #local A[1][0]=.2;
> #local A[1][1]=.3;
>
> can be expressed as
>
> #local C=array[2];
> #local C[0]=pigment{
>   gradient y
>   pigment_map{
>     [0 color rgb A[0][0]]
>     [1 color rgb A[0][1]]
>   }
> }
> #local C[1]=pigment{
>   gradient y
>   pigment_map{
>     [0 color rgb A[1][0]]
>     [1 color rgb A[1][1]]
>   }
> }
> #local P=pigment{
>   gradient x
>   pigment_map{
>     [0 C[0]]
>     [1 C[0]]
>   }
> }
>
> and then
> A[0,0]=P(0,0,0)
> A[0,1]=P(0,1,0)
> A[1,0]=P(1,0,0)
> A[1,1]=P(1,1,0)
>
> Of course this can be easy extended into 3 dimensions and coded with smart loops
> but I would leave it for you because you are using 'advanced' group for post :-)

I always have some difficulty with understanding someone elses code, but I
think this is a way to interpolate between the grid points.
If this is what you mean with this code, then that is not my problem, because I
have a solution for that already.
Your code gives a linear interpolation, but I need a interpolation using
A0 + A1*x + A2*x^2 + A3*x^3 + A4*x^4 + ... = y
for the densities in the array vary a lot because these are the electron
densities around tens of atoms inside a molecule. (The density values vary
from 1.0*10^-20 to 1 within a few grid points)
I've developed functions that uses matrix calculation in order to solve
a N unknowns in N equations problem for me and they work fine.
You can choose the power of the polynomal as high as you wish ( or
as much patient as you have, because the parse time of the functions
grow with N-factorial, but power N=4 needs about a second).
My problem is that only during the rendering the indices for the various
grid points are known and POV-ray don't accept that.

Further the dimensions of the arrays (I've about ten different molecules)
are in the order of  40 by 40 by 40 grid points.
If you mean that it is possible to expend your solution to 40 points inside
these maps, then I've to accept a linear interpolation, for my solution
obviously can't be used. I will try this.

Thanks for your reaction,

Jaap Frank

Post a reply to this message