vtkSurfaceNets3D: Order of BoundaryLabels do not seem to reflect direction of triangle normals

Support
1

Hi list,

when using vtkSurfaceNets3D recently I have discovered that the BoundaryLabels Scalars correctly include the two numeric labels for the inside/outside areas of the input image, but their order does not seem to match the normals of the generated triangles.

For example, given labels 1 and 2, in the generated mesh surface, a few triangles seem to have normals that point to 1, while most others point to 2, even though the order of the BoundaryLabels for these triangles is constant and always shows e.g. “1 2” but not “2 1” for the triangles with normals that show in the opposite direction.

Is there any chance that this can be easily included/fixed? Obviously it would even be better if all normals of a mesh separating two structures only (no more junctions) would always point into the same direction such that the boundary label order indeed can stay the same for all related triangles.

If this is not easily possible then I would think one has to loop over each generated triangle, make a small step into the normal direction, inspect the underlying voxel of the input image and correct manually.

Any hints are welcome.

Thanks,

sophonet

2

Yes, we are aware of this issue and plan to fix it soon. Thanks for your feedback, it’ll motivate us fix it sooner.

3

Hi,

since there has not been any update, I had a look myself at the source code earlier today, and it seems that SurfaceNets::WriteScalarTuple contains a few lines that changes the order of the label values such that background gets always written as a second value and otherwise s0 < s1. I have not found any reason for doing that, so it might be that the issue is caused by introducing some cosmetics to the output. I will check further and commit a pull request if that turns out to be indeed the reason.

Thanks,

Sophonet

4

Yes, please create an issue on gitlab. There are a couple of approaches to fixing this issue: 1) when the scalar 2-tuple (s0,s1) is reordered so that (s0<s1), the corresponding faces need to be reversed; or 2) give up on reordering (s0,s1), it’s not clear that such ordering is needed.

I should be able to get to this in August.