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;
vtkcolors->SetNumberOfComponents(4);
vtkcolors->SetNumberOfTuples(mesh->GetNumberOfCells());
for (int i=0; i<poly->GetNumberOfCells(); i++) vtkcolors->InsertTuple(i, argb);
poly->GetCellData()->SetScalars(vtkcolors);
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 ?
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?
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).