[vtkusers] Performance problems with large number of actors
Mark Beall
mbeall2 at simmetrix.com
Mon Jul 17 18:05:15 EDT 2000
Hi George,
Yes, we've run into this problem - unfortunately we don't have a
solution at this time. We had posted some information to this
mailing list a month or two ago about what we had found when
we looked into this problem. The summary is that we we're not
able to figure out why this is a problem, but we were able
to (we think) figure out that the problem isn't really the
fact that there are a large number of actors (there is overhead in
vtk when there are a lot of actors, but that's not the major source
of the performance problem), but it has something to do
with how OpenGL is being set up with VTK that is causing a
serious performance degradation when there are a lot of display lists.
I have a feeling that the fix to this is very simple if someone
can just figure out what's going on. I think that someone at
Kitware was going to try to figure it out. I don't know if they've
had a chance to look at it yet.
mark
Reposted from 4/26/00:
Hi Folks,
While working on an application that involve thousands of
actors in VTK, I noticed really poor graphics performance on a SUN
Ultra10 Elite 3D workstation for relatively simple geometry. I then
began investigating what the performance bottleneck was by writing some
very simple test applications. One app was written in VTK and the other
was written in OpenGl. Basically each app displays n cubes (each a 14
point triangle strip) and can change the way the data is structured by
varying the number of actors (or display lists in the case of OpenGl)
used as well as changing the material property of each cube.
One using one actor (or one display list) the results are basically the
same:
#of cubes framerate rendering rate
1000 Framerate = 76 .91 MTri/Sec <- limited by frame buffer
switching
8000 Framerate = 38 3.7 MTri/Sec
15625 Framerate = 25 4.7 MTri/Sec
27000 Framerate = 15 4.9 MTri/Sec
However when I changed the number of actors used (even for 1000 cubes)
the results differed dramatically:
For 1000 cubes - simply varying the number of actors
actors Framerate Rendering Speed
1 Framerate = 76 .91 MTri/Sec <- limited by frame buffer
switching
100 Framerate = 76 .91 MTri/Sec <- limited by frame buffer
switching
125 Framerate = 38 .30 MTri/Sec
250 Framerate = 38 .30 MTri/Sec
500 Framerate = 19 .23 MTri/Sec
1000 Framerate = 9.4 .11 MTri/Sec
In the case of OpenGl there was no difference with varying the number of
display lists (including setting a material property per cube). The
Framerate was still 76/sec
In the case of increasing the number of cubes beyond 1000 (each with a
different material property) using OpenGl:
# of cubes Framerate Rendering Speed
1000 Framerate = 76 0.91 MTri/Sec <- limited by frame
buffer switching
8000 Framerate = 19 1.8 MTri/Sec
15625 Framerate = 9.5 1.8 MTri/Sec
27000 Framerate = 4.8 1.6 MTri/Sec
You can see we are getting at least an order of magnitude penalty.
We also ran both test applications through quantify and saw the following
behavior:
The expected issue:
There is overhead in vtk itself with so many actors seemingly mainly due
to the fact that it has to poll each actor for changes before it
renders each frame. We are working with Kitware to develop solutions
to this problem.
The unexpected issue:
There is something about how vtk and opengl are interacting that
makes the rendering of the display lists that vtk creates for
the vtkActorTest much slower than for the plain OpenGl code that we
wrote.
The actual time spent in glCallList for the vtk-based example vs. the
non-vtk-based example is something like an order of magnitude greater.
We even tried to allocate (and initializing) blocks of memory between the
allocations of display lists in the OpenGl example (to simulate the fact
that with vtk the display lists won't be in contiguous memory blocks).
This didn't have any noticable effect.
If anyone have expertise in OpenGl and would like to take a look at why
the performance differs so drastically please let me know and I can send
you copies of the test programs.
Please let me know what you think.
Bob
Robert M. O'Bara
Senior Software Engineer
Simmetrix Inc.
1223 Peoples Ave.
Troy, NY 12180
>I am experiencing very significant performance degradation when using a
>large number (~1000) of actors composed of unstructured grids. Each of
>these actors represent one part of an assembly; each part is to be
>colored and added to the display individually. When the geometry is
>added as a single actor, the performance is acceptable, though I cannot
>color and select geometry directly. The performance problem results from
>dividing the geometry into a number of separate actors.
>
>Initially the code I developed created each actor with its own mapper,
>then I switched to using a single mapper to alleviate the performance
>degradation problem using an AppendFilter as its input (since the
>mappers acommodate only a single input on their own), but the
>performance only got worse.
>
>Has anyone in vtkuser land run across and (hopefully solved) this
>problem? I have scanned the archives and have found no mention of it
>yet. My (rather dirty) assembly function code follows.
>
>Thanks for your help,
>
>G.B.
>
>
>vtkAssembly *GetAssembly2()
>{
> UGridReader *ugr = UGridReader::New(); //creates my multi-output
>reader
> ugr->Initialize();
> vtkAssembly *assy = vtkAssembly::New();
> srand( 100 );
> float dval = RAND_MAX;
> int outputs = ugr->GetNumberOfOutputs();
> vtkDataSetMapper *ugridMapper = vtkDataSetMapper::New();
> vtkAppendFilter *ugridFilter = vtkAppendFilter::New();
> ugridMapper->SetInput(ugridFilter->GetOutput());
> ugridMapper->ImmediateModeRenderingOn();
> for (int i=0;i<outputs;i++)
> {
> float rvalr = rand()/dval;
> float rvalg = rand()/dval;
> float rvalb = rand()/dval;
>
> vtkUnstructuredGrid* ugrid = ugr->GetOutput(i);
>
> ugridFilter->AddInput(ugr->GetOutput(i));
>
>
> vtkActor *ugridActor = vtkActor::New();
> ugridActor->SetMapper(ugridMapper);
> ugridActor->GetProperty()->SetBackfaceCulling(1);
> ugridActor->GetProperty()->SetColor(0.8,
> rvalg==0.0?1.0:.8+rvalg,
> rvalb==0.0?1.0:.8+rvalb);
> ugridActor->AddPosition(0,0.001,0);
>
> vtkActor *wireActor = vtkActor::New();
> wireActor->SetMapper(ugridMapper);
> wireActor->GetProperty()->SetRepresentationToWireframe();
> wireActor->GetProperty()->SetColor(0,0,0);
>
> assy->AddPart(ugridActor);
> assy->AddPart(wireActor);
>
> //ugrid->Delete();
> //ugridMapper->Delete();
> ugridActor->Delete();
> wireActor->Delete();
> }
> ugridMapper->Delete();
> return (assy);
>}
>
>
>
>_______________________________________________
>This is the private VTK discussion list.
>Please keep messages on-topic. Check the FAQ at:
><http://public.kitware.com/cgi-bin/vtkfaq>
>Follow this link to subscribe/unsubscribe:
>http://public.kitware.com/mailman/listinfo/vtkusers
More information about the vtkusers
mailing list