[vtkusers] Performance issues with large set of actors

[KenLists]

> I've also got a molecular editor though, and there I need one actor
for
> each atom/bond to be able to do picking and iteract properly with the
> underlying molecular structure (a graph inherited from the Boost Graph
> Library). I've currently solved this by inheriting from vtkActor (will
> be changed to LODActor now) like this:
> 
>                               vtkBondActor
>                              /
> vtkActor <- vtkChemistryActor
>                              \
>                               vtkAtomActor
> 
> The Bond and Atom actor both keep a reference to the associated
> atom/bond in the underlying graph, and the Atom actor also keeps
> pointers to the connected Bond actors so that those can keep up when
> an Atom actor is moved. Maybe this is not the best solution, but as
far
> as I can see I need to create separate actors to be able to interact
> through picking?

Using a Cell or PointPicker will allow you to have one actor and yet
still know what atoms/bonds are being selected and manipulated. While
this helps I still think that for molecular vis you need a different
class. Specifically using Glyph3D results in polygons being created for
each atom and bond. That results in a lot of wasted polygons. A better
approach would be to have polygons for a sphere and polygons for a tube.
Then the rendering process would simply adjust the position, scale, and
color of the spheres and tubes as they are drawn. This would have a
small memory foot print and faster to render for extremely large models.
I see this class as the following


vtkProp3D <- vtkChemistryActor
   - Input (vtkPolyData with some conventions)
   - a sphere connected to a vtkMapper internally to draw the atoms
   - a tube connected to a vtkMapper internally to draw the tubes
   - Render method that sets the properties and calls Render on the 
     above listed mappers for each atom & tube, depending on how well
     works a custom mapper might need to be written instead, but it 
     would be a pretty simple mapper.
   - some custom code for picking


This would take a few days to create but I think it would really meet
the needs of the chem Folks more than the current approaches.

Thanks
Ken