[vtk-developers] vtkHyperTreeGridGeometry and vtkDataSetSurfaceFilter

[Marcus D. Hanwell]

On Thu, May 10, 2012 at 10:13 AM, Philippe Pebay
<philippe.pebay at kitware.com> wrote:
> Hello all:
>
> I have a question regarding vtkDataSetSurfaceFilter, the accelerated
> version of the Geometry filter.
>
> My question is the following: I would like to make
> vtkDataSetSurfaceFilter able to automatically fork off to the
> vtkHyperTreeGridGeometry filter when the data object is found to have
> type VTK_HYPER_TREE_GRID.
> This seems like a simple addition to make, by simply instantiating the
> hyper tree grid geometry filter when the case is met in the switch
> statement of vtkDataSetSurfaceFilter::RequestData().
>
> However, this would introduce a dependency of Filters/Geometry on
> Filters/HyperTree because this is where the hyper tree grid geometry
> filter currently is, which is certainly a bad thing.
>
> So, we can think of 2 possible ways to mitigate that:
> 1. Move vtkHyperTreeGridGeometry to Filters/Geometry. Whch would
> defeat the purpose of the Filters/HyperTree module, which is there
> precisely to hold hyper tree grid algorithms, so one has the option to
> not build support for tree-based AMR things.
> 2. Another route is to create a new module Filters/SurfaceExtractiion
> whose purpose would be to contain only surface extraction filters
> (including the HyperTreeGrid one).
> I am not sure that either of these options is really great, for the
> sake of modularity, it would be nice to be able to turn off all hyper
> tree support.
>
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. An alternative you
didn't mention is one of filter registration and extending the
vtkDataSetSurfaceFilter at run time.

You can see an example of this in vtkIOSQL and the related modules
vtkIOMySQL, vtkIOPostgreSQL. If the vtkIOMySQL module is linked then
is uses the auto init logic to register a new handler with the
vtkSQLDatabase function.

The other alternative would be to derive from vtkDataSetSurfaceFilter
and create an override if the hyper tree module is linked that would
use the hyper tree filter if appropriate. Users who do not link get
the normal class, those who do get the more derived version of the
filter - this would not support registering multiple handlers but
should satisfy your current need.

Marcus