[vtk-developers] Rendering efficiency for large nested vtkAssembly's

[Bill McGrory]

I understand the inherent inefficiencies in using large nested
vtkAssembly's but I need to try and use them none-the-less.

I am trying manipulate a system with vtkAssembly's nested approximately
6 levels deep, with the bottom level containing on the order of 100's of
vtkProp3D's. (A total of less than 1000 prop's altogether.

Interactive rendering is next to impossibly slow.

I have tried to do some profiling, and what I have determined is that at
least part of the slow-down is because of what I believe are unnecessary
calls to UpdatePaths/BuildPaths, and the associated recursive calls to
GetMTime

If I construct a scene with a single top level vtkAssembly added to a
renderer, each time Render() is called,  UpdatePaths is called 4 times
(from RenderOpaqueGeometry, HasTranslucentPolygonalGeometry
RenderVolumetricGeometry and GetBounds) and the MTime's of various
components of the path are changed on subsequent calls so that the
buildpath is reconstructed each of the 4 times that UpdatePaths is
called.  All I am doing is using an interactor to move the camera, so I
don't feel like the build paths should be reconstructed in between these
calls. I may not understand what's changing in buildpaths, but it seems
to me that buildpaths shouldn't be called at all, once it is properly
constructed.
(assuming of course that visibility or transformation information
doesn't change.

Am I missing something here? isn't there room for optimization in these
routines?

Should it be safe to skip some of the calls to UpdatePaths from within
calls off of vtkRenderer::UpdateGeometry? 
since RenderOpaqueGeometry is called on each prop in the renderer,
shouldn't you be able to skip the UpdatePaths in calls to
HasTranslucentPolygonalGeometry and RenderVolumetricGeometry?

I also think that making a special GetMTimePath for an assembly, might
yield optimization as well, if you don't require a rebuild of the path
for changes that don't effect the path itself?

Regards
Bill


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20070327/9ec7332e/attachment.sig>