-
Notifications
You must be signed in to change notification settings - Fork 54
Valid Solid shells cannot be converted to CGAL polyhedra #225
Comments
Here's an example of another shape which can be an algorithm output (you could generate this one with a couple of simple unions or differences) which exhibits the same problem. Note that in this case, unlike the first, the shape is detected as "invalid" because the self-intersection is along a line rather than a point and so is detected by algorithm::selfIntersects3D.
I'm currently testing an algorithm which is able to resolve the original problem for both these shapes. However, it now appears that algorithm::selfIntersects3D is also a problem area. It is unable to detect self-intersections formed by two triangle fan shapes sharing a central vertex, as in the original example. Also, arguably, it should not be used in the validity algorithm for surfaces, because correct functioning of the boolean algorithms can produce Solids with shells that self-intersect at a point or a line, even though their interiors do not overlap. Surface validity should possibly depend on detecting self-penetrations rather than self-intersections. |
@DRC1Spatial Hi, thanks for your detailed report. I honestly need some time to digest it, visualise your examples and understand what is the problem. |
@DRC1Spatial Thanks, however the attached images do not seem to be visible. Edit: received your images by email, pasted them into your last comment |
If you have a non-manifold vertex in your input, Boolean operations for example will not be possible. So even if non-manifold can be represented in a Polyhedron, you won't be able to do something with it. You wrote Many valid Solids contain "pinched" or self-touching shells but who says that they are valid? The norm or a function? |
algorithm::isValid. If you run it on the given Solid, you'll see what I mean. This in fact turns out to be a bug in selfIntersects3D - it won't detect opposing triangle fans that share a central vertex, because it allows point touches between non-neighbours. If not for that bug, it would probably detect the given shape as invalid. However, this is unfortunately a problem, because you can get such shapes as algorithm results. The third test case demonstrates this. When represented as CGAL polyhedra (as returned by the P_minus_Q operation), the shared vertex is duplicated so that a non-manifold point does not occur in the topology - the triangle fan on one side references one copy of the vertex, and the triangle fan on the other side references the other copy of the vertex (you can see this in the logging output from Import_volume_as_polyhedron that I have included). But as soon as the GeometrySet containing that polyhedron is recomposed, the information about the duplicated vertex is lost, and the next attempt to decompose the shape will result in an error. |
I did not initially think that algorithm::isValid was wrong, because this Solid can be produced by boolean operations, has a closed shell that does not self-penetrate, and no discontinuities in its interior. |
The SFS doesn't say much about volumes. |
Yes, to my knowledge, they have not yet published a version that extends to 3D, so there is no appropriate standard. But I think it's fair to say that if a shape can be produced by boolean operations from simple primitives, SFCGAL will need to support it. |
A polyhedron expects the surface it represents to be manifold but you can produce some non-manifold surfaces using Boolean operations and you would need a |
Quite a lot of GIS data represents non-physical things - e.g. electoral districts. A Solid might refer to a volume of space enclosed by a non-physical boundary, rather than an actual solid object, and could therefore have a non-manifold boundary, could it not? |
I'm just saying that it is not possible to have this feature with the current data structure and I'm proposing a workaround. If you want the "general case", then you have to use Nef polyhedra and pay the overhead price. |
This is not correct in all cases - you can see from my original example that a normal CGAL polyhedron can describe such surfaces, by careful use of duplicated vertices. What I don't know is whether CGAL can do this in the general case.
Yes, that's true - that's the bug that I was trying to alert you to. Even if there is a workaround by denying that such surfaces can be valid Solid shells, the library perhaps needs to deal more gracefully with what happens when they occur as a result of boolean operations. |
The way the function in CGAL is supposed to work is to return |
A question that I'm interested in knowing the answer to is this: As shown in the example, there are at least some cases involving non-manifold vertices and/or edges which the halfedge structure can represent by duplicating vertices without losing any important information. So, when you take two valid polyhedra and do a P_minus_Q operation to get the difference, and the resulting shape happens to have non-manifold points, the underlying algorithm can sometimes give a result back that can then be assembled into a closed surface. My original test case demonstrates this. But can it do this in all cases? Or, is there a family of valid input polyhedra and boolean operations on those polyhedra such that non-manifold points in the result cannot be "hidden" by duplicating vertices (or possibly where they could, but the algorithm cannot reliably discover how to do it)? Another way to ask the same question is this. If you take a closed TriangulatedSurface that self-touches as in the examples, decompose the enclosed volume into tetrahedrons, then union the set of resulting tetrahedrons together, will this always succeed and return a halfedge structure from which the original TriangulatedSurface can be recovered? |
There are 2 notions to understand: the underlying graph (vertices/edges/faces) and the geometry (coordinates of the points). We say that a vertex is non-manifold if the volume is pinched and if the vertex is the same entity in the graph. If you duplicate the vertex (to resolve the manifoldness issue in the graph) then you have what is called a self-intersection. The problem with self-intersections is that the Bool op code cannot compute anything as soon as there is such a situation. In general the geometry has to be modified to resolve the self-intersection first. |
Many valid Solids contain "pinched" or self-touching shells where the existing algorithm to convert a TriangulatedSurface to a CGAL polyhedron produces a non-manifold point. Since CGAL's combinatorial maps cannot represent non-manifold points, this causes construction to fail.
These problem geometries can easily be produced as algorithm results; the corefinement code will solve this by duplicating the pinch vertices so as to hide the pinch from the combinatorial map. Once recomposed, these Geometries cannot be decomposed again without triggering the problem.
Here are three test cases which demonstrate the problem. The problem geometry is the same in all tests; in the third test it is produced from inputs to difference3D, but the same geometry can be produced directly from WKT, as demonstrated in the first two tests.
The text was updated successfully, but these errors were encountered: