Adding Properties for vtkPartitionedDataSetCollection

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.

1 Like

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.

1 Like

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 of vtkDataSet 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!

  1. vtkCompositePolyDataMapper: is a part of RenderingCore, it is meant to render vtkCompositeDataset instances using a single actor. Internally, it creates a unique vtkPolyDataMapper for each dataset and invokes mapper->Render(ren, act). The datasets are uploaded one by one. This mapper does NOT use vtkCompositeDataDisplayAttributes. This mapper relies on SetScalarArray and uses that array to map colors for all blocks without any hesitation.
  2. vtkCompositePolyDataMapper2: is a part of RenderingOpenGL2. 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 on SetScalarArray 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.

2 Likes

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

1 Like