[vtk-developers] Selecting Fields for Filtering

[Charles Law]

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




First, there were already several filters in VTK that allowed different 
arrays (i.e. Vectors vs. Normals in glyph) to be used for execution. The 
current "SelectInputScalars" ... methods are a first step at extending this 
feature to arbitrary field arrays. I am not terribly happy with the chosen 
API because the method names do not use the VTK Set/Get conventions. Also, 
there is no way to differentiate between Cell and Point arrays. If a filter 
required a selectable point scalar array as well as a selectable cell 
scalar array, you would be stuck.

Not all filters/ vtkSources have selectable arrays, the API cannot be 
defined in the super class. Just like "SetInput" of vtkImageToImageFilter 
or better "SetSource" of vtkGlyph, the array selection methods must also be 
defined in subclasses and specific filters. I also dislike adding features 
that increase the complexity of VTK super classes like vtkSource.

I do not know what the final solution will be, but I do know that it will 
certainly not be solved for the 4.2 release. I doubt that it will be 
implemented in the next several months. Since the current API will most 
likely be changed/improved, I understand that it should not be a part of 
the 4.2 release. I purposely kept it out of the 4.0 release for this reason.

However, I do like the option of adding it back into the development 
release after the official 4.2 branch has been created. This would save me 
(or Berk :) a fair amount of work changing ParaView to use 
vtkAssignAttribute filters.


Charles.