[vtk-developers] Selecting Fields for Filtering

[Gary Templet]

Hi,

After hearing that the issue of selecting fields for a particular 
mapper/filter/etc was being debated at Kitware, I wanted to add my voice to 
the debate and argue for having each filter/mapper have the ability to select 
the particular field on which it would like to operate.

In General, there seems to be three ways in VTK to make sure a filter/mapper 
has access to the correct field.

1. Have the source object set an active Scalar and/or Vector field
	vtkDataSetAttributes::SetActiveScalars()
	vtkDataSetAttributes::SetActiveVectors()	
	vtkDataSetAttributes::SetActiveTensors()

2. Insert a vtkAssignAttribute filter before each filter and mapper in the 
pipeline to ensure they see the correct field.

3. Have filters and mappers choose the field on which to operate from those 
provided by the input data set. (from the compound member list)
	# SelectInputScalars() : ....... vtkWarpScalar, vtkThreshold, 
						vtkGlyph3D, vtkContourGrid, 
						vtkContourFilter, vtkClipDataSet, 
						vtkBandedPolyDataContourFilter ...........
	# SelectInputVectors() : vtkWarpVector, vtkStreamTracer, 
					vtkRibbonFilter, vtkGlyph3D
	# SelectColorArray() : vtkMapper


There's no reason all three can't be supported. Although there is some 
overlap, they do perform useful and exclusive funtionality, none of which 
should be eliminated from VTK.

However, in general item three offers the most flexibility and is the easiest 
to implement when developing vis apps.



Item 1 allows you to set a default answer to the question, "On which field 
should I operate"? If downstream filters fail to specify the field on which 
they would like to operate, then properly setting an Active Scalar and  
Vector gives you a reasonable default.

Item 2 is basically a field data mask which makes available only the specified 
fields to downstream objects, certainly a useful object. However, the way 
it's implemented now, every field which is to be made available to a 
filter(s) must pass through a seperate vtkAssignAttribute class. Therein lies 
the code bloat. You find yourself implementing the exact same object over and 
over with only one or two changes between them. It seems logical that this 
functionality should be absorbed by another object in order to hide this 
implementation.

Again you have the same problem that filters downstream to a particular 
vtkAssignAttribute class only see the fields made available by that 
vtkAssignAttribute class.

So, if you want to filter on a different field, then you have to create a new 
vtkAssignAttribute class. Again.

And again,.......



Item 3 allows users to EASILY (i.e. less code must be written) specify which 
field each filter and mapper should operate on. One call, that's all. 
Granted, there are still some issues with how to make the syntax more 
consistent, but IMHO this is the right place for the distinction between 
fields to be made.
        It hides the implementation from the user and reduces code bloat by 
incorporating the functionality of certain repeated snippets of code 
(vtkAssignAttribute code) into the object which require them.



One reason to use VTK is that you can develop vis apps without having to write 
numerous lines of code. If vtkAssignAttribute is the only way to distinguish 
between fields, then VTK becomes less attractive as it requires much more 
development time and effort.

And instead of spending time thinking about visualization, I'm forced to think 
about what filters CAN see.

Item 3 requires only that you specify what fields filters WANT to see. They 
can alreadly see ALL the fields, it's just a matter of choosing between them. 
Much more democratic in my opinion:)


In short, I propose that having the ability to distinguish between fields as 
an inherent property of the filters, mappers, and anything else that might 
operate on fields should become the main mode of operation for VTK, or at 
least continue to be supported as a first-class functionality.

I look forward to hear more about what Kitware's plans are in regards to this.

Thanks,
Gary Templet