So I have a ship, that has thrusters at the bottom and that can only use these to move forward. It can also rotate itself around its center. Its thrusters gives it acceleration, so it doesn't move at a constant velocity. What I want to do is to tell it "move to point B".
I have come up with a solution but it doesn't work very well and it doesn't rotate smoothly, it moves jerkily and it doesn't end up exactly where it should be, so I have to have a big margin of error.
Is this a normal problem, and if so is there a "standard" way of doing it? Is this an easy problem? I want to make it look like the ship is steering itself to that point, using the constraints (thrusters, rotation) the player has. This excludes just lerping it from point A to B. Or does it?
I'd love some help in solving this problem. Positions are stored in vectors, and it's a 2D problem. Just for reference I'm including my solution, which basically is accelerating the ship until and rotating it to point to the point. I think my implementation of this idea is the problem:
Vector diff = vector_sub(to_point, pos);
float angle = vector_getangle(diff);
float current_angle = vector_getangle(dir);
float angle_diff = rightrange(angle) - rightrange(current_angle);
float len = vector_getlength(diff);
// "Margin of error"
float margin = 15.0;
// Adjust direction, only if we're not stopping the next thing we do (len <= margin)
if ( len > margin && fabs(angle_diff) > 2.0 )
{
dir = vector_setangle(dir, current_angle + (angle_diff)*delta*(MY_PI) - MY_PI/2);
}
else if ( len > margin )
{
dir = vector_normalize(diff);
}
// accelerate ship (if needed)
acc.x = acc.y = speed;
acc = vector_setangle(acc, vector_getangle(dir));
if ( len <= margin )
{
// Player is within margin of error
}
If you are not looking for a very general solution that works online, then there is a simple solution. What I mean by online is continuously re-calculating the actions along the complete trajectory.
Assuming the ship is at rest at start, simply rotate it towards your target point (while still at rest). Now, your ship can reach the target by accelerating for t seconds, rotating back while in motion (for 0.5 seconds as per your constraint), and decelerating for another t seconds. If the distance between current point and destination is d, then the equation you need to solve is:
d = 0.5*a*t^2 + 0.5*a*t + 0.5*a*t^2
The first term is distance traveled while accelerating. The second term is distance traveled while rotating (v*t_rot, v=a*t, t_rot=0.5). The final term is the distance traveled while decelerating. Solve the above for t, and you have your trajectory.
If the ship is moving at start, I would first stop it (just rotate in opposite direction of its speed vector, and decelerate until at rest). Now we know how to reach destination.
The problem with offline trajectory calculation is that it is not very accurate. There is a good chance that you will end up in the vicinity of the target, but not exactly on top of it.
Let's make the problem a little more interesting: the ship cannot rotate without acceleration. Let's call this acceleration vector a_r, a vector that is at a certain angle against the ship's direction (somewhat like having a thruster at an angle at the back). Your task now is to rotate the ship and accelerate in such a direction that the speed component perpendicular to the vector connecting the current position to the target is canceled out. Instead of trying to calculate the vectors offline, I would go with an online approach with this.
The easiest thing to do would be to add the following algorithm calculated at every time interval:
Calculate the vector pointing from ship to destination.
Split your current speed vector into two components: towards the destination, and perpendicular to it.
If perpendicular speed is zero, skip 4
Start rotating towards the negative of the perpendicular vector's direction. If already looking away from it (not exact opposite, but just looking away), also fire main thruster.
This will oscillate a bit, I suspect it will also stabilize after a while. I must admit, I don't know how I would make it stop at destination.
And the final approach is to model the ship's dynamics, and try to linearize it. It will be a non-linear system, so the second step will be necessary. Then convert the model to a discrete time system. And finally apply a control rule to make it reach target point. For this, you can change your state-space from position and speed to error in position and (maybe) error in speed, and finally add a regulation control (a control loop that takes the current state, and generates an input such that the state variables will approach zero).
This last one is fairly difficult in the maths compartment, and you'd probably need to study control engineering a bit to do it. However, you'll get much better results than the above simplistic algorithm - which admittedly might not even work. In addition, you can now apply various optimization rules to it: minimize time to reach target, minimize fuel consumption, minimize distance traveled, etc.
Related
I am trying to create a physically plausible 2d physics engine. I have read many documents about detection of collisions, contact resolving, interpenetrations, projection, separating axis theorem (SAT) methods, etc.
Projection via SAT appears to be one physically plausible method for dealing with overlapping ("penetrating") objects. This works fine for objects with no rotation, but I can't figure out how to deal with rotations.
Imagine two polygons in rotation that will collide:
I need to understand how to project the point of contact and the time when this happens.
any help will be appreciated!
The problem is that you are assuming both bodies are moving at the same time, which will be a huge pain to calculate the exact collision point.
You can update the position of each body sequentially, and apply the collisions accordingly:
(I know the bodies are not rotated in this example, but I have no means right now to draw rotated forms, but the same idea applies, sorry)
First, the rectangle is moved, and checks for collision.
Then, the pentagon moves, and collides with the rectangle, updating its position.
And last, the triangle position is also checked for collition and updated.
About how to calculate the collision point, you can apply this:
Position calculateValidPosition(Position start, Position end)
Position middlePoint = (start + end) /2
if (middlePoint == start || middlePoint == end)
return start
if( isColliding(middlePont) )
return calculateValidPosition(start, middlePoint)
else
return calculate(middlePoint, end)
Note that
Position middlePoint = (start + end) /2
not only calculates the body's middle position, but also should calculate it's middle rotation:
If rotation is X at the begining of the movement, and Y at the end, the middle point rotatiln is just (X+Y)/2
Note this algorithm leaves a lot of room for optimization (like making it non-recursive)
This solution might seem not really accurate, but it will only work incorrectly when the speed of the bodies is way greater than the body's size, which will only happen if a really small body moves really fast. In the rest of scenarios the result is "good enough" for a game.
I was wondering if there was a target leading formula for target leading in 3d with a ballistic trajectory and if not i was wondering if it is possible to convert a 2d target leading formula to work as a 3d target leading formula by aligning the plane it is on along the motion of the target?
Leading the target can be easily calculated at the time the projectile is fired, however there is no guarantee the target won't change course, accelerate, or decelerate while the projectile is in the air. In any case, when you're leading the target you can either assume that the target's velocity will remain the same, or if it is accelerating, that its acceleration will remain the same.
Here's a blog post I wrote about predicting a traveled distance over time, accounting for acceleration. And here is the code I use.
This will calculate a distance traveled, over time, given a constant acceleration. In this case constantAccel is a speed, and if your target isn't accelerating then you would just use 0.0f for that parameter.
float CalcDistanceOverTime(const float initVelocity,
const float constantAccel,
const float timeDelta)
{
return (initVelocity * timeDelta)
+ (0.5f * constantAccel * (timeDelta * timeDelta);
}
Here's an example:
Vector3 targetsVelocity(3.0f, 0.0f, 3.0f);
float targetsAcceleration = 1.0f;
float distanceTraveled = CalcDistanceOverTime(targetsVelocity, targetsAcceleration, timeDelta)
Vector3 finalPosition = targetsVelocity * distanceTraveled;
You may notice that you'll need a timeDelta to pass to this formula. This means, based on your projectile's trajectory and speed, you'll need to know about how long it will take to reach the target, however it is made more difficult by the fact that you don't know exactly how long that may take until you know where it will be. I'm not sure of the exact formula for this, but I believe using Calculus you could calculate, based on the speed and velocity of your projectile, and the speed and velocity of your target, accounting for gravity with both, that you should be able to find a point in space where these two can collide.
If the above method isn't feasible then you may be able to choose a fixed timeDelta, if you can guarantee your projectile can go at whatever angle and speed that you would like. For example, pick 3 seconds as your timeDelta, you know where the target will be in 3 seconds, and immediately fire a projectile that you know will reach that point in space within 3 seconds.
And just in case, here's a blog post about calculating ballistic trajectory in 3D. Calculating the time to target with this method should be simple, based on outgoing vertical velocity and position, just use gravity to calculate how many seconds until that position reaches the elevation at the target position.
I've looked for quite some time now to find a nice math solution for my cannon firing a projectile at a moving target, taking into account the gravity. I've found a solution for determining the angle at which the cannon should be fired, based on the cannon's position, the target's position and the start velocity. The formula is described here: http://en.wikipedia.org/wiki/Trajectory_of_a_projectile#Angle_.CE.B8_required_to_hit_coordinate_.28x.2Cy.29.
This works perfectly. However, my target is moving, so if I shoot at the target and the projectile takes a few seconds to get to its destination, the target is long gone. The target's x position can be determined from the time. Lets say that: x = 1000 - (10 * t) where t is the time in seconds. The y can be described as: y = t.
The problem is, that t depends on the angle at which the cannon is fired.
Therefor my question is: How can I modify the formula as described in the wiki, so that it takes the moving target into account?
Additionally, I might have been looking at the wrong words here or on Google, but I didn't find any solution describing this exact problem.
Thank you in advance for your braintime!
As a reply to your comments. I want to fire it now and the target is in range given the speed. I think that are all constraints that are applicable to this problem.
As a reply to the answer, lets take a look at this example:
The cannon is at {0, 0} and isn't moving.
The start speed is 100 m/s.
The target is at {1000, 0} and is moving with 10 m/s towards the cannon (v = -10 m/s).
What angle should I use to hit the moving target, when I want to fire at t=0 (immediately)?
If I shoot without taking the target's speed into account, I would aim at {1000, 0} and the angle could be calculated using the mentioned formula. But it will miserably miss the target because its moving.
As Beta suggested, I could aim at i.e. {500, 0}, calculate what time it takes for the projectile to arrive at those coords (lets say 5 seconds) and wait until the target is 5 seconds away from {500, 0}, being {550, 0}. But this means that I have to wait 450m or 45 seconds before I can fire my cannon. And I don't want to wait, because the target is killing me in the mean time.
I really hope this gives you enough info to go with. I'd prefer some math solution, but anything that would get me really close to firing "right away" and "right on target" is also much appreciated.
The problem is underconstrained, which means that you will have some choices. You can track the target through the air for a while, and the choice of when to fire is up to you.
If you know the target's trajectory, and you know how to hit a stationary target, then you can choose where you want the impact to occur. Just pick a point on the trajectory (comfortably far ahead of the target) and aim there. Then all you have to do is decide when to fire. It is easy to calculate how long the cannonball will take to reach the point of impact; it is easy to calculate where the target will be, that much time before it reaches the point of impact; when the target is there, pull the trigger.
I suspect finding a formula will be quite difficult. However the error in the iterative scheme below will go down by roughly a factor of v/V (v the target speed, V the projectile speed) each step.
start by taking the time of flight to be zero
Repeat
calculate the distance to the target (using time of flight)
calculate the time of flight from the distance.
Until two successive times of flight are close enough
I'm trying to make a top-down spaceship game and I want the movement to somewhat realistic. 360 degrees with inertia, gravity, etc.
My problem is I can make the ship move 360° with inertia with no problem, but what I need to do is impose a limit for how fast the engines can go while not limiting other forces pushing/pulling the ship.
So, if the engines speed is a maximum of 500 and the ship is going 1000 from a gravity well, the ship is not going to go 1500 when it's engines are on, but if is pointing away from the angle is going then it could slow down.
For what it's worth, I'm using Construct, and all I need is the math of it.
Thanks for any help, I'm going bald from trying to figure this out.
Take a page from relative physics, where objects cannot exceed the speed of light:
(See below for my working C++ code snippet and running demo [Windows only].)
Set the constant c to the maximum speed an object can reach (the "speed of light" in your game).
If applying a force will increase the speed of the object, divide the acceleration (change in velocity) by the Lorentz factor. The if condition is not realistic in terms of special relativity, but it keeps the ship more "controllable" at high speeds.
Update: Normally, the ship will be hard to maneuver when going at speeds near c because changing direction requires an acceleration that pushes velocity past c (The Lorentz factor will end up scaling acceleration in the new direction to nearly nothing.) To regain maneuverability, use the direction that the velocity vector would have been without Lorentz scaling with the magnitude of the scaled velocity vector.
Explanation:
Definition of Lorentz factor, where v is velocity and c is the speed of light:
This works because the Lorentz factor approaches infinity as velocity increases. Objects would need an infinite amount of force applied to cross the speed of light. At lower velocities, the Lorentz factor is very close to 1, approximating classical Newtonian physics.
Graph of Lorentz factor as velocity increases:
Note: I previously tried to solve a similar problem in my asteroids game by playing with friction settings. I just came up with this solution as I read your question^^
Update: I tried implementing this and found one potential flaw: acceleration in all directions is limited as the speed of light c is approached, including deceleration! (Counter-intuitive, but does this happen with special relativity in the real world?) I guess this algorithm could be modified to account for the directions of the velocity and force vectors... The algorithm has been modified to account for directions of vectors so the ship does not "lose controllability" at high speeds.
Update: Here is a code snippet from my asteroids game, which uses the Lorentz factor to limit the speed of game objects. It works pretty well!
update:* added downloadable demo (Windows only; build from source code for other platforms) of this algorithm in action. I'm not sure if all the dependencies were included in the zip; please let me know if something's missing. And have fun^^
void CObject::applyForces()
{
// acceleration: change in velocity due to force f on object with mass m
vector2f dv = f/m;
// new velocity if acceleration dv applied
vector2f new_v = v + dv;
// only apply Lorentz factor if acceleration increases speed
if (new_v.length() > v.length())
{
// maximum speed objects may reach (the "speed of light")
const float c = 4;
float b = 1 - v.length_squared()/(c*c);
if (b <= 0) b = DBL_MIN;
double lorentz_factor = 1/sqrt(b);
dv /= lorentz_factor;
}
// apply acceleration to object's velocity
v += dv;
// Update:
// Allow acceleration in the forward direction to change the direction
// of v by using the direction of new_v (without the Lorentz factor)
// with the magnitude of v (that applies the Lorentz factor).
if (v.length() > 0)
{
v = new_v.normalized() * v.length();
}
}
Well, lets consider the realistic problem first and see why this doesn't work and how we have to differ from it. In space as long as your engines are firing, you will be accelerating. Your speed is only limited by your fuel (and in fact you can accelerate faster once you've spent some fuel because your moving less mass).
To give this model an effective maximum speed, you can consider particles in space slowing you down and causing friction. The faster you go, the more particles you're hitting and the faster you're hitting them, so eventually at some fast enough speed, you will be hitting enough particles the amount of decelerating they do exactly cancels out the amount of accelerating your engine is doing.
This realistic model does NOT sound like what you want. The reason being: You have to introduce friction. This means if you cut your engines, you will automatically start to slow down. You can probably count this as one of the unintended forces you do not want.
This leaves us with reducing the effective force of your engine to 0 upon reaching a certain speed. Now keep in mind if your going max speed in the north direction, you still want force to be able to push you in the east direction, so your engines shouldn't be cut out by raw velocity alone, but instead based on the velocity your going in the direction your engines are pointing.
So, for the math:
You want to do a cross dot product between your engine pointing vector and your velocity vector to get the effective velocity in the direction your engines are pointing. Once you have this velocity, say, 125 mph (with a max speed of 150) you can then scale back the force of your engines is exerting to (150-125)/150*(Force of Engines).
This will drastically change the velocity graph of how long it will take you to accelerate to full speed. As you approach the full speed your engines become less and less powerful. Test this out and see if it is what you want. Another approach is to just say Force of Engines = 0 if the dot product is >=150, otherwise it is full force. This will allow you to accelerate linearly to your max speed, but no further.
Now that I think about it, this model isn't perfect, because you could accelerate to 150 mph in the north direction, and then turn east and accelerate to 150 mph going in that direction for a total of 212 mph in the north east direction, so not a perfect solution.
I really do like Wongsungi's answer (with the Lorentz factor), but I wanted to note that the code can be simplified to have fewer floating-point operations.
Instead of calculating the Lorentz factor (which itself is a reciprocal) and then dividing by it, like this:
double lorentz_factor = 1/sqrt(b);
dv /= lorentz_factor;
simply multiply by the reciprocal of the Lorentz factor, like this:
double reciprocal_lorentz_factor = sqrt(b);
dv *= reciprocal_lorentz_factor;
This eliminates one floating-point operation from the code, and also eliminates the need to clamp b to DBL_MIN (it can now be clamped to 0 because we're not dividing anymore). Why divide by the reciprocal of x when you can just multiply by x?
Additionally, if you can guarantee that the magnitude of v will never exceed c, then you can eliminate the testing of b being less than zero.
Finally, you can eliminate two additional sqrt() operations by using length_squared() instead of length() in the outer if statement:
if (new_v.length_squared() > v.length_squared())
{
const float c = 4;
float b = 1 - v.length_squared()/(c*c);
if (b < 0) b = 0;
double reciprocal_lorentz_factor = sqrt(b);
dv *= reciprocal_lorentz_factor;
}
This may only make a 0.1% difference in speed, but I think the code is simpler this way.
You need to have three variables for your ship, which you update at each physics time step based on the forces that are acting on it. These will be mass, position, and velocity. (note that position and velocity are single numbers but vectors). At each physics time step you update the position based on the velocity, and the velocity based on the acceleration. you calculate the acceleration based on the forces acting on the ship (gravity, friction, engines)
Newton's equation for force is F = M*A We can rearrange that to A = F/M to get Acceleration. Basically you need to figure out how much the ship should accelerate, and in which direction (vector), then add that acceleration to the ship's velocity, and add the ship's velocity to its position.
Here is the code you should execute each physics time step (I hope you can fill in the blanks) please ask if this is not enough detail
gravity = //calculate force of gravity acting on ship from Newton's law of universal gravitation
friction = //ten percent of the ship's velocity vector, in the opposite direction
engines = 0
if (engines_are_firing)
engines = 500
forces = gravity + friction + engines
acceleration = forces / ship.mass
ship.velocity += acceleration
ship.position += velocity
redraw()
Your question is difficult for me to understand but it seems like you're not using real physics for this game. Have you considered using real physics equations such as velocity, acceleration, force, etc?
Edit:
After your edits, I think I have a better understanding. You are simply keeping track of the current velocity (or something similar) but you don't keep track of the force where that velocity comes from. The ship should not be storing any of that information (other than engine thrust) -- it should come from the environment the ship is in.
For instance, the environment has a gravity vector (directional force) so you would need to take that into account when calculating the directional force provided by the engine.
Your ship should be storing its own engine force, acceleration, and velocity.
Okay I'm working on a Space sim and as most space sims I need to work out where the opponents ship will be (the 3d position) when my bullet reaches it. How do I calculate this from the velocity that bullets travel at and the velocity of the opponents ship?
Calculate the relative velocity vector between him and yourself: this could be considered his movement if you were standing still. Calculate his relative distance vector. Now you know that he is already D away and is moving V each time unit. You have V' to calculate, and you know it's length but not it's direction.
Now you are constructing a triangle with these two constraints, his V and your bullet's V'. In two dimensions it'd look like:
Dx+Vx*t = V'x*t
Dy+Vy*t = V'y*t
V'x^2 + V'y^2 = C^2
Which simplifies to:
(Dx/t+Vx)^2 + (Dy/t+Vx)^2 = C^2
And you can use the quadratic formula to solve that. You can apply this technique in three dimensions similarly. There are other ways to solve this, but this is just simple algebra instead of vector calculus.
Collision Detection by Kurt Miller
http://www.gamespp.com/algorithms/collisionDetection.html
Add the negative velocity of the ship to the bullet, so that only the bullet moves. Then calculate the intersection of the ship's shape and the line along which the bullet travels (*pos --> pos + vel * dt*).
The question probably shouldn't be "where the ship will be when the bullet hits it," but IF the bullet hits it. Assuming linear trajectory and constant velocity, calculate the intersection of the two vectors, one representing the projectile path and another representing that of the ship. You can then determine the time that each object (ship and bullet) reach that point by dividing the distance from the original position to the intersection position by the velocity of each. If the times match, you have a collision and the location at which it occurs.
If you need more precise collision detection, you can use something like a simple BSP tree which will give you not only a fast way to determine collisions, but what surface the collision occurred on and, if handled correctly, the exact 3d location of the collision. However, it can be challenging to maintain such a tree in a dynamic environment.