Hello again,
My message is to say that there is likely a way to calculate isosurfaces
much more faster than what povray is doing now.
I was looking for a way to accelerate isosurfaces calculations for K3DSurf
but the parser I'm using (fparser from warp, I think it's one of your
developer but I'm not sure) was already optimised (except for the pow fct)
and it's the fastest one I've found on the net. Doing better requires then
a new "methodology" and that's the subject of my message.
The idea is quite simple and the consequences can be very interesting:
Isosurfaces  (the same for simple functions ) should be considered as a
"single math object". By "single math object " I mean that to be
calculated, the parser should do it in one pass and not point by point. To
do this, we should change the stack the parser is using to store the
intermediate value.
To explain better, suppose we have a grid of 4x4x4 points. The modified
parser will use an internal stack with the size of 4x4x4xStackSize
(StackSize is the normal size used by the original fparser).
I'm getting already some interesting results by using this methodology:
** This modified parser run from 1.5 to 5 times faster than the original
parser, however the fastests results came from isosurfaces with pow fcts,
witch was optimised for fparser. For isosurfaces with only trigonometric
fcts (cos, sin...), the midified parser run between 1.5 to 2.5 times
faster.
There is a windows binary available at :
http://sourceforge.net/project/showfiles.php?group_id=142839&package_id=156961
that implement this new parser and you can test some isosurfaces by
activating/deactivating it and comparing the time processing (This binary
was made for some testers and the code is note available yet because it's a
big mess :) ). This parser works only for grid =4, 8, 12... (grid mod 4 =0)
** This parser run faster with new CPU : this is due to the height amount of
memory in the CPU cache (L1 and L2).
** More isosurfaces fct is "big", more it run faster.
** This parser is heighly parallelisable and can take advantage from
multiCPU machines.
I think that PovRay can also use this methodology and if you want more infos
or some code from my implementation, just let me know. Also, you'll not have
to write the hole parser, only the part that evaluate the opcode should be
modified.
Cheers,
Taha
PS: sorry for my english.

Post a reply to this message