Rendering multiple solids with only one Actor, yet retaining RGBA and Picking

Hi dear friends,

I’ve post an issue where I was facing bad overall framerate with a scene containing 500+ actors.

Thanks to many useful answers, I’ve changed my code to create each solid as a vtkPolydata, then merging them thanks to vtkAppendPolyData, and finally display them with a unique Actor.

Overral performance gain is spectacular, but obviously I’m losing several thing :

  • Per solid RGBA color.
  • Per solid picking.

The picking problem is quite simple to solve by using a vtkCellPicker associated with a lookup table between vtkPolydata’s cells and original solids.

The RGBA problem should have been easy to solve too, but I’m facing an issue :
To assign a different color to each of the vtkPolydata’s cells, I’m using

double argb[4] = { R, G, B, A }; //where R...A are in [0..255]
vtkNew<vtkUnsignedCharArray> vtkcolors;
for (int i=0; i<poly->GetNumberOfCells(); i++) vtkcolors->InsertTuple(i, argb);

In my scene I have opaque solids and transparent ones.
Displayed colors are OK, except that the whole Actor becomes transparent as soon as there is at least one transparent solid in the batch.
I would have expected cell’s transparency being OK according to scalar map …

My question :

  • Is it a normal behavior (i.e. an Actor is totally transparent or not)
  • Will have I to separate my solids into as many actors as I have Alpha value ?

Thanks !

Ok, my bad.
By using a vtkMultiBlockDataSet + vtkCompositePolyDataMapper, transparency issue has gone.

Hi Olivier,

could you explain a bit more how you used vtkMultiBlockDataSet and vtkCompositePolyDataMapper to solve your transparency issue? Did you have to use a separate block for transparent / non-transparent parts?


Hi Ugis,

Sorry for late answer …
Using vtkMultiBlockDataSet is a dead end, because it is a performance trap.

I think I have tested almost all ways to have the same behavior/capabilities as for 1 actor per object, but with good performances with thousands of objects.

My conclusion is that you have to split your objects into several batches, according to a specific criterion (eg. Opacity) and then assign each batch to a specific Actor (after having merged them by any means).
You will end up with not so many actors, maybe 1-10, holding each many objects.
Performances will be pretty good, and you will keep having the possibility to customize the display as if you had 1 actor per object (almost).

I see, interesting. Then indeed I should not try to merge differently transparent objects into same actor.

Thanks a lot for sharing your experience! This will certainly save me time trying to improve performance at our side.


If your only concern is opacity, you can theoretically achieve a good display with only one actor, and mixing opacities.
For that you’ll have to :

  • Use RGBA colors assigned to point data (not cell), or use a custom lookup table
  • Set the actor as SetForceTranslucent

Cool, I will try that! Thanks.