XbimEssentials
XbimEssentials copied to clipboard
xBimTeam
Improvements to XbimTessellator
I've got the same trouble as mentioned in xBimTeam/XbimGeometry#96. So I've started to investigate the problem and found the reason. The former orientation alignment / reverse algorithm wasn't stable for all types of bodies (especially with concave shapes near the boundaries).
Improves the tessellation and especially the orientation alignment algorithm of the triangulations. It now computes the approximated tetrahedral volume and reverse the mesh orientation, if the volume is negative. It also refactors the implementation. It also adds a volume value to the shape data holder for validation purpose. Will also require a PR on geometry side.
Here's some more context of the change:
First, sorry for this heavy PR! The previous logic of normal's alignment was based on an "extreme" triangle near the boundary. For non-convex bodies (and other abitrary, too), this doesn't work in some cases. So the change adopted a (to my opinion only) stable detection of inverted closed meshes by computing the tetrahedral volume. If it's negative, the algorithm simply inverts the value and reverses the orientation of all triangles. In prior the orientation of all triangles is aligned by an abitrary initial triangle.
Additionally, a flag is delivered to propagate issues easily. If an already triangulated face set is marked as closed, orientation alignment and reverse-orientation-detection is done, too. If not, the mesh is wrapped as it is (since alignment of intentionally non-closed meshes makes no sense).
There's also a nullable volume flag shipped with this PR. If null, the geometry engine (OCC) isn't able to close the body geometrically. If it holds some value, it's the volume in model units. For sets, two values exist. A nullable wich is handled the same way: if there's an unclosed body in the collection, nullify the whole volume. The other flag named "VolumeValid" will only return the volume of closed volumes (and therefore might be only a portion of the "real" volume).
This merge needs to be aligned with PR in geometry engine. @SteveLockley, can you handle both?
