[vtkusers] Performance issues with large set of actors

[Tarjei Knapstad]

On Mon, 2003-03-31 at 18:56, KenLists wrote:
> > 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.

It does indeed.

 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.

Yes, a solution like that sounds like it should make performance depend
almost exclusively on the graphics hardware.

> 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.
> 

I'm off to a conference tomorrow and won't be back till next monday, so
I won't have time to investigate this further until then, but thanks a
lot for the pointers. I will have a look at this approach when I get
back. It's not immediately clear to me, but that's just because I'm not
yet very confident with the renderring pipeline and internals of VTK (as
should be blatantly obvious by now :) )

Cheers,
--
Tarjei