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.<div><br></div><div>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.<br>
<br></div><div>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.</div>
<div><br><div class="gmail_quote">On Mon, May 14, 2012 at 2:13 PM, Philippe Pebay <span dir="ltr"><<a href="mailto:philippe.pebay@kitware.com" target="_blank">philippe.pebay@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello Marcus<br>
<br>
Thanks for having taken the time to respond.<br>
<br>
So, regarding this option:<br>
<div class="im">> Having a pattern where one module creates meta-filters, combining<br>
> those of multiple modules is reasonable. If one wishes to use that<br>
> filter then they accept the dependency graph.<br>
</div>Yes, but in this case the "wish" would be almost a mandate, as the use<br>
of vtkDataSetSurfaceFilter is quite prevalent (for example this is the<br>
one used by PV for surface extraction, and not vtkGeometryFilter). On<br>
the other hand I think that HyperTreeGrid is quite an exotic data set.<br>
So, is it all right to force this dependency for all users?<br>
<br>
If the answer to this question is no, then we have the choice of<br>
extending either during compilation, or at run time. If I am not<br>
mistaken, a good example of the former is the Statistics vs.<br>
StatisticsGnuR. Is this correct?<br>
<br>
Thanks<br>
<span class="HOEnZb"><font color="#888888">Philippe<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On Fri, May 11, 2012 at 8:43 PM, Marcus D. Hanwell<br>
<<a href="mailto:marcus.hanwell@kitware.com">marcus.hanwell@kitware.com</a>> wrote:<br>
> On Thu, May 10, 2012 at 10:13 AM, Philippe Pebay<br>
> <<a href="mailto:philippe.pebay@kitware.com">philippe.pebay@kitware.com</a>> wrote:<br>
>> Hello all:<br>
>><br>
>> I have a question regarding vtkDataSetSurfaceFilter, the accelerated<br>
>> version of the Geometry filter.<br>
>><br>
>> My question is the following: I would like to make<br>
>> vtkDataSetSurfaceFilter able to automatically fork off to the<br>
>> vtkHyperTreeGridGeometry filter when the data object is found to have<br>
>> type VTK_HYPER_TREE_GRID.<br>
>> This seems like a simple addition to make, by simply instantiating the<br>
>> hyper tree grid geometry filter when the case is met in the switch<br>
>> statement of vtkDataSetSurfaceFilter::RequestData().<br>
>><br>
>> However, this would introduce a dependency of Filters/Geometry on<br>
>> Filters/HyperTree because this is where the hyper tree grid geometry<br>
>> filter currently is, which is certainly a bad thing.<br>
>><br>
>> So, we can think of 2 possible ways to mitigate that:<br>
>> 1. Move vtkHyperTreeGridGeometry to Filters/Geometry. Whch would<br>
>> defeat the purpose of the Filters/HyperTree module, which is there<br>
>> precisely to hold hyper tree grid algorithms, so one has the option to<br>
>> not build support for tree-based AMR things.<br>
>> 2. Another route is to create a new module Filters/SurfaceExtractiion<br>
>> whose purpose would be to contain only surface extraction filters<br>
>> (including the HyperTreeGrid one).<br>
>> I am not sure that either of these options is really great, for the<br>
>> sake of modularity, it would be nice to be able to turn off all hyper<br>
>> tree support.<br>
>><br>
> Having a pattern where one module creates meta-filters, combining<br>
> those of multiple modules is reasonable. If one wishes to use that<br>
> filter then they accept the dependency graph. An alternative you<br>
> didn't mention is one of filter registration and extending the<br>
> vtkDataSetSurfaceFilter at run time.<br>
><br>
> You can see an example of this in vtkIOSQL and the related modules<br>
> vtkIOMySQL, vtkIOPostgreSQL. If the vtkIOMySQL module is linked then<br>
> is uses the auto init logic to register a new handler with the<br>
> vtkSQLDatabase function.<br>
><br>
> The other alternative would be to derive from vtkDataSetSurfaceFilter<br>
> and create an override if the hyper tree module is linked that would<br>
> use the hyper tree filter if appropriate. Users who do not link get<br>
> the normal class, those who do get the more derived version of the<br>
> filter - this would not support registering multiple handlers but<br>
> should satisfy your current need.<br>
><br>
> Marcus<br>
<br>
<br>
<br>
</div></div><div class="im HOEnZb">--<br>
Philippe Pébay, PhD<br>
Director of Visualization and High Performance Computing /<br>
Directeur de la Visualisation et du Calcul Haute Performance<br>
Kitware SAS<br>
26 rue Louis Guérin, 69100 Villeurbanne, France<br>
<a href="tel:%2B33%20%280%29%206.83.61.55.70" value="+33683615570">+33 (0) 6.83.61.55.70</a> / 4.37.45.04.15<br>
<a href="http://www.kitware.fr" target="_blank">http://www.kitware.fr</a><br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.vtk.org/mailman/listinfo/vtk-developers" target="_blank">http://www.vtk.org/mailman/listinfo/vtk-developers</a><br>
<br>
</div></div></blockquote></div><br></div>