As discussed in this topic, 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.
// 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.
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.
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.
This approach of assigning properties directly on the vtkDataAssembly is better than assigning those on to the mapper (as was done previously with CompositePolyDataMapper[2]). This will avoid the need for client applications to maintain any separate datastructures to preserve them if the assembly changes.
We need to provide convenience API on vtkDataAssembly (or some utility class) to set properties using path expressions.
We probably need more VTK-esque way of storing properties. One option is to use the vtkInformation and vtkInformationKey... mechanism. This makes it possible for client-code to define arbitrary new properties and storing them in a type-safe way. The questions with this approacg: is can that be made efficient performance and memory-usage wise, and can that be serialized/serialized easily.
Storing visual style on the vtkDataAssembly means it will be the same across multiple views. At least some of our customers do not want that.
We have another application (aeva) for which customers want not only control over opacity and block color, but also the representation style (surface, surface-with-edges, wireframe, etc.). We are also looking at migrating to vtkPartitionedDataSetCollection and vtkDataAssembly.
Have you considered something more like CSS that separates the style from the data?
Just have vtkDataObject and vtkDataSetAttributes (or vtkFieldData?) hold a set of classes. The representation for a view would hold style strings that determine visual style based on the set classes, just the way CSS rulesets map groups of HTML elements to property values in declaration blocks.
The equivalent of HTML elements in CSS selectors would be VTK class names. So some markup might look like
/* Declare some default style for vtkPolyData: */
polydata { line-thickness: 1px; opacity: 0.5; }
/* ... and override polydata with "selected" in its list of classes: */
polydata.selected { line-thickness: 2px; opacity: 1.0; }
/* Allow point-data markups to specify scalar array coloring: */
polydata pointdata { map-scalars: true, colormap: cool-to-warm; }
/* Allow representations to be chosen by selector */
image: { representation: outline; }
image.active { representation: surface; }
The vtkDataAssembly path queries are intentionally XPath-like, but there are mappingsbetween XPath and CSS selectors.
You can also imagine some pseudo-classes would be useful for things like changing appearance upon mouse hovering:
Whenever a representation’s CSS style string changes, the representation would parse it to discover the set of unique combinations of visual styles possible.
Whenever the input data changes, the representation would traverse the vtkDataAssembly, evaluate what style applies to each leaf node, and develop a rendering plan that decomposes rendering into a sequence (or sequences if rendering in parallel) of simple operations.
Let me start by saying, I really like this approach!
Doing it all the way as you’re suggesting with pseudo-classes etc is very cool, but will probably be too much to chew right off the bat.
Does anyone have any experience with CSS + C++? I’ve been googling for css parser libraries etc. Don’t think I can spot what the canonical way in my quick searches.
Here’s a revised proposal, which includes some changes to vtkDataAssembly itself. Just to clarify, primarily talking about VTK-level here. So no notion of representations + active state etc.
Make vtkDataAssembly a standard DOM. This will add some rules to the supported types of node-names e.g. they cannot contain spaces and will need to be a valid XML element name. This is slightly different than how it’s currently implemented. That was done to support node names with spaces. In hindsight, that’s unnecessary and if needed, we can use the now supported “attributes” to add “label” which can include spaces etc.
Add support for attributes to the nodes in the assembly. Nothing special here, standard with DOMs. Allows for things like “label”, or “class” in future. Exodus Assemblies also support attributes per assembly node and this provides a mechanism to add those to vtkDataAssembly.
Create a new mapper, say vtkDataAssemblyPolyDataMapper, which subclasses vtkMapper. It’ll support the standard API to get/set root-level properties for appearance. These values together with the values setup on the vtkProperty and vtkActor define the visual properties that get used with the mapper starts rendering.
vtkDataAssemblyPolyDataMapper takes a CSS string that can be used to override the visual properties. The implementation will scan through the assembly, determining computed visual properties combing the defaults with the overrides in the CSS and then render accordingly.
CSS selectors can support attributes specified on the DataAssembly, besides the node names.
The set of properties supported by the CSS can grow overtime, we start with a simple set.
In ParaView GUI, when we use the Multiblock Inspector to setup properties, we’ll be generating a CSS.
This concept can then be extended to other mappers, e.g. vtkDataAssemblyGlyphMapper. vtkDataAssemblyMoleculeMapper etc.
I like it, especially if we can eventually have something like a vtkDispatchingMapper that chooses an underlying mapping approach based on CSS-like markup (e.g., vtkPolyData marked as glyphs, so use the glyph mapper).
sigh! searching the universe for a reasonable CSS parsing library has been quite futile. I don’t want to write my own parser using PEGTL or whatever, but seems like the only path forward :/…disappointing.
@utkarsh.ayachit Any idea on when vtkDataAssemblyPolyDataMapper will come to life? And will your first pass include transforms for partitions inside the collection? We are starting to move SMTK to use vtkPartitionedDataSetCollection and that is one of the features we like about the proposed mapper!
@vbolea is working on it…I’ll defer to him on the timeline. Priority-wise, it no longer is a requirement to get done for 5.10 since I think we can support a temporary workaround in ParaView. PartitionedDataSetCOllection support can still be implemented with a small hack to the old multiblock mapper hence the change in priorities. But if there’s scope for joining efforts, let’s talk!
I know I am late to the discussion but I wish to add some ideas.
I really like these ideas of using CSS to query the DOM, this gives us a lot of flexibility without reinventing the wheel.
With regards to libcss, a deeper research shows that it has strong dependencies of other components of the project NetSurf (LibParserUtils, LibWapcaplel ). This means that for ParaView to add this dependencies we will also need to add another dependencies and its corresponding compatible versioning combinations which will add additional complexity to our building system.
Another CSS parser which seems popular in GitHub is : https://github.com/hackers-painters/katana-parser. It does not have external dependencies and it seems to do the work, unfortunately it has not been active for a few years.
In any case these concern are just a matter of finding the appropiate library
There is some work done in the latest push in which I introduce the vtkDataAssemblyRepresentation where we can set properties using XPath ids, unfortunately I have not given it as much time as I wanted since in the last month there has been a mix of vacations and other urgent tasks.
Before I move forward I would like to take into consideration the selection of the CSS library previously stated.
Agreed, libcss is a non-starter esp with all the dependencies it needs. Katana sounds reasonable enough. Will need to be cmakified and added as TPL, but the code seems compact enough that I doubt it’ll be too difficult. Let go ahead with Katana.
