Calculate vector trajectory based on start point and end point, with simple gravity
Aaron Beall
My environment consists only of gravity (constant) and a Y plane/floor
for projectiles. There is no air drag, wind, or obstacles.
I have a known origin point, and destination point.
I want to calculate the needed artillery vector from the origin point
to land on the destination point. I don't know how to solve this
because of the gravity.
How would I solve this, assuming origin and destination points are on
the same Y value?
How would I solve this, if origin and destination may not be on the
same Y value?
Thanks for any help.
- Aaron
Paul E. Black
> This question is in regards to a Scorched Earth style artillery game.
>
> My environment consists only of gravity (constant) and a Y plane/floor
> for projectiles. There is no air drag, wind, or obstacles.
>
> I have a known origin point, and destination point.
>
> I want to calculate the needed artillery vector from the origin point
> to land on the destination point. I don't know how to solve this
> because of the gravity.
Aaron,
Hint: write an equation for a projectile given a beginning angle and
"power" (velocity) (it will be a second degree equation having trig
functions of the angle in the coefficients). Now solve the equation
for angle. You should be able to plug in the origin, destination, and
power to get an angle.
-paul-
Aaron Beall
>
> Hint: write an equation for a projectile given a beginning angle and
> "power" (velocity) (it will be a second degree equation having trig
> functions of the angle in the coefficients). Now solve the equation
> for angle. You should be able to plug in the origin, destination, and
> power to get an angle.
>
> -paul-
That makes sense, unfortunately I don't know how to write such an
equation. Any tips on how? Where I get completely lost is how to
formulate gravity, since it's just a constant applied over time. But
time is an unknown, so it can't be part of the formula, can it?
A second degree equation... you mean like this?
y = ax² + bx + c
I'm not really sure what to do what that... I did just find this
though, my understanding is very limited but it seems to be solving
exactly what I'm trying to solve:
http://hyperphysics.phy-astr.gsu.edu/Hbase/traj.html
Miss Elaine Eos
<faeaee0e-76f1-4197...@q26g2000prq.googlegroups.com>,
Aaron Beall <con...@abeall.com> wrote:
> On Aug 28, 12:13 pm, "Paul E. Black" <p.bl...@acm.org> wrote:
> > Hint: write an equation for a projectile given a beginning angle and
> > "power" (velocity) (it will be a second degree equation having trig
> > functions of the angle in the coefficients). Now solve the equation
> > for angle. You should be able to plug in the origin, destination, and
> > power to get an angle.
> That makes sense, unfortunately I don't know how to write such an
> equation. Any tips on how? Where I get completely lost is how to
> formulate gravity, since it's just a constant applied over time. But
> time is an unknown, so it can't be part of the formula, can it?
>
> A second degree equation... you mean like this?
> y = ax² + bx + c
>
> I'm not really sure what to do what that... I did just find this
> though, my understanding is very limited but it seems to be solving
> exactly what I'm trying to solve:
> http://hyperphysics.phy-astr.gsu.edu/Hbase/traj.html
To move a bullet:
startx = 0, starty = 0 // starting location
ang = degressToRadians(25) // 25 degress up on rifle
speed = 1200 // 1200 fps bullet
time = x // number of seconds after firing.
// Figure out new position
endx = startx // start location...
+ cos(ang) * speed * time // ...plus ballistics
endy = starty // start location
+ sin(ang) * speed * time // ...ballistics
- (time * time) * 32.15 // ...minus gravity
Now, to solve YOUR problem...
First work the above equation backwards to find out how many seconds
from now your bullet will be at the correct X location. (There are
often 2 answers for this, btw.)
Then work the other half of the equation backwards to figure out what
angle you need to point at to get the Y location to be what you want.
arcsine & arccosine will be involved.
Luck!
--
Please take off your pants or I won't read your e-mail.
I will not, no matter how "good" the deal, patronise any business which sends
unsolicited commercial e-mail or that advertises in discussion newsgroups.
Aaron Beall
wrote:
>
> To move a bullet:
>
> startx = 0, starty = 0 // starting location
> ang = degressToRadians(25) // 25 degress up on rifle
> speed = 1200 // 1200 fps bullet
> time = x // number of seconds after firing.
>
> // Figure out new position
> endx = startx // start location...
> + cos(ang) * speed * time // ...plus ballistics
>
> endy = starty // start location
> + sin(ang) * speed * time // ...ballistics
> - (time * time) * 32.15 // ...minus gravity
>
> Now, to solve YOUR problem...
>
> First work the above equation backwards to find out how many seconds
> from now your bullet will be at the correct X location. (There are
> often 2 answers for this, btw.)
>
> Then work the other half of the equation backwards to figure out what
> angle you need to point at to get the Y location to be what you want.
>
> arcsine & arccosine will be involved.
>
> Luck!
>
Thanks Miss Elaine! Unfortunately my brain is still not wrapped around
this.
> First work the above equation backwards to find out how many seconds
> from now your bullet will be at the correct X location.
What exactly do you mean by "work backwards"? If I solve for time, I
still don't know angle so I can't solve the formula? And won't the
time also be affected by the angle?
John Nagle
> This question is in regards to a Scorched Earth style artillery game.
>
> My environment consists only of gravity (constant) and a Y plane/floor
> for projectiles. There is no air drag, wind, or obstacles.
>
> I have a known origin point, and destination point.
>
> I want to calculate the needed artillery vector from the origin point
> to land on the destination point. I don't know how to solve this
> because of the gravity.
Read this tutorial:
http://en.wikibooks.org/wiki/High_school_physics/Projectile_motion
It has all the equations you need.
John Nagle
Animats
Aaron Beall
>
> Read this tutorial:
>
> http://en.wikibooks.org/wiki/High_school_physics/Projectile_motion
>
> It has all the equations you need.
>
> John Nagle
> Animats
Thanks so much. This looks like my answer:
http://upload.wikimedia.org/math/7/7/8/7786a0d50b1eb268db50f84665b01f35.png
"This may be solved for angle θ to give the "angle" equation to hit a
target at range dh"
I think at this point I'm just having some issue implementing the math
into programming syntax. I've tried a few combinations and they all
gave close results under some situations but didn't work in others.
var angle = 0.5 * Math.sin(-1) * ((GRAVITY*range)/
(velocity*velocity));
var angle = Math.pow(Math.sin((GRAVITY*range)/
(velocity*velocity)),-1) / 2;
Miss Elaine Eos
<995230bc-4200-4e4e...@a3g2000prm.googlegroups.com>,
Aaron Beall <con...@abeall.com> wrote:
> I think at this point I'm just having some issue implementing the math
> into programming syntax. I've tried a few combinations and they all
> gave close results under some situations but didn't work in others.
> var angle = 0.5 * Math.sin(-1) * ((GRAVITY*range)/
> (velocity*velocity));
> var angle = Math.pow(Math.sin((GRAVITY*range)/
> (velocity*velocity)),-1) / 2;
You have confused sin^-1 (aka "arcsine") with sin(-1), which is a
completely different thing. I'm surprised you get it to work under ANY
circumstances!
Also, I'm a big fan of intermediate variables for equations you don't
understand. This facilitates stepping through with a debugger and
understanding what's going on.
Even though arcsine is written as sine to the -1 power, that's not
really how it's calculated. Use Math.asin(value).
Aaron Beall
wrote:
> In article
>
> You have confused sin^-1 (aka "arcsine") with sin(-1), which is a
> completely different thing. I'm surprised you get it to work under ANY
> circumstances!
>
> Also, I'm a big fan of intermediate variables for equations you don't
> understand. This facilitates stepping through with a debugger and
> understanding what's going on.
>
> Even though arcsine is written as sine to the -1 power, that's not
> really how it's calculated. Use Math.asin(value).
Thank-you, I was definitely confused about arcsine. Somewhat
embarrasing how rusty my highschool physics are!
I seem to still be off somewhere:
GRAVITY = 3
range = target.x - origin.x
velocity = 35
angle = 0.5 * Math.asin((GRAVITY*range)/(velocity*velocity))
http://abeall.com/files/flash/tests/Game/trajectory.swf
Gray & Blue = iterative approximation to find closest angle
Red = trajectory from origin -> mouse
Green = motion formula from above, the one I'm trying to solve
Drag the origin arrow and target polygon, but note that range is
determined as x difference between origin and target at the moment. If
I can solve this for same Y position first I'll worry about different
Y elevations later.
Miss Elaine Eos
<b715ad9e-11d5-4764...@v39g2000pro.googlegroups.com>,
Aaron Beall <con...@abeall.com> wrote:
> On Aug 29, 11:07 am, Miss Elaine Eos <M...@your-pants.PlayNaked.com>
> wrote:
> > In article
> >
> > You have confused sin^-1 (aka "arcsine") with sin(-1), which is a
> > completely different thing. I'm surprised you get it to work under ANY
> > circumstances!
> >
> > Also, I'm a big fan of intermediate variables for equations you don't
> > understand. This facilitates stepping through with a debugger and
> > understanding what's going on.
> >
> > Even though arcsine is written as sine to the -1 power, that's not
> > really how it's calculated. Use Math.asin(value).
>
> Thank-you, I was definitely confused about arcsine. Somewhat
> embarrasing how rusty my highschool physics are!
Some notes:
X & Y in alphabetical order.
cos & sin in alphabetical order.
On the unit circle, cos = x value, sin = y value.
arc[cos]sin = the angle that, on the unit circle, has that [x]y value.
arc[cos] is typically limited to 0-pi (0-180°). You have to do a tiny
am amount of juggling if you're dealing with the other two quadrants.
It's simple mirror-images, though.
> I seem to still be off somewhere:
>
> GRAVITY = 3
3 *what*?! gravity = ~9M/s^s or ~32ft/s^s. I don't know any units
where it's ~3. I suppose you can make gravity whatever you want for
your game...
> range = target.x - origin.x
> velocity = 35
It's important that all your units be the same. You can't have gravity
in "meters per second" and velocity in "miles per hour" or any of that.
Pick a units & stick to it. I typically use meters & seconds when doing
Open-GL work. Other architectures get whatever is convenient.
> angle = 0.5 * Math.asin((GRAVITY*range)/(velocity*velocity))
Where did you come up with the 0.5 factor?
Don't forget my suggestion to use intermediate variables. They really
help you understand things a lot.
> http://abeall.com/files/flash/tests/Game/trajectory.swf
Ok, this looks about right. Where's the problem?
> Gray & Blue = iterative approximation to find closest angle
> Red = trajectory from origin -> mouse
> Green = motion formula from above, the one I'm trying to solve
Oh -- Green = your calculated answer? Well, it's wrong ;)
Break it down into smaller parts. Use intermediate variables. Se my
previous message (the part just before the stuff you quoted, above) for
how you have to work-backwards to calculate 2 different parts. Do them
separately, in separate, intermediate variables. (Don't optimize while
you're still trying to get the algorithm right!)
Remember that Math.foo() trig functions typically deal in radians. I
don't know what language you're using, but asin() & acos() might want
you to normalize (fit onto the unit-circle) your factors.
I notice in your calculation, you completely omitted time. Time
matters. That's why I said you have to figure the X-part first. (See
previous message.) I'm guessing that your green line is the angle you
WOULD shoot if the bullet arrive in 1 unit of time (1s), but it doesn't,
so it's wrong.
> Drag the origin arrow and target polygon, but note that range is
> determined as x difference between origin and target at the moment. If
> I can solve this for same Y position first I'll worry about different
> Y elevations later.
Sure.
Aaron Beall
wrote:
> In article
> <b715ad9e-11d5-4764-9a91-2f1729109...@v39g2000pro.googlegroups.com>,
> Aaron Beall <cont...@abeall.com> wrote:
>
>
>
> > On Aug 29, 11:07 am, Miss Elaine Eos <M...@your-pants.PlayNaked.com>
> > wrote:
> > > In article
>
> > > You have confused sin^-1 (aka "arcsine") with sin(-1), which is a
> > > completely different thing. I'm surprised you get it to work under ANY
> > > circumstances!
>
> > > Also, I'm a big fan of intermediate variables for equations you don't
> > > understand. This facilitates stepping through with a debugger and
> > > understanding what's going on.
>
> > > Even though arcsine is written as sine to the -1 power, that's not
> > > really how it's calculated. Use Math.asin(value).
>
> > Thank-you, I was definitely confused about arcsine. Somewhat
> > embarrasing how rusty my highschool physics are!
>
> Some notes:
>
> X & Y in alphabetical order.
> cos & sin in alphabetical order.
> On the unit circle, cos = x value, sin = y value.
>
> arc[cos]sin = the angle that, on the unit circle, has that [x]y value.
>
> arc[cos] is typically limited to 0-pi (0-180°). You have to do a tiny
> am amount of juggling if you're dealing with the other two quadrants.
> It's simple mirror-images, though.
Thanks again for your help! I'll try to explain the reasoning behind
my madness below:
>
> > I seem to still be off somewhere:
>
> > GRAVITY = 3
>
> 3 *what*?! gravity = ~9M/s^s or ~32ft/s^s. I don't know any units
> where it's ~3. I suppose you can make gravity whatever you want for
> your game...
All values are measured in pixels. So a value of 3 in this case simply
means the objects y velocities are accelerate downward at a rate of
3px per iteration. An iteration is basically a single frame, so at
30fps this value represents 90px/sec. This might not be physically
accurate, but it gives the effect I'm happy with.
>
> > range = target.x - origin.x
> > velocity = 35
>
> It's important that all your units be the same. You can't have gravity
> in "meters per second" and velocity in "miles per hour" or any of that.
> Pick a units & stick to it. I typically use meters & seconds when doing
> Open-GL work. Other architectures get whatever is convenient.
Velocity is again in pixels per iteration/frame. So at 30fps this
becomes 1050px/sec. The velocity may vary quite a bit, but it will be
a known value at the time I need to solve the projectile trajectory.
>
> > angle = 0.5 * Math.asin((GRAVITY*range)/(velocity*velocity))
>
> Where did you come up with the 0.5 factor?
I came up with 0.5 based on the part in formula where it says: ½sin-¹
from here:
http://upload.wikimedia.org/math/7/7/8/7786a0d50b1eb268db50f84665b01f35.png
Am I misreading the notation?
>
> Don't forget my suggestion to use intermediate variables. They really
> help you understand things a lot.
When you say "intermediate variables" you mean mean something like
this?
velocity2 = velocity*velocity;
gravityRange = GRAVITY*range;
angle = Math.asin(gravityRange/velocity2)/2;
>
> >http://abeall.com/files/flash/tests/Game/trajectory.swf
>
> Ok, this looks about right. Where's the problem?
>
> > Gray & Blue = iterative approximation to find closest angle
> > Red = trajectory from origin -> mouse
> > Green = motion formula from above, the one I'm trying to solve
>
> Oh -- Green = your calculated answer? Well, it's wrong ;)
Yeah, I'm smart enough to figure that part out, at least! :)
>
> Break it down into smaller parts. Use intermediate variables. Se my
> previous message (the part just before the stuff you quoted, above) for
> how you have to work-backwards to calculate 2 different parts. Do them
> separately, in separate, intermediate variables. (Don't optimize while
> you're still trying to get the algorithm right!)
>
> Remember that Math.foo() trig functions typically deal in radians. I
> don't know what language you're using, but asin() & acos() might want
> you to normalize (fit onto the unit-circle) your factors.
At the moment I'm using ActionScript (Flash, hence the .swf preview I
posted), and you are right, it deals in radians.
>
> I notice in your calculation, you completely omitted time. Time
> matters. That's why I said you have to figure the X-part first. (See
> previous message.) I'm guessing that your green line is the angle you
> WOULD shoot if the bullet arrive in 1 unit of time (1s), but it doesn't,
> so it's wrong.
This is where I get the most confused, I think. While I understand
time must matter, I don't understand how it plays in to my problem. I
can't know the time it will take to reach the target until I know the
trajectory, can I? And where does time play into this function:
http://upload.wikimedia.org/math/7/7/8/7786a0d50b1eb268db50f84665b01f35.png
Thanks again for your time!
Aaron Beall
> > Remember that Math.foo() trig functions typically deal in radians. I
> > don't know what language you're using, but asin() & acos() might want
> > you to normalize (fit onto the unit-circle) your factors.
>
> At the moment I'm using ActionScript (Flash, hence the .swf preview I
> posted), and you are right, it deals in radians.
Ok, now I feel stupid. Lost in my confusion about the formula I forgot
to convert radians to degrees. After doing so, the result is very
close:
http://abeall.com/files/flash/tests/Game/trajectory.swf
But for some reason it is still not perfect. I would expect the
trajectory to intersect the target point exactly, instead it seems to
shift to the right as it approaches the maximum range of the specified
velocity. Any idea? Currently I have:
range = target.x - origin.x
angle = 0.5 * Math.asin((GRAVITY*range)/(velocity*velocity))
angle = angle/(Math.PI/180)
Miss Elaine Eos
<71e0aa77-e698-448b...@r35g2000prm.googlegroups.com>,
Aaron Beall <con...@abeall.com> wrote:
> > Don't forget my suggestion to use intermediate variables. They really
> > help you understand things a lot.
>
> When you say "intermediate variables" you mean mean something like
> this?
>
> velocity2 = velocity*velocity;
> gravityRange = GRAVITY*range;
> angle = Math.asin(gravityRange/velocity2)/2;
Yes. It just REALLY helps to see what's going on if you get the
in-between values. I'd go so far as to change
> angle = Math.asin(gravityRange/velocity2)/2;
to
temp = gravityRange/velocity2;
angle2 = Math.asin(temp);
angle = angle2 / 2;
I don't know you or your code, I'm just giving this advice after doing
dozens of projects in ballistics and (especially!) 3d geometry where I
thought I understood things, but really I had some factor or another
reversed or wrong-units, or something. The in-between variables finally
helped me find my bugs.
> > I notice in your calculation, you completely omitted time. Time
> > matters. That's why I said you have to figure the X-part first. (See
> > previous message.) I'm guessing that your green line is the angle you
> > WOULD shoot if the bullet arrive in 1 unit of time (1s), but it doesn't,
> > so it's wrong.
> This is where I get the most confused, I think. While I understand
> time must matter, I don't understand how it plays in to my problem.
Your bullet is going to go up for a while, then come down for a while.
Its "up" trajectory is going to be part of the angle it was shot at, the
sin of that angle, in fact. The "down" part is going to be from
gravity. But HOW MUCH DOWN changes over time.
Hence:
* First, figure out the amount of time it would take the bullet to get
to its destination-X (ignore the Y value for now). So, if it's
traveling at 35 fps, and the destinationX = startX + 350, then it's 10
seconds.
* THEN figure out what angle you'd have to fire the bullet so that, WITH
NO GRAVITY, it would end up at destinationX,destinationY+(10*gravity)
* THEN, when you fire the bullet at that angle, it will head toward that
spot (dX,dY+(10g)), except that 10s worth of gravity will make it fall,
so it'll end up at dX,dY+(10g)-(10g) or dX,dY -- and that's what you
want.
But FIRST, you have to figure out how many seconds it will take to get
to the destination, just along the X axis. Oh, and you have to adjust
that because X will be longer along the hypotenuse, since you're
shooting up at an angle.
See?
> can't know the time it will take to reach the target until I know the
> trajectory, can I?
Sort of. For now, let's say your target is same elevation as gun. (You
can adjust for elevation later, I'm just simplifying the explanation.)
Pretend there's no gravity, for now.
d = distance to target.
v = velocity of bullet.
velocity = distance / time
... velocity * time = distance
... time = distance / velocity
Time for bullet to arrive with no gravity: t = d/v
NOTE: later, d is going to be the horizontal leg of a right triangle.
Go ahead & draw that on your napkin, for now ;)
In time (t), gravity makes you fall according to gravitational constant,
which contains a fragment "...over time squared." So it looks something
like this:
g = 9.2 / t^2 // Earth gravity = 9.2 meters per second squared.
So we now know that, in t seconds, your bullet will fall t^2 * 9.2 (or
whatever your gravity is) meters (or pixels, or whatever.)
So the VERTICAL leg of your right triangle is that long.
Now you have the spot you need to aim your gun at. It's the top corner
of that triangle. Use asin() to figure out the angle. Don't forget
that you have to normalize (that is, divide your Y by our X, to make it
fit on the unit circle.)
Luck!
> And where does time play into this function:
> http://upload.wikimedia.org/math/7/7/8/7786a0d50b1eb268db50f84665b01f35.png
Am I right that v, in that function, = velocity? Velocity can be
written as d/t (distance / time). So v^2 has time in it.