|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I prepare my first isosurface
as default from library and my function as modifier of it
my function is rather complicated becouse
this is calculation of definite integral of sqrt of derivative
of equation parametrized with coordinates
I have divide equation to subfunctions of course
this is not possible to simplify this becouse the same
function is sometimes available this way: f+ln(f)
I want such function, I have such function and it works properly
what is problem ?
I have checked that simple R function is called
nearly 400 times by subfunctions for the same coordinates,
subfunctions are also called many times
and I want ask if there is optimized calling with the same arguments ?
function at call should checks last called arguments
and compare with new one
if are equal than return remebered result instead of calculated
to avoid slower render time for simple isosurface
this feature should be switched inside isosurface
(i.e. keyword "fast_results")
but perhaps there is already something like this ....
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3a07db72@news.povray.org>, "Wlodzimierz ABX Skiba"
<abx### [at] abxartpl> wrote:
> I have checked that simple R function is called
> nearly 400 times by subfunctions for the same coordinates,
> subfunctions are also called many times
> and I want ask if there is optimized calling with the same arguments ?
> function at call should checks last called arguments
> and compare with new one
> if are equal than return remebered result instead of calculated
This type of optimization has been discussed a while ago, I think the
discussion started in povray.general and spread to .programming...
Unfortunately, nobody has ever done anything about it. There don't seem
to be any people who understand the isosurface code well enough and have
the time to implement this. Or maybe, like me, they are simply waiting
for 3.5 to come out so they don't have to forget a lot of what they
learned and have a cleaner, more stable set of code to work with.
> to avoid slower render time for simple isosurface
> this feature should be switched inside isosurface
> (i.e. keyword "fast_results")
This could be done at parse time so it wouldn't slow down even the
simplest functions, so this option would be unnecessary.
Another possibly useful feature would be the ability to use variables in
the function, for example:
function {
A = sqr(x+y*Func(x,y,z));
Func2(A, A+2, x+A/2)
}
And of course, functions allowing different numbers of parameters...
--
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:
: Another possibly useful feature would be the ability to use variables in
: the function
And conditional evaluation and recursive functions.
When all those three are supported, it will be possible to make fractal
functions (such as mandelbrot, julia... almost any).
Of course it would need some optimization so that it will not take huge
amounts of memory nor time. Tail recursion optimization is one of the most
obvious and most effective.
(For those who don't know, tail recursion optimization means that if the
recursive call is the last thing in the function, then the this call doesn't
internally generate a new function call (putting parameters in the stack etc),
but it just jumps to the beginning of the function almost as if it was just
a while-loop. For example, this type of function could be something like:
#declare Fact = function { x<1 ? 1 : x*Fact(x-1) }
which calculates the factorial of x; since the recursive call is the last
thing in the function, it can be made as a loop instead of recursive
function calling.)
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote in message ...
>This type of optimization has been discussed a while ago, I think the
>discussion started in povray.general and spread to .programming...
therefore continue is at p.p :-)
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote in message <3a092379@news.povray.org>...
> #declare Fact = function { x<1 ? 1 : x*Fact(x-1) }
I don't know whole architecture of source code
but perhaps this is impossible to call to name which
declaration is not finished
but perhaps this could be done with function "self"
which means pointer to currently declared function
this is known pointer during declaration I think
or if not it could be recived during trace,
am I wrong ?
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Guess what? This works just fine in MegaPOV 0.5a!
#declare Fact = function{ 1 }
#declare Fact = function { x<1 ? 1 : x*Fact(x-1) }
--
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
> <snip>
> And of course, functions allowing different numbers of parameters...
Why not just use shaders to specify the isosurface funcs?
--
Bye
Pabs
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Pabs wrote in message <3A0B61CC.86B37226@hotmail.com>...
> Chris Huff wrote:
> > And of course, functions allowing different numbers of parameters...
> Why not just use shaders to specify the isosurface funcs?
I don't know shaders but I think
is better to learn and use one language instead of two
but what's more important isosurface will be in 3.5 and shaders not
I have an idea how to include parameters and locals to functions
I work on it
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3A0B61CC.86B37226@hotmail.com>, Pabs <pab### [at] hotmailcom>
wrote:
> Why not just use shaders to specify the isosurface funcs?
I assume you mean replace functions with shaders...that would most
likely be slower. Isosurface functions are designed to take a simple
equation and return a float value, shaders take all sorts of
instructions and calculate a color. It would also be harder to write the
scene code...functions are a lot simpler than shaders.
I think a syntax like this would be most useful:
#declare Sphere =
function(x, y, z, Px, Py, Pz, R)
{
r - sqrt((x-Px)^2 + (y-Py)^2 + (z-Pz)^2)
}
The "x, y, z" variables would be the default, but you could specify your
own variables to use instead.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mark Wagner <mar### [at] gtenet> wrote:
: Guess what? This works just fine in MegaPOV 0.5a!
: #declare Fact = function{ 1 }
: #declare Fact = function { x<1 ? 1 : x*Fact(x-1) }
Looks like a kludge (I suppose that the first line is to fool the parser
to not to issue an error for the 'Fact()' call in the second line) :)
I suppose that this kind of recursion is not speed-optimized in the current
code.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |