Archived

This topic is now archived and is closed to further replies.

GekkoCube

Doing Physics for a Projectory.

Recommended Posts

I came up with two possible methods to have a projectory (essentially a cannon ball shooting out of a cannon)... 1) Use an interpolation formula that will render my cannon in a projectory to a pre-defined target. (from ground-to-ground). 2) Use a simple velocity vector along with a position vector while applying gravity to the velocity vector to make the cannon "naturally" render it''s own projectory course. Im wondering what would be best for a game situation where the following are considered: - Speed over accuracy. - Must hit a pre-defined target. thanks

Share this post


Link to post
Share on other sites
The second option is probably the way to go. The initial velocity can be computed when the cannon fires and then each frame all you have is velocity.y -= gravity * deltaTime. Where y is the vertical component of the projectiles velocity and deltaTime is the time between frames.

Share this post


Link to post
Share on other sites
The only caution I can give on the second approach is to make sure that DeltaT is as small as prudent. --Especially if you are using different force equations, such as a strong gravity well in a solar system simulator.

Share this post


Link to post
Share on other sites
Using an exact equation is more accurate, and you won''t have any significant speed decreases because the projectile position equation is relatively simple to use. A few square roots is the biggest hurdle, however you shouldn''t put too much worry into them.

If you find the equations are too slow, then use the second option.

Share this post


Link to post
Share on other sites
I wrote a projectile simulation program. If you want true physics i would recommend getting a book on it. I could be wrong with mine, but if i remember correctly i had to use two differnt formulas for calculating the time the projectile was in the air depending on angle and velocity.

I''ll try and get the program online sometime for you to take a look at.

Share this post


Link to post
Share on other sites
Wow thanks guys, and you too Prod for your help.

I was thinking of the first option too, the trajectory formula method since it''s the only easy way that I know for the projectile to hit a pre-defied target.

Now, can anybody post the physics for a trajectory?
im sure i''ll need to play with it to look right, but for now, im guessing its something like:


  
// trajectory formula, where speed is time elapsed * a

// certain speed.

y1 = y0 + velocity.y * speed;
position += velocity;

Share this post


Link to post
Share on other sites
oops!
Right after I posted my last post I realized that was a big mistake...that is NOT the formula for the 1st method, nor is it the formula for the 2nd method (there is no gravity)!!

Interpolating a trajectory based on a known target is not something I know right off the bat. I''ll need a physics book for that.


Can anyone provide info or a url?

Share this post


Link to post
Share on other sites
quote:
Original post by Nypyren
The only caution I can give on the second approach is to make sure that DeltaT is as small as prudent. --Especially if you are using different force equations, such as a strong gravity well in a solar system simulator.


As Zipster suggested, for simple projectile motion of a cannon ball, which only requires an initial angle and velocity (calculated based on the launch point and destination point), the most appropriate approach is to use an exact ("closed form") equation, which is perfectly stable and gives the exact answer at any time.

Just some comments on numerical integration (which can accommodate different types of gravity, wind forces, electromagnetic forces, etc.) for this type of projectile motion problem.

DeltaT probably won't be a problem here, even if he uses simple Euler integration. Reason is, DeltaT stability problems generally only occur when the forces acting on the object are "oscillatory," or spring-like. The cannon ball projection problem as described does not need to have any oscillatory forces. The only concern is that a large DeltaT will put the cannon ball slightly off course. There wouldn't be any instability.

I'll describe a bit further. Since he's talking about a cannon ball, the gravitational force will probably be defined to always be "straight down." He will/should ignore the fact that it is really towards the center of the Earth/planet. Because of this, the gravitational force is independent of the position of the cannon ball. It is constant, or at least always positive in the downward direction. And a constant force is not oscillatory. Therefore, causes no stability problems with numerical integration other than accuracy.

If any collision/response is to be implemented, then DeltaT can be a problem and the numerical method should be carefully selected. (And simple Euler is not the right choice.)

A more accurate gravitational force, that points towards the center of the planet, is an oscillatory force, since its direction and amplitude is a function of the position relative to the planet core. In this case, DeltaT and numerical method are important.




Graham Rhodes
Senior Scientist
Applied Research Associates, Inc.

[edited by - grhodes_at_work on March 18, 2003 10:31:07 PM]

Share this post


Link to post
Share on other sites
Oh my....all I want is a quick ''n easy way for an object to go from point A to point B in a trajectory fashion. No advanced oscillation, magnetism, or weather applied to it.
And for my game, and probably any game, a gravity of simply pointing straight down should be sufficient, me thinks.

And why would an Euler method notbe good if collision is expected to be done?

thanks for all the input.

Share this post


Link to post
Share on other sites
I''m not too familiar with the stability issues of DeltaT (not because I think they don''t exist, just because I haven''t done much work with it before), but if the accuracy of the projectile isn''t perfect, then neither will be the collision response, as it won''t record the true collision, just the collision using your "rough estimate" data. It''s something along those lines I hope

Share this post


Link to post
Share on other sites
Come on people!!

P0 is the initial location
V0 is the initial velocity
t is the time
g is the acceleration due to gravity (-32 f/s/s or -9.8 m/s/s)
P is the position at after t seconds
V is the velocity after t seconds
y is up


  
V.x = V0.x;
V.y = V0.y + g * t
V.z = V0.z;

P.x = P0.x + V0.x * t;
P.y = P0.y + V0.y * t + .5 * g * t * t;
P.z = P0.z + V0.z * t;


If you represent acceleration due to gravity as a vector G , it is even easier and it works no matter which way is down:


  
V = V0 + G * t;
P = P0 + V0 * t + G * ( t * t * .5 );


You can compute it incrementally your result will diverge from the actual trajectory because you are changing the velocity in increments when it is actually changing continuously.

Share this post


Link to post
Share on other sites