[vtk-developers] vtkHyperTreeGridGeometry and vtkDataSetSurfaceFilter

[Philippe Pebay]

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?

Thanks
Philippe


On Fri, May 11, 2012 at 8:43 PM, Marcus D. Hanwell
<marcus.hanwell at kitware.com> wrote:
> 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



-- 
Philippe Pébay, PhD
Director of Visualization and High Performance Computing /
Directeur de la Visualisation et du Calcul Haute Performance
Kitware SAS
26 rue Louis Guérin, 69100 Villeurbanne, France
+33 (0) 6.83.61.55.70 / 4.37.45.04.15
http://www.kitware.fr