I'm considering to use the library CGAL for the calculation of the No-Fit Polygon (NFP). I've seen that the package of 2D Minkowski Sums in CGAL is a great tool for this. However, I would need to compute the NFP for very different types of polygons, and I'm not sure whether CGAL is going to cover my needs when polygons include holes. My doubts are motivated by the following statement found in their documentation website, in the Chapter 2D Minkowski Sums:
"(...)Applications of some of the operations in this package are restricted to polygons that do not contain holes. (Resulting sums may contain holes though.)"
Does anyone know which are those operations that are restricted to polygons without holes? Beyond that, I would appreciate any piece of advice from anybody who used CGAL to calculate the NFP for non-convex polygons. Thanks a lot.
As of release 4.9 of CGAL the "2D Minkowski Sum" package supports the construction of Minkowski sums of polygons with holes. This construction can be done with either the convex decomposition or the reduced-convolution methods. The latter is the default and the most efficient in most cases. We have retained all older methods, because they do exhibit better performance in some less frequent cases. You shouldn't have any problem computing the NFP of polygons with holes using the package.
Related
Does opencv feature the capability of extracting concave hulls/contours from a set of 2D points?
Also, is there a possibility to extract all possible hulls satisfying a certain criterion; let say all hulls must have their areas bounded (min<area<max) ?
I would look at the excellent Point Cloud Library which (by its very nature) has to handle concave hulls in both 2D and 3D. As a library, it can integrate quite nicely with OpenCV (if that's what you need).
In particular, this example which show-cases the pcl::ConcaveHull class. The cropHull operation might prove useful, in response to your second question.
(Notice that in fact this is actually underpinned by the "grand-daddy" of hull libraries - qhull).
I have spent time looking for information on the best algorithm to create a nesting of irregular polygons in 2D using manual and automatic positioning. I need to use such an algorithm in the context of CAD/CAM software. Here are the real possibilities I've found so far:
Separating Axis Theorem: is a fairly quick and simple algorithm to implement, but the drawback I find with it is that it only works with convex polygons. To work with concave polygons, a convex decomposition would need to be done first. This implies an increase in the run-time and the implementation of a new algorithm that decomposes the concave polygon into convex polygons.
Nesting by a power function: calculating the partial derivatives in the X and Y axes, you could get the escape direction you should take a polygon so that there is a collision between the two polygons. This function of energy and I tested and the three major problems that I have encountered are: first obtaining local minima , second nesting when the collision occurs over a piece and finally the execution time is very high.
Using no-fit polygon: use the no-fit polygon to the nesting can be somewhat interesting. I have read several papers on the subject although there are very few online documentation on it. Not sure if it can really be a useful choice. I still have several doubts on the details of this approach.
Any idea which of these algorithms to choose? Or if you know any other options that can be used? I'm a little confused :-) .
Thank you very much.
I need an algorithm to re-triangulate a given 3D solid object.
Input: A triangular mesh
Output: A new triangular mesh where the triangles - as far as possible - have equal edge lengths. Some tolerance is allowed.
Currently I reflect on a clustering algorithm in order to distribute points
equally over the surface. Then I could use a 2D Delaunay triangulation and
project the triangles to the surface. But this is just a vague idea, not an
algorithm. It would be great if somebody could suggest an algorithm or a
reference to related scientific work.
CGAL provides a surface meshing algorithm that can be used for remeshing.
The documentation page is here.
You can directly try it in the demo. On windows precompiled demo is available here. You'll also need the following dll's.
References to scientific publications are available on the aforementioned page.
I have successfully implemented the marching cubes algorithm. I used the standard materials as a reference, but I rewrote it entirely from scratch. It works, but I am observing the ambiguities that lead to holes in the mesh.
I was considering the marching tetrahedrons algorithm, which supposedly does not suffer from ambiguities. I fail to see how this is possible.
The marching tetrahedrons algorithm uses six tetrahedrons in place of a cube, with triangulations for each tetrahedron. But, suppose I were to implement the marching cubes algorithm, but for each of the 256 triangulations, simply choose the one that is the "sum" (union) of the cube's tetrahedron's triangulations? As far as I know, this is what marching tetrahedrons does--so why does that magically fix the ambiguities?
There are 16 unique cases, I think, and the 240 others are just reflections/rotations of those 16. I remember reading in some paper somewhere that to resolve ambiguities, you need 33 cases. Could this be related to why marching tetrahedons somehow doesn't suffer from problems?
So, questions:
Why does marching tetrahedrons not suffer from ambiguities?
If it doesn't, why don't people just use the marching cubes algorithm, but with the tetrahedrons' triangulations instead?
I feel like I'm missing something here. Thanks.
Okay, well I've just finished implementing my version of marching tetrahedrons, and while I easily saw ambiguities lead to problems in the marching cubes's mesh, the marching tetrahedrons's mesh seems to be consistently topologically correct. There are some annoying features along very thin points where some vertices can't quite decide which side of the divide they want to be on, but the mesh is always watertight.
In answer to my questions:
To resolve ambiguities in the marching cubes algorithm, as far as I can tell, one evaluates the function more carefully in the cell. In the tetrahedrons algorithm, one explicitly samples the center of the cell and polygonizes to that. I suspect that because the tetrahedral mesh includes this vertex in particular, ambiguities are implicitly handled. The other extra vertices on the side probably also have something to do with it. As a key point, the function is actually being sampled in more places when you go to refine it.
I'm pretty sure they do. My marching tetrahedrons algorithm does just that, and I think that, internally, it's doing the same thing as the classic marching tetrahedrons algorithm. In my implementation, the tetrahedrons' triangles are all listed for each possible cube, which I suspect makes it faster than figuring out the one or two triangles for each individual tetrahedron individually.
If I had the time and attention span (neither of which I do), it might be beneficial to remesh the insides of each cube to use fewer triangles maximum, which I think wouldn't hurt it.
To answer the question "Why does Marching Tetrahedrons algo has ambiguities?" it is required to understand why do the ambiguities arise in the first place in Marching Cubes.
Ambiguities may occur when there are two diagonally opposite "positive" vertices and two diagonally opposite "negative" vertices in a cube. It took me some time to wrap my mind around it, but the problem with ambiguities is that they theoretically allow to create isosurface patches for adjacent cubes that are incompatible with one another. That's the obvious part. The interesting part is that two adjacent isosurface patches from two ambiguous configurations are incompatible if (and only if) one of them separates "negative" vertices, and the other one separates "positive" verticies.
Here is a relevant quote from Rephael Wenger's great book "Isosurfaces Geometry, Topology & Algorithms" (can't post more then 2 links, so I've merged all relevant images from the book into a single one):
The border of a cube’s three-dimensional isosurface patch defines an
isocontour on each of the cube’s square facets. If some configuration’s
isosurface patch separates the negative vertices on the facet while an
adjacent configuration’s isosurface patch separates the positive ones,
then the isosurface edges on the common facet will not align. The
isosurface patches in Figure 2.16 do not separate the positive
vertices on any facet. Moreover, the derived isosurface surface
patches in any rotation or reflection of the configurations also do not
separate positive vertices on any facet. Thus the isosurface patches
in any two adjacent cubes are properly aligned on their boundaries. An
equally valid, but combinatorially distinct, isosurface table could be
generated by using isosurface patches that do not separate the
negative vertices on any square facet.
What this means is that if all used ambiguous configurations follow the same pattern (i.e. always separate "negative" vertices), then it is impossible to produce a topologically incorrect surface. And problems will arise if you use configurations "from both worlds" for a single isosurface.
The surface that was constructed using the same ambiguity resolution pattern still may contain unwanted errors like this (taken from "Efficient implementation of Marching Cubes’ cases with topological guarantees" article by Thomas Lewiner Helio Lopes, Antonio Wilson Vieira and Geovan Tavares), but it will be, as you said, watertight.
To achieve this, you will need to use the look-up table based on the 22 unique configurations (not the standard 14 or 15) shown in the Figure 2.16.
Now, back to the original question at last - why does Marching Tetrahedrons does not suffer from ambiguities? For the same reason there will be no ambiguities in the Marching Cubes, if done as described above - because you arbitrarily chose to use one of the two available variants of ambiguous configuration resolution. In Marching Cubes it is not obvious at all (at least for me, had to do a lot of digging) that this is even an option, but in Marching Tetrahedrons it is done for you by the algorithm itself. Here is another quote from Rephael Wenger's book:
The regular grid cubes have ambiguous configurations while the
tetrahedral decomposition does not. What happened to the ambiguous
configurations? These configurations are resolved by the choice of
triangulation. For instance, in Figure 2.31, the first triangulation
gives an isosurface patch with two components corresponding to 2B-II
in Figure 2.22 while the second gives an isosurface patch with one
component corresponding to 2B-I.
Note how cubes are sliced into tetrahedrons in two different ways in Figure 2.31. The choice of this slicing or the other is the secret sauce that resolves the ambiguities.
One may ask himself - if the ambiguity problem can be resolved just by using the same pattern for all cubes then why are there so much books and papers about more complicated solutions? Why do I need Asymptotic Decider and all that stuff? As far as I can tell, it all comes down to what you need to achieve. If topological correctness (as in, no holes) is enough for you, then you do not need all the advanced stuff. If you want to resolve problems like those shown in "Efficient implementation of Marching Cubes" article shown above, then you need to dive deeper.
I highly recommend reading the relevant chapters of Rephael Wenger's book "Isosurfaces Geometry, Topology & Algorithms" to better understand the nature of these algorithms, what are the problems, where do the problems come from and how can they be solved.
As was pointed out by Li Xiaosheng, the basics can be better understood by carefully examining the Marching Squares algo first. Actually, the whole answer was layed down by Li Xiaosheng, I've just expanded the explanations a bit.
Take the following 2d example (which introduces ambiguities):
01
10
If we divide this square into two triangles, we will get different results in the diagonal we chose to divide the square.
Along 0-0 diagonal, we get triangles (010,010) while for the 1-1 diagonal, we get triangles (101,101). Obviously, different decomposition of square lead to different results. Either is correct and this is same for 3D Cubes.
MT doesnot resolve the ambiguities actually but it can produce topologically consist result by choosing the same decomposition strategy for all cubes. That the way it get rid of suffering from ambiguities.
I'm looking for a library or a paper that describes how to determine if one triangular mesh intersects another.
Interestingly I am coming up empty. If there is some way to do it in CGAL, it is eluding me.
It seems like it clearly should be possible, because triangle intersection is possible and because each mesh contains a finite number of triangles. But I assume there must be a better way to do it than the obvious O(n*m) approach where one mesh has n triangles and the other has m triangles.
The way we usually do it using CGAL is with CGAL::box_intersection_d.
You can make it by mixing this example with this one.
EDIT:
Since CGAL 4.12 there is now the function CGAL::Polygon_mesh_processing::do_intersect().
The book Real-Time Collision Detection has some good suggestions for implementing such algorithms. The basic approach is to use spatial partitioning or bounding volumes to reduce the number of tri-tri intersection tests that you need to perform.
There are a number of good academic packages that address this problem including the Proximity Query Package, and the other work of the GAMMA research group at University of North Carolina, SWIFT, I-COLLIDE, and RAPID are all well known. Check that the licenses on these libraries are acceptable.
The Open Dynamics Engine (ODE), is a physics engine that contains optimized implementations of a large number of intersection primitives. You can check out the documentation for the triangle-triangle intersection test on their wiki.
While it isn't exactly what you're looking for, I believe that this is also possible with CGAL - Tree of Triangles, for Intersection and Distance Queries
I think the search term you are missing is overlay. For example, here is a web page on Surface Mesh Overlay. That site has a short bibliography, all by the same authors.
Here is another paper on the topic: "Overlay mesh construction using interleaved spanning trees,"
INFOCOM 2004: Twenty-third Annual Joint Conference of the IEEE Computer and Communications Societies.
See also the GIS SE question, "Performing Overlay of Two Triangulated Irregular Networks (TIN)."
To add to the other answers, there are also techniques involving the 3D Minkowski sum of convex polyhedra - concave polyhedra can be decomposed into convex parts. Check out this.
In libigl, we wrap up cgal's CGAL::box_intersection_dto intersect a mesh with vertices V and faces F with another mesh with vertices U and faces G, storing pairs of intersecting facets as rows in IF:
igl::intersect_other(V,F,U,G,false,IF);
This will ignore self-intersections. For completeness, I'll mention that we also support self-intersections in a separate function:
igl::self_intersect(V,F,...,IF);
One of the approaches is to construct a bounding volume hierarchy BVH (e.g. AABB-tree) for each mesh.
Then one will need to find whether there is a pair of intersecting triangles from two meshes, and it will be much faster (at best logarithmic time complexity) using constructed hierarchies than checking every possible pair of triangles from two meshes.
For example, you can look at open-source library MeshLib where this algorithm is implemented in findCollidingTriangles function, which must be called with firstIntersectionOnly=true argument to find just the fact of collision instead of all colliding triangle pairs.