POV-Ray : Newsgroups : povray.programming : Which code evaluate Math functions (ie: isosurfaces) ? : Re: Which code evaluate Math functions (ie: isosurfaces) ? Server Time
27 Apr 2024 04:05:27 EDT (-0400)
  Re: Which code evaluate Math functions (ie: isosurfaces) ?  
From: virtualmeet
Date: 15 Feb 2007 23:05:00
Message: <web.45d529e5f1edfe3e975eec050@news.povray.org>
Ben Chambers <ben### [at] pacificwebguycom> wrote:
> a) your procedure will first evaluate a function X number of times and
> store the result, looking and values in this table later
Hi ,
That's it : I'm evaluating some defined fcts and store them in some tables
for a further use....as a variables. That's very important to think about
thoses tables as tables for NEW VARIABLES. I'll explain after why.

> and, if it can't find them, interpolating values?

That's not true: I'm not doing any interpolation. I'm still using the parser
to evaluate the part of the formulas that was not replaced by a predefined
fct.

Example : f(x,y,z) = cos(x) + y + z
I can define "only" one unary fct and use it to simplify the calculations,
for example : x' = g(x) = cos(x)
then the new formulas will be : F(x,y,z,x') = x' + y + z
As you can see, not all isosurface formula f was changed because I'm still
using a part of it ("y + z") and I made a replacement only for "cos(x)".
This new isosurface F is not the best one but it still advantageous to use
it. Why?
Two facts to know :
(1)You can give as much variables to the parser as you want without any
overhead in it's use.
(2) When analysing the opcode (the replacement of the humain math formulas
for the parser) the parser is faster when it comes to look for a value of
variables.

The fct F was made in this perspective :
I create a new variables x' so F is now a fct of 4 variables (no overhead
see (1)) and the formula of F has now only additions of variables (which is
what the parser like the most, see (2)).
What I'm doing is only trying to replace some part of the formulas by new
variables because variables don't have to be computed whereas a fct must be
evalueted by the parser.
To create this new formulas F, I had to create a new table X'[N] that holds
the N values of cosinus:
X[N] ===> X'[N]
   x ===> x' = cos(x).

For a grid of NxNxN, the required calculations to evaluate :

f  =  N^3*(cosinus evaluations) + 2* N^3 *(addition evaluations)

F  =  N*(cosinus evaluations) + 2* N^3 *(addition evaluations)

The difference between those evalutions came from the cosinus :
For "F" it's N but for "f" it's N^3.

Knowing that there is 3 axes and that the axe X has only N value, make
it possible to evaluate "cos(x)" with the maximum efficiency (only N
evaluations).
The knowlege of the geometry make it possible to store some fct values in a
table and use them as many times as needed when evaluating the entire
grid : That's where the geometry is important.

A normal parser can only hold informations inside one point evaluation, but
never for the entire process because it doesn't use any knowledge about the
gemetry of the domain where the fct is evalueted.

If something is not clear to you , just let me know.
Cheers,
Taha


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.