vtkWindowedSincPolyDataFilter does NOT translate and scale the position coordinates back to the original coordinate frame

Hi, I noted a somewhat unexpected behavior when using the vtkWindowedSincPolyDataFilter.

From the description of the filter, I expected that activation of the “NormalizeCoordinatesOn()” option should not affect the coordinates of the output.

However, I just checked with an amended version of the “SmoothDiscreteMarchingCubes” example (Cxx) that turning NormalizeCoordinatesOn or Off (smoother->NormalizeCoordinatesOn(); vs smoother->NormalizeCoordinatesOff(); ) does results in a different outcome regarding the scale and position of the data.

I saved the results for both settings to a PLY file and it seems that with NormalizeCoordinatesOn(), the results returned by the filter reamin scaled and centred at the origin (bounds in Y are e.g. -0.282817 to 0.282877) whilst with NormalizeCoordinatesOff() the data appears at the expected location (bounds in Y are -43.4272 to 39.387).

This is on Windows 10, using a vcpkg installation of vtk (vtk:x64-windows, 9.0.3-pv5.9.1#5).

Is there maybe any other setting I might be missing here?
It would be lovely to get some thoughts on what could be going on here.

Markus, can you send code? I just ran through the filter with the debugger (using the test TestWindowedSincPolyDataFilter2.py), and printed the output and all seemed to work fine.

Thanks very much for looking into that – it might very well be a user problem though it was not obvious to me what would be the issue.

I’ve attached the code and Cmake list I used.


SmoothDiscreteMarchingCubes.7z (2.34 KB)

Markus everything seems to be fine. Check out the modified code. I’m not sure where you are getting the bounds values. Both files overlap in ParaView etc.

SmoothDiscreteMarchingCubes.cxx (6.03 KB)

Ah - thanks so much – this is weird though: if I run that very code you provided here I do get bounds as shown below (I saved the PLY files and opened them in ParaView where I got the bounds I mentioned earlier). At least here these files do not overlap.

Any idea what could possibly cause that behavior or suggestions on how to further explore that matter, for dummies?


It’s a mystery Markus :slight_smile: I have no idea, except maybe somehow your code is picking up an old library etc. For reference, this is the output I see:

Discrete MC Bounds(: -42.4242,42.4242, -43.4343,39.3939, -43.4343,42.4242)
On Bounds(: -42.4135,42.4123, -43.4232,39.4103, -43.4242,42.4144)
Wrote file: poly_with_normalising_on.ply
Off Bounds(: -42.4135,42.4123, -43.4272,39.4062, -43.4252,42.4134)
Wrote file: poly_with_normalising_off.ply
On Bounds(: -42.4135,42.4123, -43.4232,39.4103, -43.4242,42.4144)

Ok, thanks – I’ve checked but did not see an obvious issue so, for now, I have downloaded the python wheels for VTK 9.1 and am using these (all good as expected there). I will try the Cxx version again once vtk9.1 is available for vcpkg.

This was a regression in the filter after its big refactoring (2020-05-25). It was fixed here (2021-02-02).