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.
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.
As I delve into SVG, I find myself trying to round corners in <path>s.
Contemplating web examples and looking at the answers to similar but more specific questions, I see that the most common ways to do so are using curves or arcs of some sort.
The idea behind arcs (A/a) seems pretty straight forward, but a blog post on how to figure out the maths was nowhere to be easily found or in not well-organized websites.
After seeing examples that use C/c I was pretty lost, and I couldn't find a well formatted and united blog post.
The world would be greatful if there was an SO answer with a few resources on nice posts for rounding edges or explaining the maths and implementation directly
The answer should assume:
no libraries (maybe as extra references, but not library-only answers)
paths with corners at non-orthogonal angles (non-90deg)
how it would be easier at certain specific angles/lengths
differences in efficiency between using arcs and curves (which one is best size-wise to use for what purpose and in what case)
generic examples (specific but not-hard-to-visualize values, out of 100 for example, are fine)
The answer can just list well-presented and introduced resources, and need to explain what is expected to find in the link along with a short description and summary
What maths are you trying to figure out?
Assuming you want "round" corners, meaning circular, then in most cases arcs will be what you want to use. And it has the advantage that there is normally no maths to figure out. You will have the start point of the arc (where the incoming path segment stopped). Then to add an arc, you just need to provide it with:
the radius of the curve you want
the rotation of the arc relative to the X axis. This will be 0 for circular arcs, and therefore for your case also.
the large arc flag. For every arc there will be two potential arcs: the shortest arc between the two points, or the "long way" around the circle
the sweep flag. This is the direction: clockwise or anti-clockwise
the end point of the arc
All pretty straightforward really. You may need some maths to work out where the end of the arc will be, but that's pretty much it.
The full explanation for all these parameters to the A command can be found in the Paths section of the SVG spec.
https://www.w3.org/TR/SVG/paths.html#PathDataEllipticalArcCommands
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.
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.