I've been looking at radiosity code recently and remark a few little things
I thought I could share :

Function ra_gather in radiosit.cpp :
- as already noticed we can avoid the call to VUnpack

- in the for() loop there is a
   scale = 1.0;
   ...
   VAddScaledEq(Colour_Sums, scale, Temp_Colour);
Hmm ?! Delete the unused variable "scale", and replace VAddScaleEq by
VAddScale

- the trace level and radiosity quality are changed in the for() loop, I
think we can safely move them outside
   opts.Radiosity_Quality = 6;
   #ifdef SAFE_BUT_SLOW
   opts.Quality_Flags = Quality_Values[opts.Radiosity_Quality];
   #else
   /* Set up a custom quality level with no area lights or light buffer */
   opts.Options &= ~USE_LIGHT_BUFFER;
   opts.Quality_Flags &= ~Q_AREA_LIGHT;
   if(!opts.Radiosity_Use_Media)
   {
     opts.Quality_Flags &= ~Q_VOLUME;
   }
   #endif
   /* Go down in recursion, trace the result, and come back up */
   Trace_Level++;
   Radiosity_Trace_Level++;

   for (...) {
   ...
   }

   Radiosity_Trace_Level--;
   Trace_Level--;
   opts.Quality_Flags = Save_Quality_Flags;
   opts.Options = Save_Options;

- We can avoid a max3 call if maximum_sample_brightness is not used :
   if(opts.Maximum_Sample_Brightness > 0.0)
   {
     max_ill = max3(Temp_Colour[0],Temp_Colour[1],Temp_Colour[2]);
     if (max_ill>opts.Maximum_Sample_Brightness)
     {
       max_ill = opts.Maximum_Sample_Brightness/max_ill;
       VScaleEq(Temp_Colour, max_ill);
     }
   }

- the inverse of depth is calculated twice (for the gradient and at the end
of the loop), we can replace with
   inv_depth = 1./depth;
   if (depth < opts.Radiosity_Dist_Max * 10.)
   {
     sum_of_inverse_dist += inv_depth;
     sum_of_dist += depth;
     gradient_count++;

     ...
     drdxs += dxsquared * Temp_Colour[pRED]   * inv_depth;
     ....
   }
   if (depth > opts.Radiosity_Dist_Max)
   {
     depth = opts.Radiosity_Dist_Max;
     inv_depth = 1./depth;
   }
   ...
   Inverse_Distance_Sum += inv_depth ;


all this is certainly negligeable compared to trace() calls but well..


I've also tried to improve the function ot_point_in_node in octree.cpp. It
used to return a long (??) that I replaced by a bool

bool ot_point_in_node(VECTOR point, OT_ID *id)
{
  DBL sized, minx, miny, minz, lox, loy, loz, hix, hiy, hiz;

  union
  {
    float f;
    long l;
  }
  size;                         /* MUST be float, NOT DBL */

  size.l = id->Size << 23;
  sized = (DBL) size.f;
  minx = (DBL) id->x * sized - OT_BIAS;
  lox = minx - sized * .5;
  if (point[X]<lox) return false;
  hix = minx + sized * 1.5;
  if (point[X]>=hix) return false;
  miny = (DBL) id->y * sized - OT_BIAS;
  loy = miny - sized * .5;
  if (point[Y]<loy) return false;
  hiy = miny + sized * 1.5;
  if (point[Y]>=hiy) return false;
  minz = (DBL) id->z * sized - OT_BIAS;
  loz = minz - sized * .5;
  if (point[Z]<loz) return false;
  hiz = minz + sized * 1.5;
  if (point[Z]>=hiz) return false;

  return true;
}

The idea is to escape as soon as possible. I don't know if a compiler can do
such an optimisation. Don't expect huge speed up (1% ?). By the way, how to
measure accurately the time (in windows) used by povray ? I get different
render time at each render :(

M

Post a reply to this message

Mael <mae### [at] hotmailcom> wrote:
> The idea is to escape as soon as possible. I don't know if a compiler can do
> such an optimisation. Don't expect huge speed up (1% ?). By the way, how to
> measure accurately the time (in windows) used by povray ? I get different
> render time at each render :(

  I don't want to sound negative, but if a speedup is so small that it
can't be measured, then it's probably not worth.
  If you can say "the rendering was about 20% faster" then it's worth. :)

-- 
#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

>   I don't want to sound negative, but if a speedup is so small that it
> can't be measured, then it's probably not worth.
>   If you can say "the rendering was about 20% faster" then it's worth. :)

no, no, you're not negative you're pragmatic (and i totally agree with you
:)

M

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote:
> if a speedup is so small that it
> can't be measured, then it's probably not worth.
>   If you can say "the rendering was about 20% faster" then it's worth. :)

If a change, however insignificant as a speedup, does clean up the code
(e.g. VAddScale vs VAddScaleEq), I would vote for it.

Post a reply to this message

In article <3e1f2449@news.povray.org> , "Mael" <mae### [at] hotmailcom> wrote:

> The idea is to escape as soon as possible. I don't know if a compiler can do
> such an optimisation. Don't expect huge speed up (1% ?). By the way, how to
> measure accurately the time (in windows) used by povray ? I get different
> render time at each render :(

Render scenes that take longer!

And take a closer look what other times the Window version reports!!!

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message