Description:
I am working with a PartitionedDataSetCollection that has an assembly with a large number of nodes. I select specific nodes from the tree to load only certain blocks in the hierarchy.
When I change the Block Coloring for the assembly in the Multiblock Inspector, I encounter several inconsistent behaviors:
Loss of Block Coloring when switching between assembly and hierarchy:
If I switch from the assembly view to the hierarchy view, the block coloring disappears, even when switching back to the assembly.
Since the assembly is aware of its block hierarchy, the block coloring should be transferred, right?
The most frustrating part is that the block colors do not reappear when returning to the assembly view.
Block Coloring reset after applying a different selection:
If I apply a different selection to add or remove block hierarchies, the previously set block colors are no longer available.
This means I have to recreate the block colors each time, even though the assembly tree structure remains unchanged.I am unsure if this is intended behavior, but it is causing significant issues in my workflow.
Steps to Reproduce:
Case1:
Create a PartitionedDataSetCollectionSource.Select Number Of Shapes = 9 for example.
Change the Block Coloring for the assembly in the Multiblock Inspector.
Case2:
Create a PartitionedDataSetCollectionSource.Select Number Of Shapes = 9 for example.
Change the Block Coloring for the assembly in the Multiblock Inspector.
That is not a bug, but an expected behavior based on the current implementation
You describe two cases that both have the same root problem.
Some Glossary:
There are two assembly options:
Hierarchy (its label is Hierarchy): It’s created based on the structure of your dataset.
Data Assembly (its label is Assembly): User provided that can be arbitrary
Case 1:
In the same dataset, you change which kind of assembly you use between the Data Assembly and the Hierarchy. There is no mapping to transfer from the Data Assembly to Hierarchy, because there are hard cases to deal with:
The Data Assembly can omit certain blocks.
The hierarchy has paths on partitioned datasets, but the user provided Data Assembly can organizes these partitioned datasets in many different ways (see picture above)
Since there is no direct mapping between the Hierarchy and the Assembly to be able to transfer your block properties from one assembly to another, we reset the properties each time you switch. Also, we only have a BlockColor property, not AssemblyBlockColor and HierarchyBlockColor, therefore when you switch back you can’t have access to what you assigned before.
Case 2: You change your dataset, including your DataAssembly and Hierrachy. Since this happens your block properties have to reset since they no longer apply to the same assembly (either choice).
Suggestions: Stick to one of the two organizations. During the exposure of the Data Assembly we had thought of hiding the Hierarchy if there is a Data Assembly, but we kept it in case someone prefers one or the other, but using both interchanably is not possible based ont he current implementation and it would add a lot of code complexity to support what you suggest which we deemed unnecessary.
If you refer to the properties panel of a filter, yes i agree, but if you refer to any representation setting that has auto-apply, then in my mind. and considering the current implementation, it makes sense.
Thank you for your detailed response and for taking the time to investigate this issue.
Regarding case 1:
You’ve correctly identified a potential ambiguity when multiple blocks in a hierarchy have different colorings and belong to the same assembly node. I agree that introducing separate AssemblyBlockColor and HierarchyBlockColor attributes could provide a more flexible and intuitive way to handle these cases.
I would be delighted if you ever decide to improve the block coloring feature.
Regarding case 2:
I understand that in my current workflow, I am primarily working with block colors at the assembly level and have not encountered scenarios where the assembly structure changes significantly between apply.
new question
While developing a ParaView plugin, I’m encountering an issue with applying colors to blocks. The colors are applied on the first call (in RequestData) no reset ?
but on subsequent apply calls, the colors are reset after.
Is there a way to intervene after this reset and reapply the colors at that moment?
From a development cost point of view, i don’t foresee the addition of Assembly and Hierarchy specific properties. But we would be open to implementing it assuming there is a funding option, or you want to contribute these changes yourself.
Is this correct?
If so, considering that we know the difference between hierarchy and assembly, why does ParaView need to perform a reset when switching from hierarchy to assembly or from assembly to hierarchy?
That is correct, the name of the root node is /Root/ not but its label is vtkPartitionedDataSetCollection. In the paths you should always use the names.
What do you mean we know the difference between hierarchy and assembly?
It needs to perform a reset because we don’t have assembly specific and hierarchy specific properties. We only have block properties that apply to both.
The XML name of the parent node for both the hierarchy and the assembly should be different, allowing for distinct paths between the hierarchy and assembly.
This would enable ParaView to have separate block colors for the hierarchy and the assembly within the same ‘blockColor’ property.
Consequently, there would be no need for a reset between the two, as the property would unambiguously hold the colors for both.
ParaView could ignore the links between the assembly and the hierarchy as they are too complex to implement.
For example:
partitionedDataSetCollectionSource1Display.BlockColors = [‘/Assembly/NonOrientableSurfaces’, ‘0.000000’, ‘0.764706’, ‘1.000000’,‘/Root/Boy’,‘0.000000’, ‘0.1’, ‘1.000000’]
=> Assembly view = 1 color on node “NonOrientableSurfaces” and Hierarchy view = 1 color on node “Boy”
