[vtkusers] Large number of actors

[Nicolas Rannou]

Hi Clint,

Thanks for the clarification about vtkMultiBlockDataset.

We need multiple actors so we will have to find another solution....

"Caching" might be an option.
If we are at the time point N, we would keep in memory the actors from time point N-1, N and N+1 and update the 3 vectors(?) when we move through the time.

Has VTK such capabilities or would somebody have any recommendation about the best practice to adopt?

Thanks

Nicolas

On Jun 9, 2011, at 1:29 PM, Clinton Stimpson wrote:

> On Wednesday, June 08, 2011 03:48:38 pm Nicolas Rannou wrote:
>> Hi Clinton,
>> 
>> I've been reading about the vtkMultiBlockDataset but I am not quite sure
>> about how it could improve the performance.
> 
> Its an alternative similar to
> vtkPolyData->vtkStripper->vtkAppend->vtkMapper->vtkActor
> 
> vtkPolyData->
> vtkPolyData->  vtkMultiBlockDataSet -> vtkCompositePolyDataMapper2 -> vtkActor
> vtkPolyData->
> ...
> 
> The difference is you don't do a vtkAppend which duplicates the data and 
> increases your memory usage.
> 
>> 
>> From my understanding, it would store/order the polydatas in a tree
>> structure. But the main issue are the actors and mappers... (not the
>> polydata itself...) After storing my polydatas within
>> vtkMultiBlockDataset, I still have to generate N actors from my N
>> polydatas which belong to my block of interest...
>> 
>> I tried to create 1 block per polydata.
>> 
>> 1-add polydatas in the multi block dataset using
>> vtkMultiBlockDataset::AddBlock()
>> 2-extract/append polydatas
>> vtkCompositeDataGeometryFilter or vtkMultiBlockDataset ::GetBlock()
>> 3-map it and visualize it through 1 actor and one mapper.
>> 
>> vtkCompositeDataGeometryFilter generates 1 polydata from all polydatas,
>> which makes picking impossible... vtkMultiBlockDataset ::GetBlock() will
>> return 1 polydata, which will not improve the performance since we have to
>> create 1 mapper and 1 actor for each polydata present in this block.
>> 
>> Is there a better practice to render all polydatas which belong to a block
>> through multiple actors. Am I missing something?
> 
> If you're going to use multiple actors, then don't use a vtkMultiBlockDataSet.
> 
> If you really want multiple actors, you could look at vtkMapper::SetStatic to 
> speed up the multiple actors/mappers.
> But then you'll have to do extra work if pipeline changes need to be accounted 
> for.
> 
> Clint
> 
>> 
>> Thanks
>> 
>> On Jun 8, 2011, at 3:11 PM, Clinton Stimpson wrote:
>>> On Wednesday, June 08, 2011 01:00:48 pm Nicolas Rannou wrote:
>>>> Hi all,
>>>> 
>>>> Our application requires to render up to 5000x1000 PolyDatas.
>>>> Each polydata is made of 500 triangles.
>>>> 
>>>> It looks like it is impossible to store all the related actors in memory
>>>> (on a machine with 48Gb RAM).
>>>> 
>>>> We have been playing around with things such as "vtkStripper",
>>>> "ImmediateRendering", "ReleaseDataFlag", "BackFaceCulling", etc.
>>>> 
>>>> For 1000 PolyDatas:
>>>> 
>>>> The best option in term of memory looks like turning
>>>> "ImmediateRendering" ON. -> 1000 actors
>>>> 
>>>> 	-> 60 Mb of memory usage
>>>> 	-> slow interaction
>>>> 
>>>> The best option in term of interaction seems to be using the following
>>>> pipeline: vtkPolyData->vtkStripper->vtkAppend->vtkMapper->vtkActor
>>>> 
>>>> 	->1 actor
>>>> 	-> 90mo in memory
>>>> 	-> good interaction
>>>> 
>>>> Using only one actor is not an option for us since we want to be able to
>>>> pick and change properties of each object (individually).
>>>> 
>>>> Would somebody have any advise?
>>> 
>>> In this situation, I think you can get both interaction speed and memory
>>> savings by putting your many vtkPolyData objects into a
>>> vtkMultiBlockDataSet and rendering that with an actor or a few actors.
>>> 
>>> You could put some properties, such as colors, in the vtkPolyData instead
>>> of the vtkActor.  And for other properties, you could use the same
>>> actor/mapper for those objects that share the properties.  Or perhaps
>>> use vtkPainter to customize rendering of these objects.
> 
> -- 
> Clinton Stimpson
> Elemental Technologies, Inc
> Computational Simulation Software, LLC
> www.csimsoft.com