You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I see that with commit 14a66c766a0bf397300d55b39b7954c5f52895d0 the library now enhanches the support of conforming Delaunay triangulation , adding more point if needed.
It is not clear to me if the points will be added only if edges are overlapping/intersecting.
If it is not the case, I suggest to make this functionality optional.
This to allow a "relaxed" result that is conformant to the input data.
Sometime you simply need it, at the cost of a not fully conforming Delaunay triangulation.
Suppose to expect to obtain a closed solid out of tessellations, the flux is (more or less) the following
tessellate the common boundaries in 2d
create the area trimming loops out of common boundaries
tessellate the single area providing the obtained loops
obtain a 3d tessellation out of the 2d one
merge all 3d tessellation in a single mesh
If new points are added on boundaries, then the resulting solid will be opened: there will be an "empty" boundary at the edge where the "additional" point has been inserted.
To obtain a closed solid, if new points are added, then the user should re-process all surrounding areas inserting the additional points and re-tessellate from scratch.
This process must be recursive, because then the neighbor areas might need additional points, etc...
Making it optional will ensure that there are no failures.
The library is great (actually was, now) also because of its conformance to the input data.
The text was updated successfully, but these errors were encountered:
Behavior of insertEdges is the same as before. Conforming triangulations are obtained by using new conformToEdges method. When using conformToEdges new points are added at the edge center recursively until the edge is present in the triangulation as a sum of its parts (pieces).
Resolving intersections of constraint edges is disabled by default and will only be enabled when the user explicitly passes IntersectingConstraintEdges::Resolve to the constructor.
I see that with commit 14a66c766a0bf397300d55b39b7954c5f52895d0 the library now enhanches the support of conforming Delaunay triangulation , adding more point if needed.
It is not clear to me if the points will be added only if edges are overlapping/intersecting.
If it is not the case, I suggest to make this functionality optional.
This to allow a "relaxed" result that is conformant to the input data.
Sometime you simply need it, at the cost of a not fully conforming Delaunay triangulation.
Suppose to expect to obtain a closed solid out of tessellations, the flux is (more or less) the following
If new points are added on boundaries, then the resulting solid will be opened: there will be an "empty" boundary at the edge where the "additional" point has been inserted.
To obtain a closed solid, if new points are added, then the user should re-process all surrounding areas inserting the additional points and re-tessellate from scratch.
This process must be recursive, because then the neighbor areas might need additional points, etc...
Making it optional will ensure that there are no failures.
The library is great (actually was, now) also because of its conformance to the input data.
The text was updated successfully, but these errors were encountered: