[vtk-developers] vtkHyperTreeGridGeometry and vtkDataSetSurfaceFilter

Marcus D. Hanwell marcus.hanwell at kitware.com
Mon May 14 15:01:10 EDT 2012


On Mon, May 14, 2012 at 2:13 PM, Philippe Pebay
<philippe.pebay at kitware.com> wrote:
> Hello Marcus
>
> Thanks for having taken the time to respond.
>
> So, regarding this option:
>> Having a pattern where one module creates meta-filters, combining
>> those of multiple modules is reasonable. If one wishes to use that
>> filter then they accept the dependency graph.
> Yes, but in this case the "wish" would be almost a mandate, as the use
> of vtkDataSetSurfaceFilter is quite prevalent (for example this is the
> one used by PV for surface extraction, and not vtkGeometryFilter). On
> the other hand I think that HyperTreeGrid is quite an exotic data set.
> So, is it all right to force this dependency for all users?
>
> If the answer to this question is no, then we have the choice of
> extending either during compilation, or at run time. If I am not
> mistaken, a good example of the former is the Statistics vs.
> StatisticsGnuR. Is this correct?
>
Yes, the GNU R statistics would be a good example. In that case if you
link to the GNU R module it uses the object factory to replace the
relevant classes with more derived forms. I personally think that
pattern, or the one used in the SQL classes to register additional
handlers in the base class when registered.

They are both run time techniques that do not make the meta-filter
highly dependent on every other module. If you choose the object
factory approach you should remember to replace vtkStandardNewMacro
with vtkObjectFactoryNewMacro in the vtkDataSetSurfaceFilter
implementation.

Marcus



More information about the vtk-developers mailing list