[vtk-developers] splitting vtkSurfaceReconstructionFilter into 2 classes

[David Doria]

On Mon, Aug 2, 2010 at 4:39 PM, Will Schroeder
<will.schroeder at kitware.com> wrote:
> I totally am with you on this, especially refactoring the class to break out
> the normal estimation. Renaming the class is problematic though, since Bill
> L. is still around with his golf clubs and I don't want to be struck with a
> nine iron :-) But maybe we can wait for winter ;-) or come up with a
> transition plan across multiple releases.

Bill, are you really going to hit us with a 9 iron??

I think the most important part of this idea is to expose the normal
estimation. Renaming the class is, at least to me, a secondary event.
I know plenty of people who have turned to CGAL because this
functionality was not available in VTK. As Arnaud said, I implement it
a while back (a combination of vtkPointSetNormalEstimation and
vtkPointSetNormalOrientation from here
http://www.midasjournal.org/browse/publication/708) following Hoppe's
method exactly. The implementation in vtkSurfaceReconstructionFilter
seems to be slightly modified, but seems to be much faster and doesn't
require Boost (for the MST computation), so it seems like a better
choice.

I volunteer to help Arnaud with cleaning up/documenting/whatever else
he needs help with to get this VTK ready. Of course we will modify
vtkSurfaceReconstructionFilter to use the new
vtkNormalEstimationFilter.

As for the renaming:
It's kind of long, but a name like
vtkImplicitFunctionSurfaceReconstructionFilter makes sense. Or maybe
vtkImplicitFunctionSurfaceFilter? As long as it is noted in a release
it shouldn't be a big deal, right? People could just do a "find and
replace" to bring their code up to date.

One more issue - I had named my class
vtkPointSetNormalEstimationFilter to distinguish that it was not a
mesh normal estimation filter. Is this necessary? Or is
vtkNormalEstimationFilter ok?

Thanks,

David