# Replace vtkDistancePolyDataFilter with vtkDisplacementPolyDataFilter

**URL:** <https://discourse.vtk.org/t/replace-vtkdistancepolydatafilter-with-vtkdisplacementpolydatafilter/11599>\
**Category:** Development\
**Created:** [June 1, 2023, 7:16pm UTC](https://discourse.vtk.org/t/replace-vtkdistancepolydatafilter-with-vtkdisplacementpolydatafilter/11599 "2023-06-01T19:16:21Z")\
**Posts on this page:** 13\
**Page:** 1

<div class="post-metadata">

**Author:** ![Jens\_Munk\_Hansen](https://discourse.vtk.org/user_avatar/discourse.vtk.org/jens_munk_hansen/32/1215_2.png) [@Jens\_Munk\_Hansen](https://discourse.vtk.org/u/Jens_Munk_Hansen)\
**Post date:** [June 1, 2023, 7:16pm UTC](https://discourse.vtk.org/t/replace-vtkdistancepolydatafilter-with-vtkdisplacementpolydatafilter/11599/1 "2023-06-01T19:16:21Z")

</div>

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

![hello](https://discourse.vtk.org/uploads/default/original/2X/e/e462e1d134ee6ed920bb09ca364277dfef252144.png)

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).

@Charles_Gueunet

I will read up on how to upload the baseline image - I know how to add the .sha512 file.

---

<div class="post-metadata">

**Author:** ![will.schroeder](https://discourse.vtk.org/user_avatar/discourse.vtk.org/will.schroeder/32/233_2.png) [@will.schroeder](https://discourse.vtk.org/u/will.schroeder)\
**Post date:** [June 1, 2023, 9:44pm UTC](https://discourse.vtk.org/t/replace-vtkdistancepolydatafilter-with-vtkdisplacementpolydatafilter/11599/2 "2023-06-01T21:44:31Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![cory.quammen](https://discourse.vtk.org/user_avatar/discourse.vtk.org/cory.quammen/32/6751_2.png) [@cory.quammen](https://discourse.vtk.org/u/cory.quammen)\
**Post date:** [June 1, 2023, 11:04pm UTC](https://discourse.vtk.org/t/replace-vtkdistancepolydatafilter-with-vtkdisplacementpolydatafilter/11599/3 "2023-06-01T23:04:19Z")

</div>

> [@will.schroeder](#):
>
> Can’t you just extend vtkDistancePolyDataFilter so that it can optionally produce a direction?

+1

---

<div class="post-metadata">

**Author:** ![Jens\_Munk\_Hansen](https://discourse.vtk.org/user_avatar/discourse.vtk.org/jens_munk_hansen/32/1215_2.png) [@Jens\_Munk\_Hansen](https://discourse.vtk.org/u/Jens_Munk_Hansen)\
**Post date:** [June 2, 2023, 5:06am UTC](https://discourse.vtk.org/t/replace-vtkdistancepolydatafilter-with-vtkdisplacementpolydatafilter/11599/4 "2023-06-02T05:06:11Z")

</div>

The upstream branch is here  
[https://gitlab.kitware.com/jens.munk.hansen/vtk/-/commits/DisplacementFilter](https://gitlab.kitware.com/jens.munk.hansen/vtk/-/commits/DisplacementFilter)

---

<div class="post-metadata">

**Author:** ![Jens\_Munk\_Hansen](https://discourse.vtk.org/user_avatar/discourse.vtk.org/jens_munk_hansen/32/1215_2.png) [@Jens\_Munk\_Hansen](https://discourse.vtk.org/u/Jens_Munk_Hansen)\
**Post date:** [June 2, 2023, 5:09am UTC](https://discourse.vtk.org/t/replace-vtkdistancepolydatafilter-with-vtkdisplacementpolydatafilter/11599/5 "2023-06-02T05:09:37Z")

</div>

@will.schroeder Yes, modify vtkDistancePolyDataFilter. That is a better option. Would it be okay to add an extra test where this option is used?

---

<div class="post-metadata">

**Author:** ![will.schroeder](https://discourse.vtk.org/user_avatar/discourse.vtk.org/will.schroeder/32/233_2.png) [@will.schroeder](https://discourse.vtk.org/u/will.schroeder)\
**Post date:** [June 2, 2023, 8:48am UTC](https://discourse.vtk.org/t/replace-vtkdistancepolydatafilter-with-vtkdisplacementpolydatafilter/11599/6 "2023-06-02T08:48:06Z")

</div>

Yes of course, a separate test is fine. The more testing the better as far as I am concerned,

---

<div class="post-metadata">

**Author:** ![lassoan](https://discourse.vtk.org/user_avatar/discourse.vtk.org/lassoan/32/50_2.png) [@lassoan](https://discourse.vtk.org/u/lassoan)\
**Post date:** [June 2, 2023, 7:27pm UTC](https://discourse.vtk.org/t/replace-vtkdistancepolydatafilter-with-vtkdisplacementpolydatafilter/11599/7 "2023-06-02T19:27:57Z")

</div>

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](https://github.com/NIRALUser/3DMetricTools/tree/master/ModelToModelDistance) 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

---

<div class="post-metadata">

**Author:** ![Jens\_Munk\_Hansen](https://discourse.vtk.org/user_avatar/discourse.vtk.org/jens_munk_hansen/32/1215_2.png) [@Jens\_Munk\_Hansen](https://discourse.vtk.org/u/Jens_Munk_Hansen)\
**Post date:** [June 4, 2023, 11:41am UTC](https://discourse.vtk.org/t/replace-vtkdistancepolydatafilter-with-vtkdisplacementpolydatafilter/11599/8 "2023-06-04T11:41:33Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Jens\_Munk\_Hansen](https://discourse.vtk.org/user_avatar/discourse.vtk.org/jens_munk_hansen/32/1215_2.png) [@Jens\_Munk\_Hansen](https://discourse.vtk.org/u/Jens_Munk_Hansen)\
**Post date:** [June 4, 2023, 2:59pm UTC](https://discourse.vtk.org/t/replace-vtkdistancepolydatafilter-with-vtkdisplacementpolydatafilter/11599/9 "2023-06-04T14:59:44Z")

</div>

There is merge request awaiting approval.

[https://gitlab.kitware.com/vtk/vtk/-/merge\_requests/10252](https://gitlab.kitware.com/vtk/vtk/-/merge_requests/10252)

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](https://github.com/NIRALUser/3DMetricTools/tree/master/ModelToModelDistance) has modified the filter.

---

<div class="post-metadata">

**Author:** ![Jens\_Munk\_Hansen](https://discourse.vtk.org/user_avatar/discourse.vtk.org/jens_munk_hansen/32/1215_2.png) [@Jens\_Munk\_Hansen](https://discourse.vtk.org/u/Jens_Munk_Hansen)\
**Post date:** [June 11, 2023, 3:15pm UTC](https://discourse.vtk.org/t/replace-vtkdistancepolydatafilter-with-vtkdisplacementpolydatafilter/11599/10 "2023-06-11T15:15:25Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![lassoan](https://discourse.vtk.org/user_avatar/discourse.vtk.org/lassoan/32/50_2.png) [@lassoan](https://discourse.vtk.org/u/lassoan)\
**Post date:** [June 11, 2023, 3:44pm UTC](https://discourse.vtk.org/t/replace-vtkdistancepolydatafilter-with-vtkdisplacementpolydatafilter/11599/11 "2023-06-11T15:44:45Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Jens\_Munk\_Hansen](https://discourse.vtk.org/user_avatar/discourse.vtk.org/jens_munk_hansen/32/1215_2.png) [@Jens\_Munk\_Hansen](https://discourse.vtk.org/u/Jens_Munk_Hansen)\
**Post date:** [June 11, 2023, 10:24pm UTC](https://discourse.vtk.org/t/replace-vtkdistancepolydatafilter-with-vtkdisplacementpolydatafilter/11599/12 "2023-06-11T22:24:26Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![lassoan](https://discourse.vtk.org/user_avatar/discourse.vtk.org/lassoan/32/50_2.png) [@lassoan](https://discourse.vtk.org/u/lassoan)\
**Post date:** [June 11, 2023, 10:51pm UTC](https://discourse.vtk.org/t/replace-vtkdistancepolydatafilter-with-vtkdisplacementpolydatafilter/11599/13 "2023-06-11T22:51:46Z")

</div>

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.