When one loads a composite dataset such as MultiBlock DataSet or Partitioned DataSet Collection into ParaView, ParaView generates a “vtkBlockColors” data array and colors the dataset by it by default. Anecdotally I have heard from a couple of sources, like this one, that it can be confusing, especially if your dataset has block IDs in a data array already. Furthermore, when you save this data the vtkBlockColors array is not saved to the file, which can be another source of confusion.
I don’t know the history of “vtkBlockColors”, but I assume it was added to clearly indicate that data loaded has separate blocks. Is that still useful?
I don’t remember the details, but the feature probably started because other tools Sandia users had automatically colored by block, and this was expected in ParaView, too. I remember going through several iterations of this, fixing conditions where the block colors didn’t show up.
The creation and exposure of the vtkBlockColors array is awkward, but that is just a consequence of ParaView’s structure. When you directly select the coloring on the object, you kinda have to create an item to select.
I for one like this feature and would argue against getting rid of it. Rather, I suggest correcting some of the things users find confusing. That would probably mean making block coloring “more special.” I think that would mean making the block coloring entry in the color combo box behave more like the special Solid Color entry.
The name should say Block Coloring or something like that rather than the name of the array.
The color bar should not be shown. (This will prevent confusion from VTK internal ids mismatching ids assigned by other arrays.)
The edit colors button does something special (maybe).
I don’t have much to add to Ken’s thoughts. I suspect the history is as Ken mentions, but I don’t know. I do know users use this feature, as do I. The example bake.e is a good example where it works well.
I do know we have had issues for decades being able to tell what arrays are ParaView generated and which are read in from the dataset. it would be nice if that could be clarified somehow.
By the way, the KAAMS color map was made by me a million years ago. If someone like Francesca came up with a better one, you would hear no complaints from me.
Block colors is useful for structural models with many blocks and should be retained in some form. I’m not familiar with all of the issues with vtkBlockColors, but for ExodusII files opened with the IOSS Reader it seems to roughly correspond to Exodus Block ID numbers (0-based index, rather than 1-based).
However, when opening an ExodusII file:
vtkBlockColors is the default only on the first RenderView. Opening a new RenderView of the same dataset does not color by vtkBlockColors; consistency here would be nice.
There are at least 2 other fields that seem to do the same thing: object_id cell field and vtkCompositeIndex (cell and point fields). The object_id field corresponds to actual IDs, but is difficult to use because the color map is continuous, so visualizing blocks individually with nearby numbering is difficult. With 100 blocks, block_78 and block_79 start to look a lot a like. I have no idea what vtkCompositeIndex does for me and happy to have it removed.
The color bar is useful for me, so that I can identify which of my blocks is “block_1” and which is “block_2”.
Calling it something more specific like “BlockId” might be nicer than “vtkBlockColors”.
In my experience, having blocks be different colors is useful for some users. The major issue with this feature is that colors could change over time. If the colors could be consistent over time, then this feature would be much more useful.
if i may add my grain of sand to the conversation, something ‘missing’ in paraview is to be able to do something similar to this (give a color for each region/block) but for specific fields. something like the behavior of what salome calls ‘auto color’. that it would check the number of different values of a int field and then color them with a different color each. what it is actually doing vtkBlockColor but for any integer field. I mentionned about this here. if extended this way it could be used also for the coloring of the blocks… I am thinking cases such as connectivity output and being able to color each region by a different color ‘interpret them as the blockID’
Adding some “color” to Ken’s comment, IIRC, this was added since we needed to randomly color all blocks with different colors so that one could quickly tell them apart. Rather using a monotonically increasing number such composite ID, we just assigned a mod-12 (or so) ID to each block and then together with 12-value categorical colormap, we got the effect we needed.
If we want to use colors to tell features apart (e.g. colors in a line chart or block colors as in this post), there are better ways than generating them randomly. A well-known method is the Glasbey lookup table (LUT). I considered implementing something similar years ago, sketched the ideas but finally didn’t implement it. You can find a tentative algorithm and many references is this issue: Automatic color generation in the label2rgb function · Issue #4507 · scikit-image/scikit-image · GitHub
I also like block coloring. This automated coloring for blocks is similar to automated coloring for Process Ids when running pvserver in parallel. I know users have been confused by that as well so whatever solution is used for block coloring may also be considered for Process Id.