I'm trying to write a java mobile application (J2ME) and I got stuck with a problem: in my project there are moving circles called shots, and non moving circles called orbs. When a shot hits an orb, it should bounce off by classical physical laws. However I couldn't find any algorithm of this sort.
The movement of a shot is described by velocity on axis x and y (pixels/update). all the information about the circles is known: their location, radius and the speed (on axis x and y) of the shot.
Note: the orb does not start moving after the collision, it stays at its place. The collision is an elastic collision between the two while the orb remains static
here is the collision solution method in class Shot:
public void collision(Orb o)
{
//the orb's center point
Point oc=new Point(o.getTopLeft().x+o.getWidth()/2,o.getTopLeft().y+o.getWidth()/2);
//the shot's center point
Point sc=new Point(topLeft.x+width/2,topLeft.y+width/2);
//variables vx and vy are the shot's velocity on axis x and y
if(oc.x==sc.x)
{
vy=-vy;
return ;
}
if(oc.y==sc.y)
{
vx=-vx;
return ;
}
// o.getWidth() returns the orb's width, width is the shot's width
double angle=0; //here should be some sort of calculation of the shot's angle
setAngle(angle);
}
public void setAngle(double angle)
{
double v=Math.sqrt(vx*vx+vy*vy);
vx=Math.cos(Math.toRadians(angle))*v;
vy=-Math.sin(Math.toRadians(angle))*v;
}
thanks in advance for all helpers
At the point of collision, momentum, angular momentum and energy are preserved. Set m1, m2 the masses of the disks, p1=(p1x,p1y), p2=(p2x,p2y) the positions of the centers of the disks at collition time, u1, u2 the velocities before and v1,v2 the velocities after collision. Then the conservation laws demand that
0 = m1*(u1-v1)+m2*(u2-v2)
0 = m1*cross(p1,u1-v1)+m2*cross(p2,u2-v2)
0 = m1*dot(u1-v1,u1+v1)+m2*dot(u2-v2,u2+v2)
Eliminate u2-v2 using the first equation
0 = m1*cross(p1-p2,u1-v1)
0 = m1*dot(u1-v1,u1+v1-u2-v2)
The first tells us that (u1-v1) and thus (u2-v2) is a multiple of (p1-p2), the impulse exchange is in the normal or radial direction, no tangential interaction. Conservation of impulse and energy now leads to a interaction constant a so that
u1-v1 = m2*a*(p1-p2)
u2-v2 = m1*a*(p2-p1)
0 = dot(m2*a*(p1-p2), 2*u1-m2*a*(p1-p2)-2*u2+m1*a*(p2-p1))
resulting in a condition for the non-zero interaction term a
2 * dot(p1-p2, u1-u2) = (m1+m2) * dot(p1-p2,p1-p2) * a
which can now be solved using the fraction
b = dot(p1-p2, u1-u2) / dot(p1-p2, p1-p2)
as
a = 2/(m1+m2) * b
v1 = u1 - 2 * m2/(m1+m2) * b * (p1-p2)
v2 = u2 - 2 * m1/(m1+m2) * b * (p2-p1)
To get the second disk stationary, set u2=0 and its mass m2 to be very large or infinite, then the second formula says v2=u2=0 and the first
v1 = u1 - 2 * dot(p1-p2, u1) / dot(p1-p2, p1-p2) * (p1-p2)
that is, v1 is the reflection of u1 on the plane that has (p1-p2) as its normal. Note that the point of collision is characterized by norm(p1-p2)=r1+r2 or
dot(p1-p2, p1-p2) = (r1+r2)^2
so that the denominator is already known from collision detection.
Per your code, oc{x,y} contains the center of the fixed disk or orb, sc{x,y} the center and {vx,vy} the velocity of the moving disk.
Compute dc={sc.x-oc.x, sc.y-oc.y} and dist2=dc.x*dc.x+dc.y*dc.y
1.a Check that sqrt(dist2) is sufficiently close to sc.radius+oc.radius. Common lore says that comparing the squares is more efficient. Fine-tune the location of the intersection point if dist2 is too small.
Compute dot = dc.x*vx+dcy*vy and dot = dot/dist2
Update vx = vx - 2*dot*dc.x, vy = vy - 2*dot*dc.y
The special cases are contained inside these formulas, e.g., for dc.y==0, that is, oc.y==sc.y one gets dot=vx/dc.x, so that vx=-vx, vy=vy results.
Considering that one circle is static I would say that including energy and momentum is redundant. The system's momentum will be preserved as long as the moving ball contains the same speed before and after the collision. Thus the only thing you need to change is the angle at which the ball is moving.
I know there's a lot of opinions against using trigonometric functions if you can solve the issue using vector math. However, once you know the contact point between the two circles, the trigonometric way of dealing with the issue is this simple:
dx = -dx; //Reverse direction
dy = -dy;
double speed = Math.sqrt(dx*dx + dy*dy);
double currentAngle = Math.atan2(dy, dx);
//The angle between the ball's center and the orbs center
double reflectionAngle = Math.atan2(oc.y - sc.y, oc.x - sc.x);
//The outcome of this "static" collision is just a angular reflection with preserved speed
double newAngle = 2*reflectionAngle - currentAngle;
dx = speed * Math.cos(newAngle); //Setting new velocity
dy = speed * Math.sin(newAngle);
Using the orb's coordinates in the calculation is an approximation that gains accuracy the closer your shot is to the actual impact point in time when this method is executed. Thus you might want to do one of the following:
Replace the orb's coordinates by the actual point of impact (a tad more accurate)
Replace the shot's coordinates by the position it has exactly when the impact will/did occur. This is the best scenario in respect to the outcome angle, however may lead to slight positional displacements compared to a fully realistic scenario.
Related
I'm trying to do some basic trigonometry with Java and LibGDX on android.
I've spent a long time googling "How to find an angle in right triangles".
I still don't really understand :(
I want to give an Actor subclass a random direction to follow. So what is the angle - and what should I set xSpeed and ySpeed to, in order to move at the correct angle.
I started writing an app to help me see how it works.
There are two objects - An origin point and a touch point. User presses screen, touchPoint moves to where user touched. Methods fire to figure out the appropriate values. I know the XDistance and YDistance between the two points. That means I know the Opposite length and the Adjacent length. So all I need to do is tan-1 of (opposite / adjacent), am I right?
I just don't understand what to do with the numbers my program spits out.
Some code:
In create event of main class:
stage.addListener(new ClickListener() {
#Override
public void touchDragged(InputEvent event, float x, float y, int pointer) {
touchPoint.setX(x);
touchPoint.setY(y);
touchPoint.checkDistance(); // saves x and y distances from origin in private fields
atan2D = getAtan2(touchPoint.getYDistance(), touchPoint.getXDistance());
tanhD = getTanh(touchPoint.getYDistance(), touchPoint.getXDistance());
xDistanceLbl.setText("X Distance: " + touchPoint.getXDistance());
yDistanceLbl.setText("Y Distance: " + touchPoint.getYDistance());
atan2Lbl.setText("Atan2: " + atan2D);
tanhLbl.setText("Tanh: " + tanhD);
angleLbl.setText("Angle: No idea");
}
})
...
private double getAtan2(float adjacent, float opposite) {
return Math.atan2(adjacent, opposite);
}
private double getTanh(float adjacent, float opposite) {
return Math.tanh((adjacent / opposite));
}
These two functions give me numbers between (atan2: -pi to pi) and (tanh: -1.0 to 1.0)
How do I turn these values into angles from which I can then work backwards and get the opposite and adjacent again?
Doing this should allow me to create and object with a random direction, which I can use in 2D games.
atan2 gives you direction in radians. Direction from origin (0,0) to touchPoint. If you need direction from some object to touchPoint, then subtract object coordinates. Perhaps you also want to see direction in degrees (this is only for human eyes)
dx = x - o.x
dy = y - o.y
dir = atan2(dy, dx)
dir_in_degrees = 180 * dir / Pi
I you have direction and want to retrieve coordinate differences, you need to store distance
distance = sqrt(dx*dx + dy*dy)
later
dx = distance * cos(dir)
dy = distance * sin(dir)
But note that often storing dx and dy is better, because some calculations might be performed without trigonometric functions
Just noticed - using tanh is completely wrong, this is hyperbolic tangent function, it has no relation to geometry.
You can use arctan, but it gives angle in half-range only (compared with atan2)
I have an issue in my current game dev hobby. I have two units, which are hostile in 2D space. One is shooting directly at the opponent, so if he moves it misses. But the other should predict it's opponents movement and shoot "ahead".
Let's assume first unit is A and second one is B. I can calculate their distances and I have their viewing angle and I have the speed at which they are moving. (player speed and bullet speed are different constants)
I tried with approximations to calculate distance between A and B and then use the Bv and orientation angle to calculate where the B will be in the next second and then scale that by the distance of two players divided by the bullet speed. But this is very inefficient and does not work well.
float distanceK = MathUtil.distance(unit.x, unit.y, opponent.x, opponent.y) / Constants.BULLET_VELOCITY;
float x = (float) (opponent.x + (Constants.UNIT_FORWARD_VELOCITY * distanceK * Math.cos(opponent.orientationAngle)));
float y = (float) (opponent.y + (Constants.UNIT_FORWARD_VELOCITY * distanceK * Math.sin(opponent.orientationAngle)));
float angleToRotate = MathUtil.angleBetweenUnitAndPoint(unit, x, y);
In the example above I then use angleToRotate variable to determine how much do I have to rotate to hit opponent, but the rotation too takes some time (54deg/s)
I would need a more optimal solution for this problem.
a) predict opponent movement when you are standing still.
b) predict opponent movement when you are moving.
You could use a vector representation of the space. So BA would represent the vector between A and B from A's point of view. You could then add the vector Bv of unit B's velocity. The resultant vector would be the vector between B and Bvp the predicted position of B at some time t in the future. As for a moving calculation, you'd need to also account for the movement vector of A.
Here's a quick description of what some of the methods you'll see do:
this.bounds: Returns the ship's bounds (a rectangle)
this.bounds.getCenter(): Returns a Vector2d representing the center of the ship's bounds.
getVelocity(): A Vector2d which represents the ship's velocity (added to position every frame)
new Vector2d(angle): A new Vector2d, normalized, when given an angle (in radians)
Vector2d#interpolate(Vector2d target, double amount): Not linear interpolation! If you want to see the interpolate code, here it is (in class Vector2d):
public Vector2d interpolate(Vector2d target, double amount) {
if (getDistanceSquared(target) < amount * amount)
return target;
return interpolate(getAngle(target), amount);
}
public Vector2d interpolate(double direction, double amount) {
return this.add(new Vector2d(direction).multiply(amount));
}
When the player is not pressing keys, the ship should just decelerate. Here's what I do for that:
public void drift() {
setVelocity(getVelocity().interpolate(Vector2d.ZERO, this.deceleration));
}
However, now I've realized I want it to drift while going toward a target. I've tried this:
public void drift(Vector2d target) {
double angle = this.bounds.getCenter().getAngle(target);
setVelocity(getVelocity().interpolate(new Vector2d(angle), this.deceleration));
}
This of course won't ever actually reach zero speed (since I'm interpolating toward an angle vector, which has a magnitude of 1). Also, it only really "drifts" in the direction of the target when it gets very slow.
Any ideas on how I can accomplish this? I just can't figure it out. This is a big question so thanks a lot.
This is using a big library I made so if you have any questions as to what some stuff does please ask, I think I've covered most of it though.
Your interpolate function does strange things. Why not use simple physical models? For example:
Body has position (px, py) and velocity (vx, vy), also unit direction vector (dx, dy) is convenient
After (small) time interval dt velocity changes depending on acceleration
vx = vx + ax * dt
vy = vy + ay * dt
Any outer force (motor) causes acceleration and changes velocity
ax = forcex / mass //mass might be 1
ay = forcey / mass
Dry friction force magnitude does not depend on velocity, it's direction is reverse to velocity
ax = c * mass * (-dx)
ay = c * mass * (-dy)
Liquid friction force magnitude depends on velocity (there are many different equations for different situations), it's direction is reverse to velocity
ax = k * Vmagnitude * (-dx)
ay = k * Vmagnitude * (-dy)
So for every time interval add all forces, find resulting acceleration, find resulting velocity, change position accordingly
I'm making pretty simple game. You have a sprite onscreen with a gun, and he shoots a bullet in the direction the mouse is pointing. The method I'm using to do this is to find the X to Y ratio based on 2 points (the center of the sprite, and the mouse position). The X to Y ratio is essentially "for every time the X changes by 1, the Y changes by __".
This is my method so far:
public static Vector2f getSimplifiedSlope(Vector2f v1, Vector2f v2) {
float x = v2.x - v1.x;
float y = v2.y - v1.y;
// find the reciprocal of X
float invert = 1.0f / x;
x *= invert;
y *= invert;
return new Vector2f(x, y);
}
This Vector2f is then passed to the bullet, which moves that amount each frame.
But it isn't working. When my mouse is directly above or below the sprite, the bullets move very fast. When the mouse is to the right of the sprite, they move very slow. And if the mouse is on the left side, the bullets shoot out the right side all the same.
When I remove the invert variable from the mix, it seems to work fine. So here are my 2 questions:
Am I way off-track, and there's a simpler, cleaner, more widely used, etc. way to do this?
If I'm on the right track, how do I "normalize" the vector so that it stays the same regardless of how far away the mouse is from the sprite?
Thanks in advance.
Use vectors to your advantage. I don't know if Java's Vector2f class has this method, but here's how I'd do it:
return (v2 - v1).normalize(); // `v2` is obj pos and `v1` is the mouse pos
To normalize a vector, just divide it (i.e. each component) by the magnitude of the entire vector:
Vector2f result = new Vector2f(v2.x - v1.x, v2.y - v1.y);
float length = sqrt(result.x^2 + result.y^2);
return new Vector2f(result.x / length, result.y / length);
The result is unit vector (its magnitude is 1). So to adjust the speed, just scale the vector.
Yes for both questions:
to find what you call ratio you can use the arctan function which will provide the angle of of the vector which goes from first object to second object
to normalize it, since now you are starting from an angle you don't need to do anything: you can directly use polar coordinates
Code is rather simple:
float magnitude = 3.0; // your max speed
float angle = Math.atan2(y,x);
Vector2D vector = new Vector(magnitude*sin(angle), magnitude*cos(angle));
Let there be two balls, one of which is moving about in the Cartesian coordinate plane, while the other is stationary and immobile. At some point, the moving ball collides with the inert ball. Assuming the moving ball is traveling in a straight line, how can one derive the new angle that the moving ball will be propelled given the following information:
The moving ball's center coordinates (X0, Y0), radius (R0), and angle of travel before impact (A0)
The stationary ball's center coordinates (X1, Y1) and radius (R1)
If your second ball has infinite mass:
Where phi (after a long calc) is:
phi= -ArcTan[
( 2 R^2 Sin[A0] + 2 (YD Cos[A0] - XD Sin[A0]) (2 H Cos[A0] +
2 XD Sin[A0]^2 - YD Sin[2 A0])) /
((2 R^2 - XD^2 - 3 YD^2) Cos[A0] + (XD^2 - YD^2) Cos[3 A0] +
8 XD YD Cos[A0]^2 Sin[A0] + 4 H Sin[A0] (-YD Cos[A0] + XD Sin[A0]))
]
Where:
H = (R0 + R1)^2 - ((Y0 - Y1) Cos[A0] + (X0 - X1) Sin[A0])^2
R^2 = (R0 + R1)^2
XD = X1 - X0
YD = Y1 - Y0
Edit
To determine the whole trajectory, you'll also need the coordinates for the center of the moving ball at the time of impact. They are:
{X,Y}= {X1+Sin[A0] ((Y1-Y0) Cos[A0]+ (X0-X1) Sin[A0])-Cos[A0] Sqrt[H],
Y1+Cos[A0] ((Y0-Y1) Cos[A0]+(-X0+X1) Sin[A0])-Sin[A0] Sqrt[H]}
Page 3 of Pool Hall Lessons by Joe van den Heuvel, Miles Jackson gives a great example of how to do this.
// First, find the normalized vector n from the center of circle1 to the center of circle2
Vector n = circle1.center - circle2.center;
n.normalize();
// Find the length of the component of each of the movement vectors along n.
float a1 = v1.dot(n);
float a2 = v2.dot(n);
float optimizedP = (2.0 * (a1 - a2)) / (circle1.mass + circle2.mass);
// Calculate v1', the new movement vector of circle1
// v1 = v1 - optimizedP * m2 * n
Vector v1 = v1 - optimizedP * circle2.mass * n;
// Calculate v2', the new movement vector of circle2
// v2 = v2 + optimizedP * m1 * n
Vector v2 = v2 + optimizedP * circle1.mass * n;
circle1.setMovementVector(v1);
circle2.setMovementVector(v2);
Read at least page three to understand whats going on here.
You should take a look at the elastic collision article on wikipedia. I would explain here, but everything I could have said, wikipedia says it better and with clear examples and equations.
[A long, long time ago I studied this as an undergrad. ]
You need to be clear on the masses. Probably you are assuming equal mass for both balls, as opposed to one being of infinite mass.
The second thing is: Are you interested in considering rolling constraints as well as linear momentum. The treatments you will come across which talk along the lines of a simplistic elastic collision ignore all this. As an example, consider shots in pool/ snooker where you deliberately strike the ball away from the midpoint to generate front or backspin.
Do you want to able to do this?
If so, you need to consider the friction between a spinning ball and the surface.
For example in a "simple" straight-on collision between a rolling ball and a stationary one, if we assume perfectly elastic (again not quite true):
the initial collision stops the moving ball 'A'
the stationary ball 'B' starts moving at the impact speed of 'A'
'A' still has spin, it grips the surface and picks up some small velocity
'B' starts without spin and has to match it to its speed in order to roll. This results in it slowing slightly.
For the simplistic case, the calculation is much easier if you transform to the coordinates of the centre of mass. In that frame, the collision is always a straight-on collision, reversing the direction of the balls. You then just transform back to get the resultants.
Assuming indetical masses and speeds prior to the impact of v1 and w1.
V0 = centre of mass speed = (v1+w1)/2
v1_prime = v of mass_1 in transformed coords = v1 - V0
w1_prime = w1 - V0
Post collision, we have a simple reflection:
v2_prime = -v1_prime (== w1_prime)
w2_prime = -vw_prime (== v1_prime)
v2 = v2_prime + V0
w2 = w2_prime + V0
It simply reflects from the stationary ball. So compute the point of contact (the centres of the balls will be R0 + R1 apart) and the axis of reflection will be the line joining the centres.
EDIT: By which I mean the line joining the centres at the point of contact will have an angle, and you can use this angle to help compute the new angle of the moving ball.