[3.0] (not so) IMPORTANT : vtk performance drop ? : solved (clipping range)

Sebastien Barre barre at sic.sp2mi.univ-poitiers.fr
Thu Nov 4 18:44:04 EST 1999

Here are the conclusions regarding my two previous emails :)

[nightly] IMPORTANT : vtk huge rendering performance drop ?
[nightly] IMPORTANT 2 : vtk huge rendering performance drop ? 

The problem was : Christopher Volpe and I noticed huge performance drop between
VTK 2.4 official and VTK 3.0  (current nightly releases) using the VTK Sphere
Bench (http://www.hds.utc.fr/~barre/vtk/sphere-bench.html). 

After performing some checks, it seems to me that the whole stuff is related to
the way clipping planes are computed... And of course, my inability to detect
this change efficiently in my script :) 

I do apologize, there was NO "huge performance drop", there was "just" a
(undocumented ?) change in the way VTK computes default clipping planes, and
this won't hit your application, unless you are doing some very specific stuff
like a benchmark which relies on static default values :) 

I do not know (or remember) exactly why the clipping range method was changed,
I'm sure it's for the best, but this was a bit tricky to spot :)

Here are the facts :

When I wrote the script some time ago, I added some lines to check the defaults
values of the default active Camera of a vtkRenderer :

    set my_defaults {
        $active_camera { 
            GetClippingRange {0.348564 17.4282}
            GetDistance 3.48564
            GetFocalPoint {0 0 0}
            GetParallelProjection 0
            GetViewAngle 30

These were the values that were intended, and a warning would be emitted
otherwise. From time to time, Robert Riviere (who maintains the results
database) and I received some bench results were the clipping range values were
not exactly the same, but we paid not much attention as they were very close to
our default values (I will introduce a +- x% tolerance in the next release of
the bench 2.1)

BUT, this changed dramatically somewhere during the 2.4-3.0 nightly release.
According to Christopher Volpe, "the change (if I recall correctly) was to
compute the clipping planes by computing all the actors' bounding boxes and to
project the vertices onto the VPN, keep track of the max and min distances, and
then use those values as the near and far clipping planes. This prevents
wasting z-buffer resolution on empty space."

Here are the new values of the active Camera in our situation, according to my
bench :

System :
  - VTK 3.0.0 (rev: 1.322, 1999/11/02 01:06:27)

Defaults :
WARNING : $active_camera GetClippingRange was 2.44347 4.52015 , should be
0.348564 17.4282

Apparently, the way the default clipping range (in our simple sphere context)
is computed is different, although the picture looks exactly the same (and this
is also where my mistake also relies, I trust my eyes too much :)

Sadly, this has a disastrous effect on the results :

System :
  - VTK 3.0.0 (rev: 1.322, 1999/11/02 01:06:27)

Best results, summary :
   1) 256x256 : 2408.3 kpolys/s : [stripper]
   2) 256x256 : 1912.5 kpolys/s : [small_sphere]
   3) 256x256 : 1283.4 kpolys/s : []
   4) 256x256 : 1279.2 kpolys/s : [transparency]
   5) 256x256 : 1262.6 kpolys/s : [texture]
   6) 256x256 : 1250.5 kpolys/s : [texture, transparency]
   7) 256x256 :  689.3 kpolys/s : [wireframe]

Compared to the 2.4 offical release :

System :
- VTK 2.4.0 (rev: 1.211, 1999/06/30 17:48:40) 

Best results, summary :
   1) 256x256 : 3197.9 kpolys/s : [stripper]
   2) 256x256 : 1950.7 kpolys/s : [small_sphere]
   3) 256x256 : 1950.7 kpolys/s : []
   4) 256x256 : 1950.7 kpolys/s : [transparency]
   5) 256x256 : 1393.4 kpolys/s : [texture, transparency]
   6) 256x256 : 1388.4 kpolys/s : [texture]
   7) 256x256 :  886.7 kpolys/s : [wireframe]

Huge drop (30%).

Please note that it *depends* on your hardware ! Clipping range seems to have a
more or less impact depending on the way your Z-buffer is handled. I noticed NO
performance drop using my 3dlabs GMX 2000 at home, and a strong effect on my
Visual SGI 320 (as seen above).

I will update the script very soon, and it will correct the values
automatically so that they might respect the compatibility with our database
(VTK 2.0, 2.1, 2.2, 2.3, until offical 2.4). I guess Robert and I may have to
ask these who sent us results using later release to do their tests again :(

Sorry again for the buzz/noise.

This is the private VTK discussion list.  Please keep messages on-topic.
Check the FAQ at: <http://www.automatrix.com/cgi-bin/vtkfaq>
To UNSUBSCRIBE, send message body containing "unsubscribe vtkusers" to
<majordomo at gsao.med.ge.com>.  For help, send message body containing
"info vtkusers" to the same address.     Live long and prosper.

More information about the vtkusers mailing list