[vtk-developers] Selecting Fields for Filtering

Gary Templet gjtempl at sandia.gov
Thu Nov 21 12:46:13 EST 2002


On Thursday 21 November 2002 08:55 am, Ken Martin wrote:
> > 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

Thanks, Ken.

I'm not sure what your time frame is for releasing VTK4.2, but I would hope 
that the issues you mentioned about how to properly have filters select their 
inputs could be worked out by then. I understand that you want to have the 
4.2 API in such a state that developlers won't have to change their code in 6 
months, when a better design comes along.

However, I would argue that if I code to the VTK4.2 api without the current 
"filter selects field" code, my only option is to use vtkAssignAttributes. If 
that's the case, I will definitely change my code anyway when the more 
elegant filter solution comes along. Simply because vtkAssignAttributes in 
not as extensible as the "filter selects field" solution.

In fact, moving from the current interface (where filters select their fields, 
albeit with hand-coded solutions) is less a chore than removing numerous 
instances of vtkAssignAttributes. So, I would respectfully argue that for 
developers who are looking to use the "filter selects field" solution in it's 
mature state, removing the current functionality to do that, is a disservice, 
since the current "filter selects fields" solution, which may not be the 
correct answer, is closer to the correct answer than vtkAssignAttributes.

Will the current filter selecting fields solution remain in the nightlies?

Cheers,
Gary









More information about the vtk-developers mailing list