flag to ignore error 204

[hugoledoux]

these are caused by vertices very close (like 0.001mm) to each others.

Temporary solution is to put planarity_n option to 180, but I'll add an option soon (in branch v2).

[hugoledoux]

@clausnagel I have been giving some thought at this today. I don't think it's possible to do, and that we actually want that. Let me explain. Assume we have the polygon there: http://val3dity.readthedocs.io/en/v2/errors/#non-planar-polygon-normals-deviation

If we ignore 204 then we might end up having val3dity crash because it's not possible to triangulate the top face: it gets projected to the xy-plane and thus you get duplicate points (triangulation is done by projecting to a plane). Also, if $c$ and $f$ are moved a bit to the right, when we project we get intersections of the edges. I could clean the polygon by removing the annoying vertices (with https://github.com/tudelft3d/prepair), but then what if val3dity returns VALID? It's not valid since without cleaning ops I wouldn't have been able to validate it... But within the planarity tolerance you give, it's a valid polygon.

[hugoledoux]

okay, I updated val3dity (branch v2) with the following behaviour. (it's now an option --ignore204 efbe24d)

A ring is self-intersecting (error 104) if its projection to the best-fitted plane (done with least-square) through the vertices of the polygon containing the ring has a self-intersection. This rule is there because if it is not possible to project the rings/polygons to a plane, then it is not possible to triangulate it (which is necessary, at least by val3dity, to validate 3D primitives).

If the rings of a polygon pass 203 (planarity with distance to fitted-plane) and have no self-intersection), then I can triangulate it (without modifying its geometry) and then 204 can be tested as before.

The default value of 204 is now 20degree, but can be changed.

option --ignore204 basically puts the planarity_n_tol to 180degree.