[vtk-developers] vtkHyperTreeGridGeometry and vtkDataSetSurfaceFilter

[Philippe Pebay]

Hello Berk

Thanks for the feedback.

I did not realize that CMake compiler options were now entirely banned
in VTK. That is quite a change indeed. I am also concerned by the
complexity of the run-time options.

Creating a SurfaceExtraction makes sense if we assume that there might
be one user somewhere who wants to use VTK but without surface
extraction. That is the point of modules, isn't it?

So, the simplest solution (moving the hyper tree grid surface filter
where the other surface filters are) seems reasonable. If nobody has a
strong disagreement then this is what I will do.

Thanks for the comments
Philippe


On Mon, May 14, 2012 at 11:12 PM, Berk Geveci <berk.geveci at kitware.com> wrote:
> 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
>>
>



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