Prevent accuracy degradation of signed distance computation

[morinmorin]

Signed distance computation using fast winding number (i.e. (1.0 - 2.0 * winding_num) * udist) degrades accuracy, since fast winding number contains approximation errors. This PR replaces (1.0 - 2.0 * winding_num) with winding_num > 0.5 ? -1.0 : 1.0.

This PR also applies the above change to (non-fast) winding number for consistency with "pseudo-normal test" and patched "fast winding number".
[!NOTE] Numerical errors in (non-fast) winding number computation are very small in general, but in my random testing with double precision the largest winding number I got was 1.0000005.

Unit tests ran fine and I locally tested that "pseudo-normal test", "winding number" and "fast winding number" all give the same signed distance (if they give the same sign).

Checklist

• All changes meet libigl style-guidelines.
• Adds new .cpp file.
• Adds corresponding unit test.
• This is a minor change.

[alecjacobson]

Thanks.

Ideally we might expose this as an option. For really messy inputs, it's potentially useful to have (2*w-1)d as a function, since it's continuous across "holes" in the input mesh. In that case, it loses it's distance properties (‖∇d‖ = 1, but ‖∇ (2w-1)*d‖ is not necessarily =1). Nonetheless, I've found, e.g., it's a bit better when feeding into marching cubes for surface extraction.

[morinmorin]

Agreed. For "dirty" soupy triangles and point clouds, continuous signing might be a viable option. Adding a new signed distance type SIGNED_DISTANCE_TYPE_FAST_WINDING_NUMBER_DIRTY looks easy.