POV-Ray : Newsgroups : povray.programming : Which code evaluate Math functions (ie: isosurfaces) ? : Re: Which code evaluate Math functions (ie: isosurfaces) ? Server Time
20 Apr 2024 11:43:10 EDT (-0400)
  Re: Which code evaluate Math functions (ie: isosurfaces) ?  
From: virtualmeet
Date: 25 Jan 2007 01:35:00
Message: <web.45b84eabf1edfe3e8d619fa70@news.povray.org>
> Thorsten Froehlich <tho### [at] trfde> wrote:
> This is not the same as an isosurface, and even
> though sampling a voxel array is fast, it is also extremely inaccurate
> unless you assume you have infinite memory.
Hi,
You're right about the memory requirements, it grows fast with the grid.
However, I resolved this problem by using a small grid of 4x4x4 points and
make the parser able to perform 64=4x4x4 operations in one pass. The
results I talked about were obtained by using this small grid. I made some
tests with grid up to 20x20x20 but I had some stranges results and I think
this is due to the memory cache in the CPU : Performances should grow with
the grid but this is not always the case!
So even with a small grid the results are worthy because as I mentioned
before, it was impossible to made a better parser than the original one by
following the same way of handling the calculations.
I'm not an expert in PovRay but I know that it can split the calculations of
isosurfaces to be done in many CPU (SMP archi). if I'm right, then it's
possible to use the same sheme as what I'm doing with isosurfaces in
K3DSurf, and using a custum parser that can handle as low as 64 operations
in one pass can have significant results.
Just to give you a simple example of the the code I'm using :

From the original Eval() fct in the paser I'm using:
-------------------------------------------
    for(IP=0; IP<ByteCodeSize; ++IP){
        switch(ByteCode[IP])
        {
         case   cCos: Stack[SP] = cos(Stack[SP]);
                      break;
         case   cSin: Stack[SP] = sin(Stack[SP]);
                      break;

......
Where Stack = new double[StackSize];
---------------------------------------------

Changed to :
---------------------------------------------

    for(IP=0; IP<ByteCodeSize; ++IP)
    {
        switch(ByteCode[IP])
        {
         case   cCos:
NewStack = &StackArray[SP*64];
for(i=0; i<64; i++) NewStack[i] = cos(NewStack[i]);
break;

         case   cSin:
NewStack = &StackArray[SP*64];
for(i=0; i<64; i++) NewStack[i] = sin(NewStack[i]);
break;

......
Where StackArray = new double[64*StackSize];
-------------------------------------------------

I'm not sure if you understand exactly what I'm saying (because of my poor
english) but all I can say for now is that it works for me and it should
work for every mathematical parser. I'm doing some tests for more that 3
months now and for me one thing is sure: writing a better math parser is
impossible by using the same sheme, because the fparser is the best of it's
kinde. Using the "topology" of the mathematical object to sample
calculations is one way to go further than what we are used to.
Moreover, we can make "scalables" math parsers to take advantage of
differents CPU by increasing the amount of operations that it can handle.
Who knows, perhaps in one century, we 'll have some CPU with enought memory
to store a "Super Stack" of 1 Gig  :).
Cheers,
Taha


Post a reply to this message

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