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

[Miller, James V (CRD)]

Here is a possible interpretation (or perhaps just a clarification of Lisa's hypothesis :)

A Z-buffer operation is essentially an "if-check" followed by a write.  When the clipping planes are
far apart, all of sphere geometry mapped to a few bins in Z.  As a consequence, the "if-check" failed
frequently and the write operation was avoided.  When the clipping planes were brought in tighter,
the sphere spans more of the Z-buffer, the "if-check" fails less frequently, causing more write
operations into the Z-buffer, slowing down performance.

Intuitively, I am happy with this explanation.  That is until I think about the fact that we are
rendering a single sphere in the benchmark. When rendering a sphere, I would expect only two
"if-checks" per pixel over the vast majority of the sphere with the potential of more Z-buffer
operations near the boundary of the sphere. I wouldn't expect this degradation in performance.
However, I think the sphere benchmark uses a very high resolution sphere, perhaps with more triangles
than pixels.  In this case, multiple triangles map to the same pixel, requiring more than two
"if-checks" per pixel across the sphere.



> -----Original Message-----
> From: Lisa S. Avila [mailto:lisa.avila at kitware.com]
> Sent: Thursday, November 04, 1999 11:33 PM
> To: Sebastien Barre; vtkusers at gsao.med.ge.com
> Cc: Volpe, Christopher R (CRD); Robert Riviere
> Subject: Re: [3.0] (not so) IMPORTANT : vtk performance drop 
> ? : solved
> (clipping range)
> 
> 
> 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.
> --------------------------------------------------------------
> ---------------
>