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

Lisa S. Avila lisa.avila at kitware.com
Thu Nov 4 23:32:35 EST 1999


I made the change to the clipping range some time shortly after the 2.4
release went out. I thought I sent a note out to the list, but maybe I
forgot. 

There were two reasons for the change - first, the previous way that the
clipping range was initially computed was very conservative (wasted a lot
of the range of the z buffer). Also, the way that the clipping range was
updated during interaction (rotate, pan, zoom, etc.) did not prevent
objects from being clipped - so if you zoomed in a bit you would clip your
object. I added a method to recompute the clipping range based on the
bounding box of all props, and this is called from the interactor to keep
the objects from being clipped. If you modify the camera directly, the
clipping range will not be recomputed (allowing the user to cause clipping
if desired). 

It is disturbing that tightening the clipping range can have such a
negative impact on performance. I suspect that some parts of the rendering
pipeline are being avoided (some pixels aren't being drawn) due to the
decreased resolution causing two points to have the same Z value (whereas
they would have different Z values with more resolution in the Z buffer).
Maybe. 

Lisa


At 12:44 AM 11/5/99 +0100, Sebastien Barre wrote:
>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.
>-----------------------------------------------------------------------------
> 



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