POV-Ray : Newsgroups : povray.programming : Which code evaluate Math functions (ie: isosurfaces) ? : Re: Which code evaluate Math functions (ie: isosurfaces) ? Server Time
9 May 2024 11:28:10 EDT (-0400)
  Re: Which code evaluate Math functions (ie: isosurfaces) ?  
From: virtualmeet
Date: 2 Feb 2007 01:55:00
Message: <web.45c2dd9ff1edfe3e920d46060@news.povray.org>
Warp <war### [at] tagpovrayorg> wrote:
> virtualmeet <tah### [at] yahoofr> wrote:
> > How about changing the raytracing technique to make it able to treat 64 rays
> > at the time?
>
>   I don't think it's possible to raytrace an isosurface 64 rays at a time
> and get a speed advantage.
Hi,
The geometrical parser has two features :
1) Parallel computations.
2) Optimisation du to the infos about the geometry of points to calculate.
When the advantage of the first feature is obvious, the real power should
came from the second feature : calculs simplifications by an "intelligent"
parser.
An interesting way to dig to exploit the second feature with PovRay:
The points are all in the same line, and the parser don't have any idea of
this.
To give you an idea of what I mean, suppose we want to calculate an
isosurface defined by :
f(x,y,z) = cos(x) + cos(y) + cos(z).
Suppose also that the ray is the axe X: all the points have the same value
for y and z. The geometrical parser should be able to exploit that and
reduce the above formulas to : f(x,y,z) = cos(x) + c1 + c2.
I made two suppositions:
1) The Iso formulas: I used this one because it's simple but the advantages
is not always garanted like the parallelising feature.
2) I supposed that the ray is the axe X but this is not always true == >can
be aranged by a variable changes ==> isosurface formulas should be changed
too...
Question: was it the best best choice to make a change to the the axe X?
To be continued... :)
Taha


Post a reply to this message

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