PoissonRecon generated surfaces are sometimes wrong when using -must-link constraints

[jewettaij]

Sometimes when you use PoissonRecon to generate a smooth, closed surface, you will get something completely strange that appears to have been turned inside out. This happens rarely, but when it does, it's baffling. The resulting pointcloud mesh file created by the "-normals-file" argument will seem fine. But when you run PoissonRecon, the results will be terrifying. When this happens, it is almost always because you are also using the "-must-link" argument.

Background information

Sometimes when you attempt to detect a surface using filter_mrc with the "-membrane" and "-connect" arguments, it will only be able to detect little fragments of the surface. Typically when this happens, the "-connect" argument will fail to link all of these little surface fragments together. The "-must-link" argument is used (together with "-connect") to help merge these little surface fragments into larger surfaces.

Why this happens

The PoissonRecon program needs to know outward direction of the surface at each visible point on the surface. The filter_mrc program can detect the membrane surface, as well as the direction of its surface normal. But, in the case of a closed surface, it cannot tell whether this direction is pointing outward or inward. (In other words, there is an ambiguity in the sign of the surface normal direction.) Sometimes two different surface fragments will be assigned (by filter_mrc) to orientations which are not compatible with each other.
(The direction of one surface fragment points inward, the other one outward.) This makes it impossible for to determine which voxels are inside the surface and which are outside. This is why PoissonRecon fails.
This is more likely to happen if the disconnected surfaces are not nearby, and/or if they are pointing in radically different directions. (For example, if you have two perpendicular surfaces that form a T-junction, it's not clear which side of each surface should be on the inside or outside.)

Workaround

Fortunately, there is a way for the user to manually specify the orientation of each surface fragment. It is explained in the next post...

[jewettaij]

Workaround (continued...)

When filter_mrc fails to infer the direction of each surface fragment automatically, the user can instead specify the surface fragment orientations manually. To do that, they can supply an extra number after the x,y,z coordinates on each line, which is "1" or "-1" (indicating the this surface fragment is pointing in the same or opposite direction relative to the previous surface fragment in the list, respectively). In the following example, the "-1" indicates that the two surfaces are constrained to point in opposite directions:

(141 83 62)
(123 133 64) -1

For a detailed explanation, see the documentation for the -must-link argument.