virtualmeet wrote:
> Warp <war### [at] tagpovrayorg> wrote:
>> Well, that's the problem: You are tesselating the isosurface, POV-Ray
>> doesn't. POV-Ray wouldn't benefit from your optimizations because they
>> can be used only when tesselating the isosurface.
> Hi,
> I know that the 3 steps in generating images by PovRay doesn't have clear
> frontiers like in thoses used in K3DSurf. However, it seems to me that
> everything can be splitted that way: If we don't see it, that's because we
> aren't used to it.
> How about changing the raytracing technique to make it able to treat 64 rays
> at the time? Is it really impossible to imagine that process ? I don't think
> so...

Your code does *NOT* render an isosurface!!! It is a simple voxel algorithm,
something not even closely related to an isosurface defined by a function.
As i told you very early on, you can already do exactly that in POV-ray with
the density file/function feature. The fact remains it is a *different*
algorithm that is *not* related to isosurfaces. As I have also explained
multiple times now, it does *not* make sense to implement isosurfaces based
on a voxel array. If you trace 64 or one ray is completely irrelevant, as
you voxel array will not be faster to traverse if you use one ray or 64 at a
time.

Warp and I have now multiple times explained things, and you keep repeating
the same incorrect statements. What you say just has neither head nor tail
when applied to ray tracing. In fact the algorithm you describe isn't even
the best scan-line rendering algorithm for voxels.

Please, first understand how ray tracing works in general, what isosurfaces
actually are, how intersection with isosurfaces are computed, and after all
that you will realise your misconceptions. Please!

	Thorsten

Post a reply to this message

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.

  There may be a speed advantage if the isosurface function is evaluated
*only once* for each ray. However, it isn't. Searching for the intersection
between the ray and the isosurface is an iterative process: the function
is evaluated many times for one intersection calculation, and each
consecutive evaluation depends on the previous evaluations (and thus
cannot be made in parallel). It's basically a refining process where
values closer and closer to the actual isosurface are obtained from
the previous calculations.

  Calculating 64 rays at a time would probably not give speed benefits:
The parameters for each function evaluation for each ray for each substep
are different, so they cannot be all calculated using the same variables.
Moreover, the amount of substeps to be done may change from ray to ray
(if I have understood the isosurface raytracing algorithm correctly).

  This would also be feasible only for the first recursion level (ie. the
rays starting from the camera). Reflected/refracted rays could not possibly
use this kind of parallelism in any reasonable way (because it's impossible
to tell which group of rays actually hit the isosurface when they have been
bouncing around the scene).

  And of course there would be problems inherent with tracing 64 rays
at a time: If part of those rays actually don't hit the isosurface (eg.
because there's another object in front), the function evaluations done
for them would go to waste.

-- 
                                                          - Warp

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> Warp and I have now multiple times explained things, and you keep repeating
> the same incorrect statements.

  I think it's commendable that someone is at least trying to develop
enhancements for POV-Ray. A civilized examination of the ideas and
problems involved might result in some new usable ideas. (And even if
not, at least it's a good way to understand how raytracing of isosurfaces
work.)
  Please don't shoot down people's enthusiasm. You and me have also been
young and ethusiastic at some point too.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Thorsten Froehlich <tho### [at] trfde> wrote:
>> Warp and I have now multiple times explained things, and you keep repeating
>> the same incorrect statements.
> 
>   I think it's commendable that someone is at least trying to develop
> enhancements for POV-Ray.

But it doesn't help if they refuse to first learn the basics. It is like
deciding to first climb mount Everest before ever having been on any other
mountain before.

And after all, this group is for programming with POV-Ray, not explaining
basic ray tracing. That is a prerequisite ;-)

	Thorsten

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   I think it's commendable that someone is at least trying to develop
> enhancements for POV-Ray. A civilized examination of the ideas and
> problems involved might result in some new usable ideas. (And even if
> not, at least it's a good way to understand how raytracing of isosurfaces
> work.)
Thanks Warp :). I tried to read some code from PovRay source but to
implement such parser need a full understanding of all the process used in
PovRay. I have already some understanding of the algorithm used inside it
but reading the code is another story. If it can't be implemented then it's
really a big "loss". Why? because every program that implented it will beat
all the others in terms of speed calculations: Nothing can compete with
them and this even with a "poor quality" implementation. I know a bunch of
programs (specially scientific) that can take huge advantages from it and I
think you understand what I'm talking about. I really hope to find a way to
exploit this parser in the raytracing.
Also, I found a way to exploit binary fcts for optimisations :)
I said before that this parser is going to beat the hardware in term of
speed, well now I made some tests that prove it : parallelising operations
is good, but exploiting the internal geometry propertys with the parser
give incredible results...
Cheers,
Taha

Post a reply to this message

virtualmeet schrieb:
> Hi Warp,
> In K3DSurf, I'm using mainly three steps to draw Isosurfaces:
> 1) Grid initialisation:
> Preparing the Grid: the grid is a 3D matrix that holds values obtained from
> parsing the Isosurface math formula. This process can be simplified to that
> code :
> [...]
> 
> The steps 2 and 3 are now extremely fast in K3DSurf: This part of code is
> able to treat
> (as Thorsten said) millions of triangles in less than a second.
> [...]

You should most of all keep in mind one thing:  The point about the 
POV-Ray isosurface is to avoid heavy precalculations and data storage. 
And as has been explained here grid or mesh based isosurface rendering 
requires both and furthermore has the principal limitation of a fixed 
resolution which is usually a huge disadvantage for perspective views.

Note you can speed up isosurface renders using precalculations as 
outlined on:

http://www.imagico.de/fast_iso/patch.html

but also note although this technique uses trees to store the 
precalculated function values it is still quite heavy concerning time 
and memory use although it only reduces the computations for the 
intersection test and does not do the actual intersection computation.

-- Christoph

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote:
> Note you can speed up isosurface renders using precalculations as
> outlined on:
>
> http://www.imagico.de/fast_iso/patch.html

Christoph Hormann <chr### [at] gmxde> wrote:
> Note you can speed up isosurface renders using precalculations as
> outlined on:
> ...
> http://www.imagico.de/fast_iso/patch.html
 Hi,
Thanks for the link and for the article.
You technique is excellent because it's traying also to reduce the time
processing by reducing the number of use of the parser. Inforttunately in
my case the number of use of the parser is fixed in advance...I had no hope
to make things better with such strategy. Also, optimising the marching cube
and the drawing was almost useless since the time saving is a fraction of
seconds. I had to look inside this black box called the parser and make
things work better inside it.
There was almost nothing to add to make it work better because Warp has done
the humainly possible optimisation (he said to me after that JIT compiling
will work better). The only ways left were :
Make it run faster ----> parallelising calculations
Make it smarter   -----> Give it the maximum informations about the math
object (it's geometry caracteristics).
Both of them can be achieved by using the "geometrical parser" sheme I
showed before with some code.
I hope to make some skilled people interested too and if I'm enthousiastic,
I really think that it's time to be : The results goes far further than
what I was hoping!
The last "discovery" :
It can do huge optimisation FOR EVERY UNARY DEFINED FUNCTIONS, like with
"cos(x)" I showed in one example.
ex: F(x) = log(cos(x) +x*sin(cos(log(x))) + x^3,9 *log(x*cos(x))
f(x,y,z) = z*F(x) +cos(F(y)) + F(z)*F(y) + log(F(z))*cos(F(x))
The geometrical parser will calculate this as fast as an isosurface defined
like this :
f(X,Y,Z) = c*X + Y + Z*Y +Z*X
It reduce to almost nothing and the time processing is almost the time it
tooks to read 7 single values from memory when A normal parser will take
huge time.
This is also available for user defined binarys fcts.
Scientific software are usually using data with dimension > 3, this parser
is the ultimate solution for most of them.
Taha

Post a reply to this message

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

"virtualmeet" <tah### [at] yahoofr> wrote:
> Question: was it the best best choice to make a change to the the axe X?
This can be decided depending on how the rays are generated, or how they are
related to each other: This is another information to use to optimise the
parser.
As I said in a previous message, it's going to be "hard" to use geometrical
property with PovRay, however my experience shows me that small changes can
have big consequences.
Cheers,
Taha

Post a reply to this message

Tests for f(x,y,z) =
cos(x) + cos(y) + cos(z) + 0.00001*cos(x*z) - 0.00001*cos(x) -
0.00001*cos(y)*( cos(x) +0.00001*cos(y*x*( cos(x) +cos(y*x) + cos(z*y))) +
0.00001*cos(y)) + 0.00001*sin(z-y)*( sin(x+z) +0.00001*cos(y*x*( sin(x*z)
+cos(y*x) + cos(z))) + cos(y)) - 0.00001*sin(z*y*cos(x))*( sin(x)
+cos(y*x*( sin(z) +cos(x) + cos(z*y))) + 0.00001*cos(y)) *cos(y*x*( sin(z)
+cos(y*x) + cos(y)))*x*y + 0.00001*cos(y) + 0.00001*cos(x) + 0.00001*cos(y)
+ 0.00001*cos(z) + 0.00001*cos(z) - 0.00001*cos(y*x) - 0.00001*cos(y)*(
cos(x*z) +cos(y*x*( cos(z) +cos(y) + cos(z*y))) + 0.00001*cos(y)) +
0.00001*sin(z-y)*( sin(x) +cos(y*x*( sin(z) +cos(y-x) + cos(z-y))) +
0.00001*cos(z*y)) - 0.00001*sin(z*y*cos(x))*( sin(x) +cos(y*x*( sin(x*z)
+cos(x) + cos(z))) + 0.00001*cos(y)) *cos(y*x*( sin(z) +cos(x) +
cos(z*y)))*x*y + 0.00001*cos(z*y)

ErrorTime +-(1/2)sec
Grid  OldParser  Parser64op Parser64op+optimCosSin  hardCodedfct
========================================================
120^3    41sec     24sec        13.5sec        11sec
140^3    65sec     40sec        23sec          13sec

1)This example is not advantageous for the new parser because it's not
otimising when the internal variable is different from"x", "y" or "z".
Also, binary fct are not optimised.
2)There is no opcode optimisation (from the original parser)
3)the hardcoded fct was made by compiling the isosurface formulas in C++
program.
Taha

Post a reply to this message