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

Development
1

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

2

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.

3

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.

Markus

SmoothDiscreteMarchingCubes.7z (2.34 KB)

4

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)

5

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?

image

6

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)

7

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.

8

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