I have a set of e.g. 8 points. I know all distances between each points. Is there an algorithm to reconstruct the 3d coordinates of those points.
What you are try to do is called Trilateration. It might be wise to do a bit of research before you proceed, as it's tricky to get right. However, I'll start you off with the following.
The following should work, as long as you have the actual 3D distances. Problems may come up if you don't.
Take a point, p1, and assign it to be the origin, (0,0,0).
Take another point, p2, and place it at (distance(p1,p2),0,0)
Take another point, p3, and place it on the (x,y,0) plane based on it's distance from p1 and p2.
Take another point, p4, and place in 3D space, based on it's distance from p1, p2, p3.
Repeat step 4 until no points remain.
The first 3 steps are enough to orient and fix the coordinates.
Solving steps 3 and 4 can be done by making use of planar triangles, that form easily due to how the points are centered.
Let assume that points are in a general position. That no 3 points are on a same line, and no 4 points are on a same plane. It isn't a restriction, just to make algorithm simpler without checks for a special cases.
Intersection, if exists, of four spheres (in a general position) is a single point. It can be seen since intersection of two spheres is a circle, intersection of three spheres are 2 points, and if center of forth sphere isn't on a plane with centers of other 3 spheres, that sphere can pass only through one of intersection points.
So, if distances are valid, than shape can be created by incremental adding points to it.
Position on first 4 points defines orientation. E.g. first point set in origin, second point set on +X on given distance to first, third point set in XY plane in +Y direction on intersection of circles, and forth point set in +Z direction on intersection of 3 spheres.
Additional points can be positioned by intersection of 4 spheres with centers in first 4 points and radii given by distances to them.
An other possibility is the metric Multidimensionale Skalierung.
Related
I have a list of 8 points given by their coordinates (x, y, z).
These 8 points are the 8 vertices of an hexahedron, which means that there are 6 faces which are quadrilaterals; the 4 points on each face are guaranteed to be coplanar.
I want to sort the list of points in a particular order:
the first 4 points must be on the same face, and in counterclockwise order;
the next 4 points must be their corresponding points on the opposite face.
Example:
I found similar question asked, but this algorithm fails on this example hexahedron:
I also have an idea to sort points in direct way by finding points in the same plane, then the other point in this plane, then point on same edge and etc.
But is there any easier way to order these points?
I have a set of non-intersecting spheres with known centers and radii, and I want to find the maximum sphere in the gap between these spheres.
Currently my approach is a 'nudge-and-bulge' method in which I pick on a point P in the void near the center of all the spheres, and I find the largest ball with its center at P. I then let the ball center walk randomly with small steps from P to a new position P' and check if the ball at P' with the old radius intersects with other spheres, if no intersection exists the sphere grows until it hits one sphere, else the center walks again, and repeat.
This approach is quite time-consuming, and I wonder if there is a better way to address the problem. I have searched online and the only relevant discussions are about finding maximum inscribed circle/sphere in between points/polygon/polyhedron.
If the sphere can't be made bigger by your 'nudge and budge' method, then it must be tangent to at least 4 other spheres.
Given 4 spheres, there is only one sphere that is tangent to all of them. (the position and radius are 4 unknowns, determined by the 4 distance equations to the given spheres)
So try all combinations of 4 spheres. For each combination, find the tangent sphere and see if it intersects any other ones.
That's idea that breaks your problem into a finite number of possibilities. The simple algorithm takes O(n^5), which is still a long time, though, if you have a lot of spheres. You can use the 3D Voronoi diagram to greatly accelerate this as #YvesDaoust suggests.
I have a list of coordinates (latitude, longitude) that define a polygon. Its edges are created by connecting two points with the arc that is the shortest path between those points.
My problem is to determine whether another point (let's call it U) lays in or out of the polygon. I've been searching web for hours looking for an algorithm that will be complete and won't have any flaws. Here's what I want my algorithm to support and what to accept (in terms of possible weaknesses):
The Earth may be treated as a perfect sphere (from what I've read it results in 0.3% precision loss that I'm fine with).
It must correctly handle polygons that cross International Date Line.
It must correctly handle polygons that span over the North Pole and South Pole.
I've decided to implement the following approach (as a modification of ray casting algorithm that works for 2D scenario).
I want to pick the point S (latitude, longitude) that is outside of the polygon.
For each pair of vertices that define a single edge, I want to calculate the great circle (let's call it G).
I want to calculate the great circle for pair of points S and U.
For each great circle defined in point 2, I want to calculate whether this great circle intersects with G. If so, I'll check if the intersection point lays on the edge of the polygon.
I will count how many intersections there are, and based on that (even/odd) I'll decide if point U is inside/outside of the polygon.
I know how to implement the calculations from points 2 to 5, but I don't have a clue how to pick a starting point S. It's not that obvious as on 2D plane, since I can't just pick a point that is to the left of the leftmost point.
Any ideas on how can I pick this point (S) and if my approach makes sense and is optimal?
Thanks for any input!
If your polygons are local, you can just take the plane tangent to the earth sphere at the point B, and then calculate the projection of the polygon vertices on that plane, so that the problem becomes reduced to a 2D one.
This method introduces a small error as you are approximating the spherical arcs with straight lines in the projection. If your polygons are small it would probably be insignificant, otherwise, you can add intermediate points along the arcs when doing the projection.
You should also take into account the polygons on the antipodes of B, but those could be discarded taking into account the polygons orientation, or checking the distance between B and some polygon vertex.
Finally, if you have to query too many points for that, you may like to pick some fixed projection planes (for instance, those forming an octahedron wrapping the sphere) and precalculate the projection of the polygons on then. You could even create some 2d indexing structure as a quadtree for every one in order to speed up the lookup.
The biggest issue is to define what we mean by 'inside the polygon'.
On a sphere, every polygon (as long as the lines are not intersecting) defines two regions of the sphere. Both regions are equally qualified to be called the inside of the polygon.
Consider a simple, 1-meter on a side, yellow square around the south pole.
You can think of the yellow area to be the inside of the square OR you can think of the square enclosing everything north of each line (the rest of the earth).
So, technically, any point on the sphere 'validly' inside the polygon.
The only way to disambiguate is to select which side of the polygon you want. For example, define the interior to always be the area to the right of each edge.
I have a volume mesh which is actually a tetrahedral mesh. I would like to calculate the cross-section of this mesh given a plane function, saying z = 0. I can imagine that the cross section of a tetrahedron is either a triangle or a quadrilateral. For the first case, triangle, once I calculate the 3 cross points I can get it; but for the second case, how can I make the quadrilateral become 2 triangles? My problem is I cannot determine the diagonal of the quadrilateral.
Intersect all tetrahedron edges by the plane. You will get 3 or 4 intersection points.
If 3 points then a single triangle.
If 4 points, they form a convex quadrilateral. Take any 3 points, that form a first triangle. The other triangle if formed of the fourth point and the two endpoints of the edge that has this point to its right.
Alternatively (for a more general solution), tag the intersection points with the indexes of the faces incident on the edge, and reconstruct the ring of labels.
Ex: edges are common to faces AB, CD, DA and BC; then the section is ABCD.
This answer outlines a general volume-plane intersection algorithm. It will return the vertices of the intersection in order, so it's easy to determine the diagonal of your quadrilateral.
I have an application that creates an approximation to sphere by subdividing an icosahedron. The Cartesian vertex coordinates are converted to spherical coordinates so that all vertices sit on the surface of a unit sphere.
What I need to do next is find the nearest vertex to an arbitrary point on the surface of the sphere. I have come up with two simple algorithms...
Brute force search - will be OK for a small number of vertices, but will be excessive for finer subdivisions.
Sorted / Indexed search - sort the vertices into some form of order by azimuth and inclination and then create a rough index to speed up a brute force search by limiting its scope.
I was wondering if there was a more subtle, and hopefully higher performing algorithm that I can use instead of one of the two above.
Update 1: I have just recalled that for another part of the application the vertices store information about their neighbours. My new algorithm is
Pick an arbitrary start vertex. Find which of its neighbours has a smaller distance to the point to locate. Use this neighbour as the new start vertex. Repeat until none of the vertex's neighbours has a smaller distance to the point. This vertex is the closest to the point.
Scanning through the responses, I think I may be off base, but what you're after is simple. I think.
Since you're dealing with just points that sit on the sphere, you can just drop a line from the vertex to the center of the sphere, drop another line from the arbitrary point to the center and solve for the angle created between them. Smaller is better. The easiest and cheapest way I think would be the dot product. The angle basically falls out of it. Here's a link about it: http://www.kynd.info/library/mathandphysics/dotProduct_01/
For testing them, I would suggest picking a vertex, testing it, then testing its neighbors. It SHOULD always be in the direction of the smallest neighbor (angle should always decrease as you get closer to the vertex you're after)
Anyhow, I hope that's what you're after.
Oh, and I came across this page while looking for your subdivision algorithm. Hard to find; if you could post a link to it I think it would help out a lot more than just myself.
One of possible solutions is to build BSP tree for vertices: http://en.wikipedia.org/wiki/Binary_space_partitioning
If the icosahedron has one vertex at the north pole and the opposite vertex at the south pole then there are 2 groups each of 5 vertices which are in planes parallel to the equator. With a little geometry I figure that these planes are at N/S 57.3056° (decimals, not dd.mmss). This divides your icosahedron into 4 latitude zones;
anything north (south) of 28.6528° is closest to the vertex at the nearer pole;
anything between the equator and north (south) 28.6528° is closer to one of the 5 vertices in that zone.
I'm working this as a navigator would, arcs measured in degrees and denoted north and south; if you prefer a more mathematical convention you can translate this all to your version of spherical coordinates quite easily.
I suspect, though I haven't coded it, that checking the distance to 5 vertices and selecting the nearest will be quicker than more sophisticated approaches based on partitioning the surface of the sphere into the projections of the faces of the icosahedron, or projecting the points on the sphere back onto the icosahedron and working the problem in that coordinate system.
For example, the approach you suggest in your update 1 will require the computation of the distance to 6 vertices (the first, arbitrarily chosen one and its 5 neighbours) at least.
It doesn't matter (if you only want to know which vertex is nearest) whether you calculate distances in Cartesian or spherical coordinates. However, calculation in Cartesian coordinates avoids a lot of calls to trigonometric functions.
If, on the other hand, you haven't arranged your icosahedron with vertices at the poles of your sphere, well, you should have !