When using vtkWindowedSincPolyDataFilter with NormalizeCoordinates enabled then we have found that smoothing result is slightly shifted when the bounding box of the mesh is changed. (originally reported by a 3D Slicer user here).
Interesting. I wonder if there is some sort of integral math occuring during the normalization process. Or somehow processing an intermediate iteration. I’ll take a look tomorrow morning.
Considering that smoothing moves the surface by several tenths of a millimeter, the one tenth of a millimeter shift would be acceptable. The main issue is inconsistency - that the movement of the surface depends on the bounding box size.
I’ve downloaded the data and will check it out soon.
Changing the API / behavior is something I would do only as a last resort, although the documentation certainly needs updating. It wouldn’t surprise me if there are folks in the oil/gas/geomapping areas with extremely large coordinate values who may rely on normalization. I’m guessing that this normalization was originally added for a reason due to numerical sensitivity and this may be an example of this sensitivity. Or it could be a bug It’s probably worth looking at Taubin’s original paper to see if there are any comments related to this behavior.
If coordinate normalization is only recommended for special cases then we are completely fine with disabling it.
We used coordinate normalization because there was the scaling issue in the initial implementation and they we kept it because the documentation suggested that coordinate normalization should be turned on for better stability (an it is just not enabled by default to maintain exact backward compatibility).
Hi @will.schroeder , @lassoan
It is really nice work. Is there any filter that can smooth by joining the outer points (vtkWindowedSincPolyDataFilter seems to shrink the object)?
Thanks.
It’s probably worth looking at Taubin’s original paper to see if there are any comments related to this behavior.