I have made a new class vtkDisplacementPolyDataFilter. It is an exact copy of vtkDistancePolyDataFilter except that one in addition to a signed distance gets a “direction”. It is pretty cool if one wished to visualize displacement of meshes and show the displacements using glyphs on the surface.
I have created unit test and baseline image, shown below
Would it be of interest to either add this or replace the existing vtkDistancePolyDataFilter? When working with registration task and clinical images, this is very useful - especially after SMPTools is used (sorry for the data race I introduced in an earlier MR).
Jens, great stuff. Can’t you just extend vtkDistancePolyDataFilter so that it can optionally produce a direction? Duplicating code is to be discouraged whenever possible.
Thank you @Jens_Munk_Hansen this feature has been missing from the VTK filter for a long time. We have been using the NIRAL group’s modified version of this filter that provides the displacement vector. I don’t know why nobody has thought about contributing this useful change back to VTK. Note there are also some modifications to vtkImplicitPolyDataDistance filter in the same folder. If you have time it would be nice if you could have a look if there was anything else worth porting back to VTK.
+1 for adding this as a new feature to the existing class
Will do that. Note also that the filter now uses SMTools and the faster vtkStaticCellLocator. I use a lot of homemade filters but improving the distance filter seemed like an easy thing to do which many would benefit from
I decided to go for a AOS output and output unit vectors in addition to the signed/unsigned distances. It is quite convenient since then you can use the distances for scaling the vectors. It is a little difference from how the NIRAL group has modified the filter.
Hi @lassoan . I will consider adding an extra function to vtkImplicitPolyDataDistance. The possibility to know if the nearest point is an edge. With this distances can be computed between meshes avoiding the large values from boundaries.
For mesh registration, you need to reject outliers based on some distance threshold anyway, so I’m not sure if adding a mechanism to reject points based on boundary/non-boundary closest point would improve the results. You can only get definitive answer by comparing the results with both approaches (with and without boundary point rejection) on real data sets.
Yes, I know. The rejection for mesh difference I would use for visualization of the displacement field. One could of course always use a threshold on the length of the displacement vectors
If the goal of visualization is to help with assessing the registration quality (and understand the root cause of residual registration error) then I would use the same outlier rejection method for registration and visualization.
But maybe if you show some pictures that could help explaining why the additional boundary point based filtering seems necessary.
