[vtk-developers] Selecting Fields for Filtering

[Ken Martin]

> 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.


Hello Gary,

Thanks for the feedback. The plan is to provide all three interfaces as
you described above. The first two interfaces are implemented in a way
that I feel is correct and will not have top be changed in the near
future (we all hate changing APIs). The third approach is not currently
implemented correctly in my opinion. There is no question that we will
provide that functionality, but it will probably not make it into VTK
4.2 because the correct solution involves making that functionality
available to all filters in a clean and consistent manner. Currently it
has been hand added to a few filters (generally the method names are
consistent but no API enforces that) but not all. Also since it is added
to specific filters you must know the specific filter before being able
to apply the method. There is no capability to ask a vtkSource to do
this. The more general solution would support such operations on
vtkSource and hence all of its subclasses. 

This also ties into a general method for determining what arrays are
available and requesting specific arrays through a pipeline. These
issues require some thought and development so that we can get them
right and not end up changing the API six months from now. We do receive
a few complaints about API changes so we want to reduce them as much as
possible.

Thanks
Ken