[vtkusers] Slow Performance with 2K actors (*.obj file)

[Carlos]

If all the actors have the same geometry, then you can use Shallowcopies
(actor.ShallowCopy ) in a way similar to:

 

  // Visualize

  vtkSmartPointer<vtkPolyDataMapper> mapper =

    vtkSmartPointer<vtkPolyDataMapper>::New();

  mapper->SetInputConnection(reader->GetOutputPort());

 

  vtkSmartPointer<vtkActor> actor =

    vtkSmartPointer<vtkActor>::New();

  actor->SetMapper(mapper);

   renderer->AddActor(actor);

 

for (int i=0;i<2000;i++)

{

  vtkSmartPointer<vtkActor> actor2 =

    vtkSmartPointer<vtkActor>::New();

 

  actor2->ShallowCopy(actor);

   renderer->AddActor(actor2);

}

 

 

This will reduce both the time of loading as the polydata and the mapper are
created only once and also it will improve the interaction experience.

There are only some parameters that can be change, like position or
orientation but not the geometry in the new actors. 

 

 

Regards,

 

Carlos

 

De: vtkusers [mailto:vtkusers-bounces at vtk.org] En nombre de Sonya Blade
Enviado el: lunes, 16 de junio de 2014 8:09
Para: David Cole; vtkusers at vtk.org
Asunto: Re: [vtkusers] Slow Performance with 2K actors (*.obj file)

 

Ok thanks David for entry point,

 

Probably construing the scene from many actors was not a good idea if you
look at it from VTK side,

but due to the design architecture I should have each object as a seperate
entity which might have the 

the supplied *.obj shape or any other arbitrary shape provided by end-user
and those shapes should be 

interactable, modifiable, etc 

 

If it wasn't AddActor() proc then what other methods I can use for that ?

 

Regards,



> To: sonyablade2010 at hotmail.com; vtkusers at vtk.org
> Subject: Re: [vtkusers] Slow Performance with 2K actors (*.obj file)
> From: dlrdave at aol.com
> Date: Sun, 15 Jun 2014 08:01:59 -0400
> 
> You should probably only have 10s or 100s of actors in any given 
> renderer. 1000s or more *actor* objects are known to be slow.
> 
> Unless somebody else chimes in and contradicts me, with a speed up 
> hint, it's probably best to restructure your code to use fewer actors.
> 
> 
> HTH,
> David C.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20140616/053caf00/attachment.html>