Just like Christoph reads radiosity I spend some at night when my daughter had
fever reading printed sources of parametric object. Can't find any speed up
yet but have some notes already:

1. I have already partially pointed first problem at
http://abx.art.pl/pov/patches/uvparam.php. In MegaPOV UV coordinates returned
for objects during intersection test were stored on intersection stack with
push_uv_entry while in 3.5 it is changed. UV coordinates are written to fields
of objects: last_u and last_v. It is correct if we assume that between
intersection test and any normal or uv calculation won't be another
intersection test. If there are plans for allowing functions to be placed as
texturing parameters and pland for allowing trace to be placed in functions
that it is wrong assumptions imo. I think storing uv coordinates between
intersection test and normal/uv calculations is more safe when performed via
intersection stack. Please clarify my opinion if I'm wrong.

2. If above wories are not worth anything than my suggestion is to connect
      DBL last_u, last_v;
fields from Parametric_Struct definition to one structure
      UV_VECT last;
This way all assigments to/from "last" can be optimized to use Assign_UV_Vect
which is optimized with memcpy.

3. When contained_by in parametric object is parsed then Make_BBox is called
and then Compute_Parametric_BBox(Object) is called as next. There is no need
for Make_BBox becouse it is either initialized in Create_Parametric and again
overwritten in Compute_Parametric_BBox.

4. It could be leaved for security but Parametric->Trans is always assigned
within Create_Parametric and not removed until Destroy_Parametric so no need
for all those blocks with if(Param->Trans==NULL) in whole fparam.cpp.

5. In line 222 there is a condition:
  if (Depth1 == Depth2) Depth1 = 0;
Somehow I'm not sure it is correct. When ray intersects container only once
then intersection test will return all intersection between container and
camera.

6. I think it is a bug but I'm not sure. Why in lines 183-184 of fparams.cpp
both depths are divided by len ? Isn't it returned with correct value ? Or is
it done to return to scene space from object space ? The same note is
connected with isosurface object.

7. Minor issues:

  Lines 178-179:
     VLength(len, New_Ray.Direction);
     VInverseScaleEq(New_Ray.Direction, len);
  can be replaced with:
     VNormalizeEq(New_Ray.Direction);
  unless note 6. is wrong.

  Lines 214-219:
    P[X] = Ray->Initial[X];
    P[Y] = Ray->Initial[Y];
    P[Z] = Ray->Initial[Z];
    D[X] = Ray->Direction[X];
    D[Y] = Ray->Direction[Y];
    D[Z] = Ray->Direction[Z];
  can be replaced with:
    Assign_Vector( P , Ray->Initial )
    Assign_Vector( D , Ray->Direction )

  Lines 453-454:
    VScale(IPoint, Ray->Direction, TResult);
    VAddEq(IPoint, Ray->Initial);
  can be replaced with:
    VAddScaled(IPoint, Ray->Initial, TResult, Ray->Direction)

I hope my notes were readable and not missed anything. Any comments ?

ABX

Post a reply to this message

ABX,
If it is of any help, I ran a quick profiling job against the pov input file
below, which came off Mike Wiliam's tutorial page.  The big hitters are:

29.3%  ==> POVFPU_RunDefault
21.9%  ==> A profiling counter function (ignore this)
12.1%  ==> Evaluate_Function_UV
11.7%  ==> POVFPU_SetLocal
8.1%    ==> All_Parametric_Intersections
4.9%    ==> library sin function
4.6%    ==> library cos function

After this most everything is noise at <1%.

Here is the pov input file I ran.

//  Run with the command:
//       povray +V -D -P -X +A0.2 +Am2 +R2 +W240 +H180
//=======================================================
#declare R=2;

camera { location  <1*R, 1*R, -4*R> look_at <0, 0, 0> angle 30}

sky_sphere { pigment {
    function{abs(y)}
    color_map { [0.0 color blue 0.6] [1.0 color rgb 1] }
  }
}

light_source {<100,200,-100> colour rgb 1}
light_source {<-100,-200,-100> colour rgb 0.5}

// ----------------------------------------


parametric {
  function {sin(u)}
  function {cos(u)}
  function {v}
      <0,-2>,<2*pi,2>
  contained_by{ box {<-2,-2,-2>,<2,2,2>}}
  precompute 18, x,y,z
  pigment {rgb 0.9}
  finish {phong 0.5 phong_size 10}
  no_shadow
}

Post a reply to this message

On Thu, 29 Aug 2002 16:57:45 -0400, "William F. Pokorny"
<pok### [at] attglobalnet> wrote:
> 29.3%  ==> POVFPU_RunDefault
> 12.1%  ==> Evaluate_Function_UV
> 11.7%  ==> POVFPU_SetLocal

Something to think about. Thanks.

ABX

Post a reply to this message

"ABX" <abx### [at] abxartpl> schrieb im Newsbeitrag
news:he4umukt09felolvnem4jui7g6r2bu09nq@4ax.com...
> On Thu, 29 Aug 2002 16:57:45 -0400, "William F. Pokorny"
> <pok### [at] attglobalnet> wrote:
> > 29.3%  ==> POVFPU_RunDefault
> > 12.1%  ==> Evaluate_Function_UV
> > 11.7%  ==> POVFPU_SetLocal
>
> Something to think about. Thanks.

But not much to do about ... the ratio will actually change depending on the
functions used.  The more complex the more POVFPU_RunDefault will consume,
while the other two will sooner or later be irrelevant.  One should really
not measure these with trivial functions which only contains something
simple like sin or cos, but more complex functions using some operations...

    Thorsten

Post a reply to this message

Thorsten,
You are correct as usual. I ran Mr Suszuki's carpet and tori example and we get:

55.3%  ==> POVFPU_RunDefault
7.7%    ==> drem.c library function
6.0%    ==> Noise
2.8%    ==> __itrunc
2.0%    ==> f_noise3d
1.7%    ==> sqrt
1.6%    ==> IsoSurface_Function_Find_Root_R
1.5%    ==> POVFPU_SetLocal

Then a pile of functions out of the math library running around 0.5 to 1.2%.

I have looked over the POVFPU_RunDefault code and I find it both impressive and
intimidating. I just don't understand it well enough to help. I do wonder how
well the compilers are optimizing that huge case statement.  10 years ago case
statements of that size were trouble for a compiler and breaking them up with
conditionals was recommended. But, I do not know if this holds for the compilers
of today or even if it would be possible to break this case statement up....
Bill P.


> "ABX" <abx### [at] abxartpl> schrieb im Newsbeitrag
> news:he4umukt09felolvnem4jui7g6r2bu09nq@4ax.com...
> > On Thu, 29 Aug 2002 16:57:45 -0400, "William F. Pokorny"
> > <pok### [at] attglobalnet> wrote:
> > > 29.3%  ==> POVFPU_RunDefault
> > > 12.1%  ==> Evaluate_Function_UV
> > > 11.7%  ==> POVFPU_SetLocal
> >
> > Something to think about. Thanks.
>
> But not much to do about ... the ratio will actually change depending on the
> functions used.  The more complex the more POVFPU_RunDefault will consume,
> while the other two will sooner or later be irrelevant.  One should really
> not measure these with trivial functions which only contains something
> simple like sin or cos, but more complex functions using some operations...
>
>     Thorsten

Post a reply to this message

In article <3D6F7E14.AF371036@attglobal.net> , "William F. Pokorny" 
<pok### [at] attglobalnet> wrote:

> I have looked over the POVFPU_RunDefault code and I find it both impressive
> and intimidating. I just don't understand it well enough to help. I do wonder
> how well the compilers are optimizing that huge case statement.  10 years ago
> case statements of that size were trouble for a compiler and breaking them up
> with conditionals was recommended. But, I do not know if this holds for the
> compilers of today or even if it would be possible to break this case
> statement up....

Well, modern compilers will do a good job if they don't crash optimising it
:-)

No, seriously, by design this thing is a dense switch statement which every
compiler (even really bad ones) will manage to use a branch table.  BTW, the
macros are not to intimidate people but but make the implementation easier
because there generate a real lot of code.

In any case, after lots of analysis I had to conclude that on x86 compilers
do not do a good enough job distributing the eight VM registers into the
eight stack slots, so if anybody would want to tweak it such that it uses
SSE2 registers (would limit its use, I know), at least people witha P4 would
gain a bit.

But i would recommend to not spend too much time with this code.  It is my
first VM and the "next" one for a future POV-Ray is already in development.
It will in particular deal with vectors, ints and strings, plus include all
lectures learned from implementing this VM.

    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

On Fri, 30 Aug 2002 20:01:31 +0200, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> It will in particular deal with vectors, ints and strings, plus include all
> lectures learned from implementing this VM.

Great.

ABX

Post a reply to this message

In article <3D6E8AC9.ABD52296@attglobal.net> , "William F. Pokorny" 
<pok### [at] attglobalnet> wrote:

> If it is of any help, I ran a quick profiling job against the pov input file
> below, which came off Mike Wiliam's tutorial page.  The big hitters are:

BTW, as you have profiling enabled on the official source code, could you do
a quick test with optics.pov and benchmark.pov at 160*120 no AA and post the
results?

    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