I am given a pivot point (by the integer coordinates) and a line that goes through that point and makes an x degree with the horizontal. The line makes a 360 degrees clockwise rotation around the pivot point with speed s= 0.001 degree per second. I am now given N points (with integer coordinates) and I have to sort these points in the order in which the line touches these points. How can i compute this? Thank you in advance.
You need to do something equivalent to the following:
Translate everything so that the pivot point is at the origin
Convert each point to polar coordinates.
Subtract x from each point's angle component, modulo 360 degrees (2pi radians).
Sort the angle components in ascending order.
Write the comparison function that takes two points and compare the angles they make with horizontal line.
Related
I have the x,y position of a body that makes roughly circular orbits around a known point. Is there an algorithm that will give me the number of orbits this body makes over time if I feed it a vector of x,y positions? I don't care about variations in the distance of the body from the "origin" of the orbit.
EDIT 1:
My solution so far:
shift the x,y coords of the body by the x,y position of the orbit origin (i.e. make origin of orbit [0,0])
compute atan2 of body xy to get radians, then convert to degrees
shift degrees so that 0 is start location of body
find all turn points in degree vector (find 359->0 transitions)
count orbits as number of turn points + remainder
The following algorithm assumes that there are more than 2 positions stored per orbit, with a spacing of less than 180 degrees.
Basically you define a "finishing line" for the orbit using the first position and increment a count when the body crosses it, which you can detect when the sign of the dot product of the position vector with the line normal changes:
Take the vector from the known point the body is orbiting around to the first position in your series and find a vector perpendicular to it. In 2D you can do this just by subtracting the center point from the first position, then swapping the x and y components and negating one of them. This vector defines the normal to the "finishing line" of each orbit.
Take the vector from the center to second position in the series, and find the dot product with the normal calculated above by multiplying component-wise.
Initialize an orbit count to zero
For each remaining position in the series:
Compute the vector from the center to the position, and the dot product of it with the finishing line normal. If the sign of the dot product the same as that of the second position, and different to the previous position in the series, increase the count by one.
You can work out the fractional part by calculating the angle between the last position and the first.
I'm trying to calculate the axis of rotation of a ball which is moving and spinning at the same time, i.e. I want the vector along the axis that the ball is spinning on.
For every frame I know the x, y and z locations of 3 specific points on the surface of the sphere. I assume that by looking at how these 3 points have moved in successive frames, you can calculate the axis of rotation of the ball, however I have very little experience with this kind of maths, any help would be appreciated!
You could use the fact that the direction a position vector moves in will always be perpendicular to the axis of rotation. Therefore, if you have two position vectors v1 and v2 at successive times (for the same point), use
This gives you an equation with three unknowns (the components of w, the rotation axis). If you then plug in all three points you have knowledge of you should be able to solve these simultaneous equations and work out w.
all the plane definitions i've found use either four numbers (for the plane normal and distance from origin definition) or six numbers (for the plane normal and point that is on the plane definition).
maybe i'm missing something, but shouldn't it be possible to define a plane with only three numbers, (nx, ny, nz) using the direction of the vector as the plane normal and the magnitude of the vector as the distance from the origin?
i am trying to write a game that generates billions of planes, and shaving 25% off of my plane struct would really help.
It is possible, at the cost of recalculating the distance to the origin every time you need it.
If you need a solution using 3 parameters that has no degenerate case, use two direction angles (U, V) and the distance to the origin D.
Equation of the plane: cos(U).X + sin(U).cos(V).Y + sin(U).sin(V).Z = D.
If high accuracy is not mandated, you can store the angles as shorts, with suitable scaling, achieving 0°00'20" resolution. With float D, this packs to 8 bytes per plane.
I want to use the minkowski sum to predict the exact point of collision between two convex shapes. By my understanding the point where the velocity vector intersects with the minkowski sum is the amount I have to move my object along the vector so they just touch (I already know they will collide). Here's an example of what I mean (for simplicity reasons I just used rectangles):
I mean I could just calculate the intersection with every line of the convex hull and just use the closest but that seems horribly inefficient. My idea was to calculate the simplex closest to the vector but I have no idea how best to do it. I found a algorithm which calculates the smallest distance between to objects or to be more precise the smallest distance from the minkowski sum to the origin (http://www.codezealot.org/archives/153). One part of the algorithm tries to find the simplex closest to origin which is kinda what I want to do. I tried to change it to my needs but I wasn't successful. To me it sounds like there should be a very simple solution but I am not that good with vector math.
I hope I could make my problem clear since my english is not so good :D
You can transform the problem as follows:
1) rotate the plane so that the velocity vector becomes horizontal
2) consider the portions of the polygon outlines facing each other (these are two convex polylines); now you have to find the shortest horizontal distance between these two polylines
3) through every vertex of one of the polylines, draw an horizontal line; this will parition the plane into a set of horizontal slices
4) transform every slice using a shear transformation that brings the two vertices defining it onto the Y axis by horizontal moves; this transform preserves horizontal distances
5) while the first polyline is transformed into a straight line (the Y axis), the other polyline is transformed into another polyline; find the vertex(es) closest to the Y axis. This gives you the length of the collision vector.
As a by-product, step 2) will tell you if the polygons do collide, if the ranges of Y values overlap.
I found a Web Site which explains Inverse Kinematics in 2D:
Starting from the joint nearest the
end point:
1. Calculate a force vector from the end of the bone to the target.
2. Calculate the dot product of the force vector and the Right angle
vector.
3. Multiply it by a small value, like 0.01.
4. Add it to the angle of the joint.
http://freespace.virgin.net/hugo.elias/models/m_ik.htm
So the way the bones are designed in my application is in terms of a joint and an angle. Each 'bone' is a joint and an angle and a length. The bone's end point is then the unit vector of its starting point and angle, multiplied by its length.
So I think for step 1, I simply generate a unit vector whos direction points toward the target and multiply it by the distance between the end point and the target point.
Step 2 is where I'm unsure. I know how to produce a dot product, but I'm not sure how to get this right angle vector they speak of.
Thanks
The "right angle vector" is a vector that is at a right angle to the length of the bone.
If you are pushing the bone along its length, it shouldn't move. In this case, the angle between this "right angle vector" and your force vector is then 90 degrees, and so the dot product is zero. Hence, no change in angle of the bone.
The Right-Vector is the R-Vector in the pictures of the 2D-inv-kinematics-sections. It is a normalized vector orthogonal to the bone.
A small hint: the dot-product of vector A and a normalized vector B is just the projected length of vector A to the straight of vector B which is just the cos(angle). More details here: http://en.wikipedia.org/wiki/Dot_product#Geometric_interpretation
As a result if the target-vector is nearly the same as the right-vector then the cos will be near 1 and the algorithm will correct your bone-angle more than if the target-vector is nearly the same as your bone-vector (cos is near 0)