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

virtualmeet wrote:
> 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:

Sorry, but this is one of my pet peeves.

Yes, it will be faster, and win on that front.  If that's what you want, 
then you should never even look at ray-tracing.  Go get a 3d board from 
NVidia, and render all the triangles you want.

The problem is, you will LOSE on the quality front.  Try zooming in on a 
sphere in a CAD / modeling program, and you will see straight lines and 
hard angles.  Try zooming in on a sphere in POV-Ray, and you will see a 
smooth curve.  Why?  Because POV-Ray uses exact mathematical functions 
to represent objects.

You are essentially saying "If you just ditch your quality concerns, and 
use polygonal tessellation instead, you could have much faster renders!" 
  Well, if we WANTED to use polygonal tessellation, we wouldn't be using 
POV-Ray's isosurfaces.

...Chambers

Post a reply to this message

Ben Chambers <ben### [at] pacificwebguycom> wrote:
> The problem is, you will LOSE on the quality front.
>...
>You are essentially saying "If you just ditch your quality concerns, and
>use polygonal tessellation instead, you could have much faster renders!"
Hi,
What I'm saying is that there is probaly a way to render images faster by
using an "intelligent" parser: this "intelligence" came from given it some
geometrical propertys of points to render. Also, the quality of images will
be the same.
This technic is suitable for grid of points but can be used in every case
where points have some propertys in commun. In my case , the location and
number of points are known in advance and this was used to speed up the
parser. For PoV-Ray, point's number is unkown however there locations are
in the same ray (line) and this property should be used by the parser.
I think that people get confused with what I'm saying because there is a
deep thought that it's impossible to "improve" the parser (the part of the
code that perform math functions). What I'm saying is that the actual way
of doing math calculations (and this in every field where a parser is
needed) IS OVER : People should think about using geometrical propertys
when performing math calculations...
I don't know how well this will work with PovRay but for me I'm already
doing some calculations more than 30 times faster than before! and I'm
still using it "only" for 3D objects: It's much much more powerful with
dimensions > 3.
To be honest, I start thinking that some heivy demanding math applications
should be rewritten in the perspective to take advantage of that kind of
"technologie": The parser should "impose" the way math calculations will be
done and applications should be adapted to that fact.
Taha

Post a reply to this message