How to update the scalar range for evolving scalar values in a pipeline?

Hello!!!

I have a fairly standard pipeline, the key piece of which is represented by the fragment below consisting of a vtkUnstructuredGrid (“data” below), a mapper and lookup table.
The vtkUnstructuredGrid has multiple scalar point fields, and the rest of the pipeline before the section shown can cause new fields to be added or existing ones changed

When I set the pipeline up, I grab the range of the first field and use that to configure the scalar range on the mapper. But that operation is outside of the pipeline - so if the range of the field changes or the code sets a new active Scala field the scalar range on the mapper is not updated.

What is the preferred way to update the scalar range on the mapper using the pipeline?

    data.GetPointData().SetActiveScalars('Node ID')
    range=data.GetScalarRange()

    lut = vtkLookupTable()
    lut.SetHueRange(0.667, 0)
    lut.Build()
 
    mapper = vtkDataSetMapper()
    mapper.SetLookupTable(lut)
    mapper.SetInputDataObject(data)
    mapper.SetScalarRange(data.GetScalarRange())

I guess I can use an Observer to listen for changes to the target scalar field elsewhere in the pipeline - or maybe even in the mapper - and then update the range in the callback.

But it seems that this would be a useful feature for the pipeline to support and I’m interested to know if I’m just missing something…

VTK leaves it up to you to update the range of lookup tables.

It could be complicated to figure out all the ways VTK users might want to update/not update/conditionally update lookup table ranges and then encode them. ParaView has several modes that specify lookup table update strategies - do nothing to update lookup table ranges, only change the min if new min is lower/change the max if new max is greater, always reset to the new data range, etc. Understanding such modes can be a pain, and they might not do exactly what you want to do, leaving you to update the range yourself anyway.

Thanks Cory. That makes a lot of sense - and it helps to know I’m not missing something obvious.

I’m in a similar position now with resetting the camera on a subset of the actors and renderers associated with a render window. At first I was a little frustrated that I couldn’t just reset to all actor bounds, but then I realized that isn’t actually what I want and I really do need a very specific reset logic that I need to code