[vtk-developers] Rendering with a large number of actors
Ken Martin
ken.martin at kitware.com
Tue Oct 30 13:41:30 EST 2001
Hello Folk,
I have wrapped up my work on rendering a large number of actors. In
some areas I made some good progress and in other areas I have left
some options open. The problem I was trying to address was VTK's
performance when rendering large numbers of fairly small polygon count
actors. In these cases VTK has a huge overhead in a few areas. I have
made the following changes to VTK
1) The vtkProp3D now has an Identity ivar that can be checked to see
if its matrix is identity. This ivar starts at 1 and most any change
causes it to go to zero. So it is maily useful when the actors are not
being transform (which is commonly the case)
2) vtkOpenGLActor looks at the Identity ivar from (1) to determine if
it needs to push down the actor's matrix (a few opengl calls, a
getmatrix call, a transpose of the matrix)
3) Some collections in vtkRenderer werebeing created and destroyed
evenry render. Two of the collections were removed and the third is
now kept around.
4) All collections now use a static_cast<> instead of SafeDownCast to
retrieve a value. SafeDownCast required a strcmp call while
static_cast<> does not.
5) vtkProp3D had some code where it copied a matrix into itself, this
has been fixed
6) SwapBuffers was also doing a flush when it wasn't required
After making these changes there are still significant performance
issues. These stem from the UpdateInformation call that gets made a
few times per render per actor. Fixing this was a little tricky
because it requires the user indicating that the data is static versus
dynamic etc. I decided not to add this functionality into
vtkOpenGLPolyDataMapper because it would slow down the rendering for
all other cases (extra if checks). I did create a
FastOpenGLPolyDataMapper that assumes the data is static. When it
changes you have to call UpdatePiece. I have attached the class to
this email. It could use some work but it shows how by subclassing,
significant performance changes can be made for some cases.
I tried caching opengl state using some of John Schalf's code as a
starting point. This was interesting because it made almost no impact
on my Win32 system with a NVidia card. My guess is that the NVidia
drivers do state caching already and so my changes had no real impact.
I also tried them on a Sun Creator 3D and there it did make a
difference. I checked the classes into VTK but they are not being used
right now. I didn't use them because my implementation requires that
opengl calls are modified so that glEnable becomes
vtkOpenGLCall_glEnable. Thsi is an easy change to make with emacs but
it must be made to everything or else the OpenGLStateCache can get out
of sync with the actual opengl state causing rendering problems. For
this reason I left it out right now.
I added a test to VTK 4.0 based on the example Bob Obera sent me. It
is VTK/Rendering/Testing/Cxx/TimeRenderer where values of 12 12 1 1728
are good arguments. I'm open to feed back & suggestions etc.
Thanks
Ken
--------------------------
Ken Martin, PhD
Kitware Inc.
518 371-3971 x101
469 Clifton Corporate Pkwy.
Clifton Park, NY 12065
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vtkFastOpenGLPolyDataMapper.cxx
Type: application/octet-stream
Size: 5553 bytes
Desc: not available
URL: <http://www.vtk.org/pipermail/vtk-developers/attachments/20011030/812ba364/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vtkFastOpenGLPolyDataMapper.h
Type: application/octet-stream
Size: 3243 bytes
Desc: not available
URL: <http://www.vtk.org/pipermail/vtk-developers/attachments/20011030/812ba364/attachment-0001.obj>
More information about the vtk-developers
mailing list