Thanks for your answer. I think I understand more how this class works now.
In theory, even
vtkTableorvtkGraphcould becomevtkCellGridinstances with different subclasses ofvtkCellMetadatarepresenting rows/columns or nodes/arcs, respectively.
I rapidly read through your MR. Correct me if I’m wrong, but it seems that vtkCellGrid is a collection of cell types that you group by cell types. Each cell grid query type is linked to a responder that performs whatever you want done on each visited cells.
I’m trying to understand how this class could take over all of vtkDataSet inheritance tree.
If you want to have, say a vtkImageData, done with this representation, you’ll need to give it a different voxel cell type than on a vtkUnstructuredGrid represented as a vtkCellGrid, because we want to take advantage of the implicit structure of an image and do not need to carry a conn array for the connectivity.
Do you see us specializing instances of vtkCellGrid in such a way that you have a vtkImageData-like or a vtkUnstructuredGrid-like? I feel like it would conflict with vtkCellGrid::AddCellMetadata API for vtkImageData because we’re restricting ourselves to uniform grids in this instance. If we do not create specialized instances of such dataset types, how do you deal with filter selection in ParaView on filters that do not work on a certain dataset type? As an example, we can think of a convolution filter which is well defined on images, but maybe more complicated to generalize to wilder topologies.
Or do we assume more that you can put any cell types in a vtkCellGrid, uniform grids of voxels, triangles, hexahedrons, and that each cell being linked to a responder, we just try to respond to a query, and if no responder exists, we skip, and thus we never gray out filters in ParaView?