There are a set of points S in n dimensional space. I want to test a given point P is inside the region of S.
Since this is n dimensional space, points should form a polytope. Then the question is to determine whether a given point is inside the convex polytope.
I find this for 3-D polyhedrons but C++ libraries were not meaningful and I couldn't find their definitions. Besides it doesn't check the boundary conditions.
Another algorithm I found is for 2D polygons. I couldn't modify it since it is not clearly written. I can extend it of course but I'm not an expert in this domain so it's better to ask first.
Finally I found an algorithm for triangulation for concave polygon but I don't think it fits to my case.
Not sure what exactly you are asking, it seems you have several problems. First to compute Convex Hull of a point set. In 2d you can use BOOST or CGAL. For 3d CGAL. Not sure if they handle higher dimensions. For interior check, one way is (as the link you posted states) to check the ray intersection from the point of query to a known exterior point. The point of intersection of the ray (for interior point) should lie on a plane with normal pointing in the same direction as your ray. Meaning you are exiting the volume. A more efficient way would be to use something like a Binary Space Partitioning Tree (BSP). There are many links with tutorials on how that works.
From your description, you have established that S is convex. If that is the case you apply the hyperplane separation theorem (http://en.wikipedia.org/wiki/Hyperplane_separation_theorem)
Find the point Q in S that is closest to P.
Construct a hyperplane H that lies on Q and is normal to P-Q
Test all the points in S on which side of H are on.
If they are all either on the plane or on the opposite side of H compared to P, then P is either on or outside of S. If some points are in front of H, and others are behind H, then P is inside S.
Related
This might be a weird application.
The brief description of the problem is "How to get Absolute Coordination of nodes based on Relative Positions (distances) ?"
We have a number of Nodes (each with a unique ID) and a list specifying its Adjacent nodes and distance to each of them as Input.
The required output would be one possible way to lay out these nodes on a 2D Surface.
The resulting algorithm is going to be used in C#... So external .net libraries might help too.
It would be a great help if you could advise me an approach to do that.
Thank you in advance.
You must have coordinates of at least three known points at start.
Way I. If the known points are adjacent, the process is simple - you loop all your points, looking for such, which have in their lists three known points. Use two of them to count two possible positions, then use the third to choose right or left variant. Repeat the loops until you have no new points during a loop.
That simple algorithm has bad convergence - the errors are accumulating and far points could have bad coordinates. But as you have the coordinates integer, you can repair coords after each counting and have them good.
Way II. If the known points are not adjacent to each other, the process is more complicated.
Let's say, you have start known points A,B,C.
Take A and some its adjacent point D. Place it somewhere at the correct distance from A.
Find some point E adjacent to A and D. Choose any of two possible positions.
Starting from A, D, E, use the way I.
When you reach by distances the second start known point, let it be B, of course, it will be in bad place. Turn all the net you have built around A so, that B will get the correct coordinates. Continue the looping.
When you will reach the last of the start known points, C, it will be set correct or not. If not, mirror the whole net relatively AB axis - the C will be set correctly. (If not, you have bad data). Continue the way I looping till the end.
Both these two ways work if you have long lists for all points. If points have only few distances given, the task becomes much, much more complicated.
I have some trouble.
I need generate walls by path.
For example. I have vectors A, B, C. And I need to find vectors D, E, F for creating volumetric walls around ABC.
Firstly, I going on easiest way - scaling ABC (with finding a centroid).
But it's not a correct solution, b/c I need to set correct width of walls, and I need to find some additional points like this (point J and point K with JK perpendicular AB)
I will be gratefull for any help!
You will need to find out normals to the outer edge of the polygon.
There could be two approaches.
One is using edge normals, another is vertex normals.
On edge normals you will need to find out what direction is outside (depends on closed / open)
If you use vertex normals, you will only need to translate the vertex to the new position. Finding out a good vertex normal is the main problem.
This is known as offsetting. More details can be found below.
An algorithm for inflating/deflating (offsetting, buffering) polygons
I've been going over this algorithm and it seams pretty straight forward. I am, however, confused as to how to use it in a enclosed polygons. ALL of the examples I have seen deal with a line/curve with open ends. If i'm visualizing the process correctly drawing a single line and then iterating over it to re-capture the detail of a polygon wont work because it will always leave at least on side of the polygon open.
I'm thinking about writing an implementation that first makes 4 points (the farthest topLeft, TopRight, Bottomright, and BottomLeft points) and then runs the algorithm on vertices in between these to points indices.
So if the bottom line has an index of 40 and 80 in the original path array then I will iterate there and capture the likeness of that line on just points 40-80 them move onto the next side until all for sides are done.
I've been known to make a fool myself and way overcomplicate tings so I was wondering if this was a reasonable implementation?
I'm basicaly trying to replication the GPX data reduction impmentation seen below:
After a quick reading of the algorithm on Wikipedia, it seems that you can capture the simplified shape of the enclosed loop in a simple way.
Call the method with the start-point 'A' and end-point 'Z' being the same.
Modify the algorithm, so that if 'A' and 'Z' are the same point that instead of finding the farthest point perpendicular to the line AZ that it just looks for the point farthest away according to Euclidean distance from the Start/End point.
Now the algorithm recurses on A->M and M->Z where M is the point farthest from A (which is also Z). Now the algorithm can run normally.
I've got two polygons defined as a list of Vectors, I've managed to write routines to transform and intersect these two polygons (seen below Frame 1). Using line-intersection I can figure out whether these collide, and have written a working Collide() function.
This is to be used in a variable step timed game, and therefore (as shown below) in Frame 1 the right polygon is not colliding, it's perfectly normal for on Frame 2 for the polygons to be right inside each other, with the right polygon having moved to the left.
My question is, what is the best way to figure out the moment of intersection? In the example, let's assume in Frame 1 the right polygon is at X = 300, Frame 2 it moved -100 and is now at 200, and that's all I know by the time Frame 2 comes about, it was at 300, now it's at 200. What I want to know is when did it actually collide, at what X value, here it was probably about 250.
I'm preferably looking for a C# source code solution to this problem.
Maybe there's a better way of approaching this for games?
I would use the separating axis theorem, as outlined here:
Metanet tutorial
Wikipedia
Then I would sweep test or use multisampling if needed.
GMan here on StackOverflow wrote a sample implementation over at gpwiki.org.
This may all be overkill for your use-case, but it handles polygons of any order. Of course, for simple bounding boxes it can be done much more efficiently through other means.
I'm no mathematician either, but one possible though crude solution would be to run a mini simulation.
Let us call the moving polygon M and the stationary polygon S (though there is no requirement for S to actually be stationary, the approach should work just the same regardless). Let us also call the two frames you have F1 for the earlier and F2 for the later, as per your diagram.
If you were to translate polygon M back towards its position in F1 in very small increments until such time that they are no longer intersecting, then you would have a location for M at which it 'just' intersects, i.e. the previous location before they stop intersecting in this simulation. The intersection in this 'just' intersecting location should be very small — small enough that you could treat it as a point. Let us call this polygon of intersection I.
To treat I as a point you could choose the vertex of it that is nearest the centre point of M in F1: that vertex has the best chance of being outside of S at time of collision. (There are lots of other possibilities for interpreting I as a point that you could experiment with too that may have better results.)
Obviously this approach has some drawbacks:
The simulation will be slower for greater speeds of M as the distance between its locations in F1 and F2 will be greater, more simulation steps will need to be run. (You could address this by having a fixed number of simulation cycles irrespective of speed of M but that would mean the accuracy of the result would be different for faster and slower moving bodies.)
The 'step' size in the simulation will have to be sufficiently small to get the accuracy you require but smaller step sizes will obviously have a larger calculation cost.
Personally, without the necessary mathematical intuition, I would go with this simple approach first and try to find a mathematical solution as an optimization later.
If you have the ability to determine whether the two polygons overlap, one idea might be to use a modified binary search to detect where the two hit. Start by subdividing the time interval in half and seeing if the two polygons intersected at the midpoint. If so, recursively search the first half of the range; if not, search the second half. If you specify some tolerance level at which you no longer care about small distances (for example, at the level of a pixel), then the runtime of this approach is O(log D / K), where D is the distance between the polygons and K is the cutoff threshold. If you know what point is going to ultimately enter the second polygon, you should be able to detect the collision very quickly this way.
Hope this helps!
For a rather generic solution, and assuming ...
no polygons are intersecting at time = 0
at least one polygon is intersecting another polygon at time = t
and you're happy to use a C# clipping library (eg Clipper)
then use a binary approach to deriving the time of intersection by...
double tInterval = t;
double tCurrent = 0;
int direction = +1;
while (tInterval > MinInterval)
{
tInterval = tInterval/2;
tCurrent += (tInterval * direction);
MovePolygons(tCurrent);
if (PolygonsIntersect)
direction = +1;
else
direction = -1;
}
Well - you may see that it's allways a point of one of the polygons that hits the side of the other first (or another point - but thats after all almost the same) - a possible solution would be to calculate the distance of the points from the other lines in the move-direction. But I think this would end beeing rather slow.
I guess normaly the distances between frames are so small that it's not importand to really know excactly where it hit first - some small intersections will not be visible and after all the things will rebound or explode anyway - don't they? :)
I have a List of 2D points. What's an efficient way of iterating through the points in order to determine whether the list of points are in a straight line, or curved (and to what degree). I'd like to avoid simply getting slopes between smaller subsets. How would I go about doing this?
Thanks for any help
Edit: Thanks for the response. To clarify, I don't need it to be numerically accurate, but I'd like to determine if the user has created a curved shape with their mouse and, if so, how sharp the curve is. The values are not too important, as long as it's possible to determine the difference between a sharp curve and a slightly softer one.
If you simply want to know if all your points fit more or less on a curve of degree d, simply apply Lagrange interpolation on the endpoints and d-2 equally spaced points from inside your array. This will give you a polynomial of degree d.
Once you have your curve, simply iterate over the array and see how far away from the curve each point is. If they're farther than a threshold, your data doesn't fit your degree d polynomial.
Edit: I should mention that iterating through values of d is a finite process. Once d reaches the number of points you have, you'll get a perfect fit because of how Lagrange interpolation works.
To test if it's a straight line, compute the correlation coefficient. I'm sure that's covered on wikipedia.
To test if it's curved is more involved. You need to know what kind of curves you expect, and fit against those.
Here is a method to calculate angle: Calculate Angle between 2 points using C#
Simply calculate angle between each and every point in your list and create list of angles, then compare if angles list values are different. If they are not different then it means it's straight line, otherwise it's curve...
If it's a straight line then angle between all points has to be a same.
The question is really hazy here: "I'd like to avoid simply getting slopes between smaller substes"
You probably want interpolation a-la B-splines. They use two points and two extra control points if memory serves me. Implementations are ubiquitous since way back (at least 1980's). This should get you underway
Remember that you'll probably need to add control points to make the curve meet the endpoints. One trick to make sure those are reached is to simply duplicate the endpoints as extra controlpoints.
Cheers
Update Added link to codeproject
it would appear that what I remember from back in the 80's could have been Bezier curves - a predecessor of sorts.