[vtk-developers] vtkHyperTreeGridGeometry and vtkDataSetSurfaceFilter

[Berk Geveci]

You don't have the choice of extending it at compile time :-) As of VTK 6,
we will not allow for the content of individual modules to change based on
compile-time (i.e. CMake) options.

The run-time options sounds overly complicated and computer-sciency to me.
And they are harder to support when linking statically. But that's me. I am
a simple mechanical engineer.

If this was my code, I would put the new geometry filter in the same place
as the dataset surface filter and be done with it. If I felt like being
fancy, I might consider creating a SurfaceExtraction module and move all
surface filters there.

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?
>
> 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
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtk-developers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20120514/8b748899/attachment.html>