Alexandre,
I am interested in using (and possibly implementing) software for (constained) 3d tetrahedralization and so I was concerned when I saw your comment:
"3D delaunay (I assume you want tetrahedra, not that you're trying to fit a surface) is very very very very ill conditioned and almost impossible to get right robustly. Actually, the problem is less with the algorithm than with the typical data which is fed to it. – Alexandre C. Feb 4 '11 at 14:20"
Can you possibly elaborate on why you feel that 3d delaunay is so ill-conditioned? In particular, could you point me to a reference so that I can read on it myself?
Thanks,
Dan L.
The problem is that in the input points, there can easily be five points that are almost co-spherical, and for those points, the insphere predicate of the Delaunay triangulation is difficult to evaluate.
Actually, not so difficult. The following article Efficient Exact Geometric Predicates for Delaunay Triangulations explains how it is implemented in the 3D Delaunay triangulation of CGAL: the article explains how the predicates can be computed exactly, with filters that ensure the efficiency in non-degenerated cases.
Related
The detection of edges in 3d objects may be the first step for the automatic processing of particular characteristics and landmarks.
Thus, I'm looking for a method to identify such edges for some of my 3d-scanned objects.
However, with all my ideas (Hough transformation, angles threshold for neighboring vertices) I didn't succeed.
Thus, I'd be quite happy if someone could point me to a solution to the edge-finding-problem for 3d point clouds which can be applied using R.
There is a nice paper from last year about this topic.
Basically, you need to compute several features, for each point, based on it's neighbors.
I usually prefer Python over R so I'm not aware of any point-cloud processing package un R. But the implementation of that paper in R should be easy.
If you can translate Python-R, you can take a look at this library that I wrote as it has already implemented the computation of all the features mentioned on that paper.
If that helps you, in this answer you can find example code on how to add the curvature for each point. You just have to replace the word curvature with the other names of features.
Is there any easy algorithm to split a concave polygon in convex ones or represent a polygon by triangles. I know there is a Wikipedia entry on triangulation but this doesn't really help me. I know there already is a question on Stackoverflow, however this is not very helpful to me. I would appreciate any pseudocode (or real code in an understandable programming language) to break a concave polygon in convex ones or triangles. Btw, the algorithm should also work for convex polygons and not mess around with them.
Thanks for your help!
As proposed by the commenters, ear cutting (clipping) should be the most straight forward way to triangulate. To speed up the verifying process of an ear in practice one can employ a geometric grid.
To write robust and performant code, especially for geometric problems is very challenging. Why not use existing implementations like triangle or CGAL.
In order to use CGAL via python one could go for SWIG.
I want to triangulate a polygon (without selfintersection, but with holes and the polygon can also be concav).
In this question (e.g.):
Delaunay triangulating the 2d polygon with holes
a Constrained Delaunay Triangulation is proposed.
What I was wondering about: is this the best way to do so or is it like "using a sledge-hammer to crack a nut"? An alternativ would be to use an algorithm for creating a "normal" triangulation (eg splitting the polygon in y-monoton parts and triangulate these parts) and flipping the edges afterwards. But it seams that (nearly) nobody takes this solution. Is there a reason?
What are the pros and cons for one of these solutions?
(the polygons can have an arbitrary size)
There are a few reasons to prefer (constrained) Delaunay triangulations to other approaches:
In R^2 it can be proven that such a triangulation is the "best" way to triangulate a given geometry -- resulting in a triangulation that maximises the minimum angle. This is equivalent to producing triangles of optimal quality, without any "skinny" elements.
Forming the Delaunay triangulation is efficient (i.e. O(n*log(n)) in R^2).
Delaunay triangulation algorithms are robust and efficient in practice. A number of very high quality implementations exist, such as Triangle and CGAL.
Delaunay triangulations generalise to higher-dimensional problems (i.e. tetrahedrons in R^3 and general simplexes in R^d).
Delaunay triangulations induce an orthogonal dual complex (i.e. the Voronoi diagram). This can be important for certain classes of numerical methods.
Depending on what exactly you're looking to achieve, you might find one or more of these criteria persuasive. Other options, such as ear-clipping or monotone slab triangulation, can be competitive in some areas, but don't, IMO, exhibit the same kind of overall performance.
You can try alpha shapes. It is defined as a delaunay triangulation without edges exceeding alpha.
I'd like to draw the 3-simplex which encloses some random points in 3D. So for example:
pts <- rnorm(30)
pts <- matrix(pts, ncol = 3)
With these points, I'd like to compute the vertices of the 3-simplex (irregular tetrahedron) that just encloses these points. Can someone suggest a package/function that will do this? All manner of searching for simplex-related material is dominated by answers that relate to using simplices for other purposes, of which there are many. I just want to compute one and draw it. Seems simple, but I don't seem to know the relevant keywords for what I need.
If nobody can find a suitable package for this, you'll have to settle for doing it yourself, which isn't so difficult if you don't require it to be the absolute tightest fit. See this question over at mathexchange.
The simplest approach presented in this question seems to me to be translating the origin so that all points lie in the positive orthant (i.e, all point dimensions are positive) and then projecting the points to lie within the simplex denoted by each unit vector. To get this simplex in your original coordinate system you can take the inverse projection and inverse translation of the points in this simplex.
Another approach suggested there is to find the enveloping sphere (which you can for instance use Ritter's algorithm for), and then find an enveloping simplex of the sphere, which might be an easier task depending what you are most comfortable with.
I think you're looking for convhulln in the geometry package, but I'm no expert, so maybe that isn't quite what you are looking for.
Am following this tutorial for my 2d game collision handling , this tutorial explains about the collision used in one of my favorite game "N". How they used separate axis theorem more efficiently for collision between AABB vs AABB and AABB vs Circle. http://www.metanetsoftware.com/technique/tutorialA.html. I understand the implementation of AABB vs AABB collision handling but I couldn't understand AABB vs Circle collision detection especially voronoi regions.Totally confused how/where to start.
AABB vs AABB collision detection
Find the axis along all the edge by finding the normal of each edge.
Projection all the vertices to the
resultant Axis , final result should
be a scalar value.
The resultant scalar value in turn
is used to find whether collision is
present or not.
Can someone please explain how to handle collision AABB vc Circle - vise versa?
Since collisions with a circle always come down to a comparison against the radius (in your case, via projection), having the closest line segment (edge of the polygon) and the normal vector are the only building blocks you need. The normal vector is easily computed from the points of the line segment (something like unit(y2-y1, x1-x2) ... the negative reciprocal of the slope). Figuring out which edge is closest is the building block that remains. Voronoi regions give us the last building block.
You understand collisions between axis-aligned bounding boxes. I assume you also understand collisions between two circles. I'm assuming you don't understand voronoi regions. So, where to start? Voronoi diagrams. I highly suggest that you find a diagrammed explanation. This link is quite good. However, depending on how lost you are, perhaps a little additional background (seriously, though, no explanation can beat the visual):
A voronoi diagram is one of the ubiquitous data structures of computational geometry. Any computational geometry book will discuss the Voronoi diagram. It answers a simple question: where is the closest post office? Given a set of points in a plane (post offices), a voronoi diagram separates the plane into different regions, each containing one of the points. If you are in a particular region, you know which point (post office) is closest to you. If you were a circle, this would be nice for collision detection for a simple reason: the closest point is the most important one to test for collisions.
Note that if you want to mathematically derive a voronoi diagram, you simply consider all point pairs and calculate all bisecting lines. Then you intersect all of the bisecting lines and throw away the segments that are unimportant because some other point is closer to the point of interest (which happens at every intersection). This leads to a terribly inefficient algorithm, though. The efficient implementation involves another ubiquitous thing in computational geometry: the line-sweep algorithm. Its details can be found elsewhere; the important bit is that it provides a method of considering only the important points at any stage of the algorithm.
The voronoi regions in your tutorial are a little more complex. Instead of just points, we have line segments. Fortunately, the line-sweep algorithm handles this nicely. You mostly have to worry about the start or end of the line segments. Conceptually, not much changes once you have the basic algorithm down. Again, this is exceptionally helpful for collision detection with a circle: given the voronoi region, you know which line segment to test collisions against.
Does that even help? Feedback appreciated. I'll be happy to clarify anything. Explaining voronoi diagrams without visuals is probably a bad idea.