Mael wrote:
> 
> Of course it will be nice to see how it improves a "typical" scene (as far
> as such a thing exists..) and hopefully Andreas Kaiser will give us the
> numbers for benchmark.pov (though on a PIII 850MHz I can understand it might
> take him some time :) , Anyway when testing a modification in the code it
> seems normal to me to use a test case that makes the improvement evident.
> What if benchmark.pov is only 1% faster ? Will you say the patch is not
> worth and deprive all menger sponge builders out there of a nice speed up ?
> :))

If the gain for benchmark.pov is only 1% i would probably never do the 
work of rewriting the code Andreas posted to POV-Ray syntax to try it.

There are mainly 3 criterias for a patch to make it into MegaPOV or 
ultimately official POV:

- the patch is a useful improvement of functionality/performance
- the patch is well written, well tested and compatible to current POV-Ray.
- the patch is well documented (source and user level)

Since one of these points is not met and the other (documentation) is 
not so relevant in this case the third is even more important.

But don't get me wrong, to me this patch seems quite useful at the first 
glance so i would encourage Andreas to show additional test results and 
code usable for current POV.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 25 Oct. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

In article <rn4### [at] tritonimagicode> , Christoph Hormann 
<chr### [at] gmxde>  wrote:

> But don't get me wrong, to me this patch seems quite useful at the first
> glance so i would encourage Andreas to show additional test results and
> code usable for current POV.

I agree.

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote:

>In article <rn4### [at] tritonimagicode> , Christoph Hormann 
><chr### [at] gmxde>  wrote:
>
>> But don't get me wrong, to me this patch seems quite useful at the first
>> glance so i would encourage Andreas to show additional test results and
>> code usable for current POV.
>
>I agree.
>

OK, i'll rewrite it for the official version and then run the internal
benchmark.

Andreas

Post a reply to this message

I find it amazing that folks just picking up C/C++ for the first time
exclusively for the purposes of improving POV-Ray have been so successful...
whereas I've been studying Computer Science for 4 years now and I haven't
the foggiest what I could do to improve the code (that, or I can't read it).
Sigh. This is not encouraging. I'll put on my dunce hat now... <:(

-- 
Anthony Bennett

PS: I just finished my Operating Systems final* today... This means I'm
done. I'm sticking around one more semester for Japanese III and Scientific
Visualization, but I'm basically done with CS. Yay!

*Most evil exam ever. Ever.

Post a reply to this message

"Tony[B]" <ben### [at] catholicorg> wrote:

>I find it amazing that folks just picking up C/C++ for the first time
>exclusively for the purposes of improving POV-Ray have been so successful...
>whereas I've been studying Computer Science for 4 years now and I haven't
>the foggiest what I could do to improve the code (that, or I can't read it).
>Sigh. This is not encouraging. I'll put on my dunce hat now... <:(

Take it off :)
I've been using C for several years, so the step to C++ was a small
one. Before i started to work as a software developer i've studied
physics, so the math and physics used in POV-Ray were no problem for
me. The latter was the main reason to play around with the POV-Ray
code: I was going to lose all my math knowledge completely.


>-- 
>Anthony Bennett
>
>PS: I just finished my Operating Systems final* today... This means I'm
>done. I'm sticking around one more semester for Japanese III and Scientific
>Visualization, but I'm basically done with CS. Yay!
>
>*Most evil exam ever. Ever.

Congratulations.

Andreas

Post a reply to this message

Next try.


The version below isn't as fast as my C++ version as it doesn't use a
BBOX tree for the inverted children. Timing values for a level 4
menger sponge are:

Original Version: 2207 seconds
this C Version:    523 seconds
my C++ Version:     35 seconds

benchmark.pov, rendered with -w384 -h384 +a0.3 +v -d -f -x

Original Version: 5987 seconds
this C Version:   4280 seconds

 
Add this flag to objects.h:

#define CSG_SIBLING_IGNORE_FLAG 0x2000000L /*AKA: csg internal flag*/

/*****************************************************************************
*
* FUNCTION
*
*   All_CSG_Intersection_Intersections
*
* INPUT
*
* OUTPUT
*
* RETURNS
*
* AUTHOR
*
*   POV-Ray Team
*
* DESCRIPTION
*
*   -
*
* CHANGES
*
*   Sep 1994 : Added code to count intersection tests. [DB]
*   Dec 2003 : Changes to enable early escape and reduce number of
*              'Inside_Object()' tests. [AKA] 
*
******************************************************************************/

static int All_CSG_Intersect_Intersections (OBJECT *Object, RAY *Ray,
ISTACK *Depth_Stack)
{
  int Maybe_Found, Found;
  OBJECT *Current_Sib;
  ISTACK *Local_Stack;
  INTERSECTION *Sibling_Intersection;

  Increase_Counter(stats[Ray_CSG_Intersection_Tests]);
  
  /* To get an intersection for a CSG-Intersection object, it must be
     inside of all siblings. If a ray misses one ore more siblings
     completely, the CSG-Intersection isn't hit by this ray. */

  Local_Stack = open_istack ();

  /* 1st step: get intersection points of all children */
  for (Current_Sib = ((CSG *)Object)->Children;
       Current_Sib != NULL;
       Current_Sib = Current_Sib->Sibling)
    {
    if (Ray_In_Bound (Ray, Current_Sib->Bound) && 
        All_Intersections (Current_Sib, Ray, Local_Stack))
      {
      /* the child's intersection points have been added to
         'Local_Stack', clear the 'ignore' flag. */
      Clear_Flag(Current_Sib, CSG_SIBLING_IGNORE_FLAG);
      continue; /* try the next one */
      }

    /* If we reach here, the ray was out-of-bounds and/or the child
       wasn't hit. */
    if (!Inside_Object(Ray->Initial, Current_Sib))
      {
      /* Ray's origin is outside of 'Current_Sib' and doesn't hit any
         of it's boundaries ==> we can escape here. */
      close_istack (Local_Stack);
      return(false);
      }
    else
      {
      /* Ray's origin is inside of 'Current_Sib' and doesn't hit any
         of it's boundaries, so the entire ray is inside of
         'Current_Sib'.
         ==> this sibling can be ignored in the 2nd step as any
             intersection is inside of it, so set the 'ignore' flag.*/
      Set_Flag(Current_Sib, CSG_SIBLING_IGNORE_FLAG);
      }
    }

  /* 2nd step: for each entry in 'Local_Stack' check whether the
     intersection point is inside of each sibling */

  Found = false;

  while ((Sibling_Intersection = pop_entry(Local_Stack)) != NULL)
    {
    Maybe_Found = true;

    for (Current_Sib = ((CSG *)Object)->Children;
         Current_Sib != NULL;
         Current_Sib = Current_Sib->Sibling)
      {
      if (Test_Flag(Current_Sib, CSG_SIBLING_IGNORE_FLAG) ||
          (Current_Sib == Sibling_Intersection->Object))
        continue; /* with the next sibling */

      if (!(Current_Sib->Type & LIGHT_SOURCE_OBJECT) ||
          ((LIGHT_SOURCE *)Current_Sib)->Children)
        {
        if (!Inside_Object (Sibling_Intersection->IPoint,
                            Current_Sib))
          {
          Maybe_Found = false;
          break; /* try the next intersection */
          }
        }
      }

    if (Maybe_Found)
      {
      if (Point_In_Clip (Sibling_Intersection->IPoint, Object->Clip))
        {
        if (Test_Flag(Object, MULTITEXTURE_FLAG))
          {
          Sibling_Intersection->Csg = Object;
          }

        push_copy(Depth_Stack, Sibling_Intersection);

        Found = true;
        }
      }
    }

  close_istack (Local_Stack);

  if (Found)
  {
    Increase_Counter(stats[Ray_CSG_Intersection_Tests_Succeeded]);
  }

  return (Found);
}

Post a reply to this message

Andreas Kaiser wrote:

> Next try.
> 
> 
> The version below isn't as fast as my C++ version as it doesn't use a
> BBOX tree for the inverted children. Timing values for a level 4
> menger sponge are:
> 
> Original Version: 2207 seconds
> this C Version:    523 seconds
> my C++ Version:     35 seconds
> 
> benchmark.pov, rendered with -w384 -h384 +a0.3 +v -d -f -x
> 
> Original Version: 5987 seconds
> this C Version:   4280 seconds

Almost 30% for benchmark.pov! That is a huge improvement! Great work, if 
it indeed produces 100% identical results. I hope you can make a patch 
that can be someday included in official version.

Severi Salminen

Post a reply to this message

Andreas Kaiser <kai### [at] siemenscom> wrote:
> The version below isn't as fast as my C++ version as it doesn't use a
> BBOX tree for the inverted children.

  Why not?


-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Andreas Kaiser <kai### [at] siemenscom> wrote:
> I've been using C for several years, so the step to C++ was a small
> one.

  Actually the step from C to C++ is much much larger than you might
believe. Much larger than for example from Java to C++.
  I have seen too much C++ code made by C coders and it looks horrible.
There are tons of things that can be done much better in C++ than in C,
but due to the C coder bad habits they can't (or even refuse) to
understand... :)

  But this is, of course, off-topic.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Hello,

> Next try.

First thank you for your work and patience..
 I've tried to apply your patch and decided to test it with chess2.pov (in
scenes/advanced). And (you're going to hate me :)  .. I don't get the same
image (too bad because it was faster :) . I may have messed up applying your
modification or it could be a compiler issue so if you (or someone else) can
check.. For information I've compiled on a linux redhat 7.2 PIII 1.13Ghz (in
fact a bi PIII), gcc version 2.96 and rendered with "+w640 +h480 +a0.3 +fn
+Ichess2.pov"
I'll try again later on a more recent system

M

Post a reply to this message