I have code to find the correct vector to aim a gun to hit stationary targets using ballistic trajectories.
I also have code to hit moving targets in zero gravity (flat trajectories).
Both of these work perfectly.
My problem is trying to combine them.
Intercept needs the shot speed. This is pretty straight forward when using flat trajectories. With a ballistic arc, I can probably get close by dividing range by the time of flight to give an approximation of horizontal shot speed.
(I realize that this isn’t going to be spot on accurate. Though I’m not sure how else to do it. Advice?)
My issue is with the “h” at the end for “initial height of the projectile”. This makes no sense. Initial height is irrelevant, as all that should matter is the height compared to the target’s height. If it truly is the y height on a grid, SURELY you would need the target height as well?
Perhaps this term actually means the height difference?
Anyway, I plugged it in assuming height difference, and… well, it could use a lot of improvement.
h is not the difference. h is the height above the ground plane that the bullet starts. I think you’ll want to leave h as 0. Instead you should be using the angle of the ground to represent the difference in height between the cannon and target. sin(theta).
I think what you need to do is calculate the x and z components of your projectile first like you are with the zero gravity flat trajectory. From that you can get the time (t) it’ll take your projectile to get there. Then you need to rearrange the projectile equation so that it finds the initial y velocity (u) you need for it to be at the target y value after time (t)…
But height above the ground is irrelevant. Unless it’s assuming the projectile is ending at ground level, in which case, then h is effectively the height difference.
In previous equations, theta is the fire angle. And the description suggests angle of launch.
I don’t think theta can’t be the angle to the target. It has to be the angle of fire. If it’s angle to the target, there would have to be a distance to target in there somewhere, and there isn’t. Additionally, if it’s angle to target, then there would be 2 solutions for angle of fire (high arc and low arc) thus 2 solutions for time of flight. And the equation doesn’t doesn’t reflect that either.
Why would I need to rearrange for initial velocity? I already know the initial velocity.
yeah sorry, you’re right. I misinterpreted the equation after looking at another on wikipedia.
The idea for rearranging was to find the initial y velocity so that your projectile would land on the target after flying to t (time) with g (gravity) applied to it. It is a bit of a fudge but it’s probably the easiest way to get it to land on the target.
That way you can aim your cannon to hit a target’s future position like you are with your flat trajectory, no gravity equation and then just ad the gravity and y velocity on to that.
You’re saying to make muzzle velocity vary from one moment to the next?
I’d rather avoid that.
I think a better way to think of this is:
“Given a shot speed of v, what average horizontal velocity intersects with a future position of the target?” (this might be akin to slope-intercept?). And this result has to be narrowed down to valid firing solutions. (and there’s probably two of them)
I’m not really sure how to find this.
Hmm, wait. Maybe it’s, “what average horizontal velocity matches the target’s horizontal velocity?”. I think this might be just a rearranging of the intercept formula.
Once I have that, then the question becomes what angle of fire results in that horizontal velocity?
Or maybe, that won’t matter because I’ll have the future target position then, and then it’s just like the normal ballistic formula.
Hitting a moving target with a ballistic projectile is typically an iterative process. Approximate the time of projectile travel. Project the targets position forward that amount of time. Calculate a trajectory to hit the projected position. Calculate the actual time. Repeat until an acceptable shot is found.
In reference to the equation, h can be considered as the height of the launcher above ground level.
Also note the equation doesn’t guarantee a hit is possible, it just determines how long it would take for the projectile to return to the ground. You use a separate formula to find the horizontal distance travelled and thus the final landing location of the projectile.
The ground, then, in the formula is the target. So h is the height difference between the shooter and target.
If the hit was impossible, then I wouldn’t be finding time of flight. I’ve already got a separate working formula to hit a stationary target. I was only finding time of flight to find the average horizontal velocity.
I’m trying to work through the equations, but I’m a little unsure how to adapt this. It looks like he’s using vectors, however directly using vectors in code causes the compiler to complain.
I tried isolating distances along height, and then along xz. And also tried using magnitudes. It’s not really working.
Can anyone make heads or tails of those formulas?
The last one looks like exactly what I need, just can’t quite work it.
You can actually dispense with half of the formula. (If you make the assumption that gravity is standard.)
It translates in Unity to something like this. (Untested).
// I assume you can get these two variables;
Vector3 initialVelocity;
Vector3 targetPosition;
float time = (initialVelocity.y + Mathf.Sqrt(initialVelocity.y * initialVelocity.y + 2 * Physics.gravity * (transform.position.y - targetPosition.y)))/2;
Hmmm. That can’t be right. It doesn’t yield two solutions. Most of the time there will be two firing solutions, a high arc and a low arc, each with a different time of flight.
Is initialVelocity supposed to be shot speed or relative target speed? Either way, I would think you’d need the other one too.
You indicated you already had your firing solution solved. This formula has nothing to do with finding the shooting solution. Once you have your shooting solution (initialVelocity in my code) then you can use this equation to figure out the time of flight, and adjust the shooting solution to hit the new target.
Stepping right back to the algorithm you need to follow.
Identify the target position and velocity
Solve the firing solution to hit the target position (ie get the projectile initialVelocity)
Calculate the time (t) required for the projectile to reach the target position (my code, and the equation you linked)
Project where the target will be in t seconds
Resolve the firing solution to hit the new target position
Repeat steps 3-5 until a firing solution that is close enough to the target is found
Step 2 is exactly the same for a stationary target or a moving target. Its step two that will always yield two solutions, your high and low arc. If you don’t have a solution for hitting a stationary target then we should resolve that before trying to hit a moving one.
I’m not entirely convinced that a iterative solution is the way to go. It sounds computationally expensive (prohibitive). Surely there is a better way to do this?
It looks like the newer linked page isn’t describing an iterative solution, (though he does talk about some kind of iteration to find cubic roots, not really following that, though.) For one thing, putting the quadratic equation into wolfram alpha to solve for (t), certainly doesn’t look iterative.
I think my difficulty now is translating the equations into 3D vector space, though it’s entirely possible that the process is fundamentally flawed.
But I’m under the impression that ballistics is a solved field of math. Are you positive that this requires an iterative solution?
The article you posted uses an iterative solution. The details are different to my method, but the end result is identical.
It’s probably possible to create some artificial constraints and do some clever calculus and come up with an exact equation. But that would require far more mathematics then you have at your disposal.
Ah.
Ok then, so if it isn’t working, it’s a problem in how I’m handling the vectors and positions, and not the underlying mathematics.
That’s somewhat good news.
I contacted the author, and it appears the problem lies in the fact that wolfram alpha is treating the vectors as scalars. This changes the nature of the equation re-arranging, as the dot product of two vectors is not the same as multiplying the magnitudes.
I tried putting the vectors into wolfram alpha, and it didn’t like that very much. So it looks like I’m back to an iterative solution.
I did wonder how you could solve it when every other solution I’ve seen uses an iterative approach. It doesn’t take many iterations, but it will require a couple.
Real world ballistics is typically done by splitting the equation into x and y components, rather then trying to solve with vectors directly.
