# Adding Properties for vtkPartitionedDataSetCollection

**URL:** https://discourse.paraview.org/t/adding-properties-for-vtkpartitioneddatasetcollection/6061
**Category:** Development
**Tags:** proposal
**Created:** [December 15, 2020, 1:14am UTC](https://discourse.paraview.org/t/adding-properties-for-vtkpartitioneddatasetcollection/6061 "2020-12-15T01:14:24Z")
**Posts on this page:** 1
**Showing post:** 1

<div class="post-metadata">

### Author: ![vbolea](https://discourse.paraview.org/user_avatar/discourse.paraview.org/vbolea/32/4121_2.png) [@vbolea](https://discourse.paraview.org/u/vbolea)
#### Post date: [December 15, 2020, 1:14am UTC](https://discourse.paraview.org/t/adding-properties-for-vtkpartitioneddatasetcollection/6061/1 "2020-12-15T01:14:24Z")

</div>

As discussed in [this topic](https://discourse.paraview.org/t/deprecating-multiblock-datasets/4950/3), we will finally departure from `multiblock` datasets by introducing the `vtkPartitionedDataSetCollection` and friends.

An important feature needed for those hierarchical datasets are properties, such as `visibility` or `opacity`, which makes uses of the its hierarchy —similar to `vtkCompositeDataDisplayAttributes.h` for multiblock datasets.

To enable this feature we added the missing `vtkPartitionedDataSetCollectionMapper` which takes into consideration those new introduced properties and made several changes to the `vtkDataAssembly` class.

## Example usage

Here is an example of API usage the new proposed feature.

```auto
  // We want to hide the elements under //left/r2 in this example
  vtkNew<vtkDataAssembly> assembly;
  const auto base = assembly->AddNodes({ "left", "right" });
  const auto right = assembly->AddNodes({ "r1", "r2" }, base[1]);

  assembly->AddDataSetIndices(base[0], { 0, 1 });
  assembly->AddDataSetIndices(right[0], { 2 });
  assembly->AddDataSetIndices(right[1], { 3 });

  // Every dataset contained in the //left/r2 subtree would inherit
  // those properties when rendering. 
  assembly->SetProperty(right[1], Visibility, "false");
 
  auto ret = assembly->GetProperty(right[1], Visibility);

  assembly->UnSetProperty(right[1], Visibility);

  for (auto prop : assembly->GetProperties(right[1]))
  {
    std::cout << auto ret = assembly->GetProperty(right[1], prop) << std::endl;
  }

  // Similar methods have been introduced for the class vtkDataAssemblyVisitor.

```

## Discussion

This work came with few design decisions, some of which I wish to bring to debate in this thread.

1. In this work we set properties in the hierarchy using the class `vtkDataAssembly`. This effectively groups all the storing logic into `vtkDataAssembly` at the expense of adding more responsibilities to the class.  
Alternatively, this API could be moved to the new introduced mapper, making thismapper in charge of storing the properties and also taking decisions based on them – such as disabling or changing the opacity of an entire subtree.

2. Following the design decision of implementing the properties features in the `vtkDataAssembly`. We currently store the properties into the vtkDataAssembly XML DOM, using `pugiXML` library. I wonder if there are any scenarios in which this can be an inconvenience or a potential bottleneck.

Please feel free to add any comment or suggestion as this is still work in progress.

## Related links

- MR: [https://gitlab.kitware.com/vtk/vtk/-/merge\_requests/7426/diffs#c9372a45daa2147a5771e6c91641f57a8d0f93ac](https://gitlab.kitware.com/vtk/vtk/-/merge_requests/7426/diffs#c9372a45daa2147a5771e6c91641f57a8d0f93ac)

---

_[View the full topic](https://discourse.paraview.org/t/adding-properties-for-vtkpartitioneddatasetcollection/6061)._