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.