That can be done as the last step (and it’ll need to be added to VTK). I probably is totally fine to continue development on the mapper simply using an external build of the Katana
. That’s probably better since it will help us identify issues with the library sooner – in case, it turns out not suitable for our use.
Hi all, any progress on vtkDataAssemblyPolyDataMapper
and CSS? It is becoming a priority for aeva/cmb/smtk.
No, we don’t have it on our active task list right now since we have higher priority tasks.
2 years later… this is back on our priority with some changes. I’ll write that up separately. All the points discussed here are useful and will potentially make it into the new mapper.
The customer wants to map different scalar arrays per partition in the partitioned dataset. This is definitely possible because all partitions in a partitioned dataset are expected to have the same field arrays. It’s only a matter of selecting the ‘active’ scalar array when mapper builds the VAO or texture buffers. Citing DataAssembly doc:
All non-null partitions have similar field and attribute arrays. For example, if a
vtkPartitionedDataSet
comprises ofvtkDataSet
subclasses, all will have exactly the same number of point data/cell data arrays, with same names, same number of components, and same data types.
Before addressing that, I want to bring to light that there is confusion in VTK for mappers related to the composite dataset, there are two of them!
vtkCompositePolyDataMapper
: is a part ofRenderingCore
, it is meant to rendervtkCompositeDataset
instances using a single actor. Internally, it creates a uniquevtkPolyDataMapper
for each dataset and invokesmapper->Render(ren, act)
. The datasets are uploaded one by one. This mapper does NOT usevtkCompositeDataDisplayAttributes
. This mapper relies onSetScalarArray
and uses that array to map colors for all blocks without any hesitation.vtkCompositePolyDataMapper2
: is a part ofRenderingOpenGL2
. It has a LOT of code. This mapper can set per-block visual properties. It also uploads all datasets in one shot instead of using one mapper per block. This is currently used by ParaView. This mapper relies onSetScalarArray
and uses it for all blocks without any hesitation.
I want to ask if the vtkCompositePolyDataMapper
sees any use at all. Or is that technical debt? We can refactor these two mappers so that there is just one vtkCompositePolyDataMapper
that supports per-dataset display attributes, color mapping with different scalar arrays, and uploads all datasets in one go. The concrete vtkCompositePolyDataMapper
in RenderingOpenGL
will simply implement the actual upload and render functionality.
The vtkPartitionedDataSetCollectionMapper
(renamed from vtkDataAssemblyPolyDataMapper
) could sit in RenderingCore
, reusing vtkCompositePolyDataMapper
internally along with CSS styled selectors for display attributes.
FYI, @cory.quammen
AFAIK, vtkCompositePolyDataMapper
can be thought of as technical debt. I can’t think of any use-cases where one can’t replace it with vtkCompositePolyDataMapper2
instead.
CPDM2 will be deprecated because it’s perf and functionality is now available from CPDM. Related post on VTK discourse - Deprecating vtkCompositePolyDataMapper2 in favor of vtkCompositePolyDataMapper - Development - VTK