# Soccer ball motion approximation

Started by Jul 27 2001 02:47 AM

,
3 replies to this topic

###
#1
Members - Reputation: **122**

Posted 27 July 2001 - 02:47 AM

A year ago, I started developing a soccer game called OpenKickOff (www.openkickoff.org) based on the famous KickOff2 game.
Okay my trouble is... ball motion !
What I found a long time ago are those 2 equations providing x(t) and z(t):
x(t) = M/K*v*cos(angle))*(1-exp(-K/M*t))
z(t) = M/K*(v*sin(angle)+M*G/K)*(1-exp(-t*K/M))-M*G/K*t+h0
Where:
M is the ball mass
v the initial velocity at ball kick
angle the initial vertical angle at ball kick (0 = horizontal)
K air resistance constant
G = 9.81 m.s-2
This works fine but require high calculation along the game.
Are there other equations to approximate ball motion during a soccer game that are frequently used in game design ?
herve@openkickoff.org

###
#2
Members - Reputation: **351**

Posted 27 July 2001 - 05:13 AM

There are two obvious optimisations:

First you need to only calculate cos(angle) and sin(angle) once per kick. You may be able to calculate them together, e.g. some APIs provide a SinCos function which works them both out at once.

Second you do not need to use exp to do drag. Exp arises when you try to write down a precise formula for the position at all times, as it''s the solution to an equation of motion of a particle with linear drag.

But you can intead use numerical techniques. The first equation can be derived from the equation of motion

dv

-- = -Kv/M

dt

where v is the velocity. This can be used to update the horizontal velocity u with the approximation formula

u = u - (K * u / M) * t

where t is the time step between updates.

Then use

x = x + u * t

to update x.

Similarly for the vertical motion use

v = v - (K * v / M + G) * t

and

z = z + v * t

Because u, v, x and z are calculated from previous values they need to be initialised, and for your situation this would be

u = V * cos(angle)

v = V * sin(angle)

x = 0

z = h0

where ''V'' is the launch speed.

It''s important to note that these numerical methods are approximations: over even a short time step u and v are changing, so calculations done with them are incorrect by the end of the time step.

It is therefore important that the time step is as small as possible, and so that updates are done as often as possible. This is usually one of the key decisaions in designing a simulation, and it''s difficult to give precise recommendations, but it''s often best to use an fixed update rate different from the frame rate if it can vary.

First you need to only calculate cos(angle) and sin(angle) once per kick. You may be able to calculate them together, e.g. some APIs provide a SinCos function which works them both out at once.

Second you do not need to use exp to do drag. Exp arises when you try to write down a precise formula for the position at all times, as it''s the solution to an equation of motion of a particle with linear drag.

But you can intead use numerical techniques. The first equation can be derived from the equation of motion

dv

-- = -Kv/M

dt

where v is the velocity. This can be used to update the horizontal velocity u with the approximation formula

u = u - (K * u / M) * t

where t is the time step between updates.

Then use

x = x + u * t

to update x.

Similarly for the vertical motion use

v = v - (K * v / M + G) * t

and

z = z + v * t

Because u, v, x and z are calculated from previous values they need to be initialised, and for your situation this would be

u = V * cos(angle)

v = V * sin(angle)

x = 0

z = h0

where ''V'' is the launch speed.

It''s important to note that these numerical methods are approximations: over even a short time step u and v are changing, so calculations done with them are incorrect by the end of the time step.

It is therefore important that the time step is as small as possible, and so that updates are done as often as possible. This is usually one of the key decisaions in designing a simulation, and it''s difficult to give precise recommendations, but it''s often best to use an fixed update rate different from the frame rate if it can vary.

###
#4
Anonymous Poster_Anonymous Poster_*
Guests - Reputation:

Posted 03 August 2001 - 09:11 AM

Other things to note:

Velocity in the non-vertical directions (the directions not effected by gravity) is virtually constant while the ball is in the air. Air resistance will have some effect, but if you need to speed it up more, compute the horizontal velocity once.

Air resistance will be almost negligable.

Also, mass of an object does not effect an object once it is in the air.

While these will cause your code to be inaccurate, the inaccuracies will be inconsequential for a soccer game. They will speed it up a little bit though, which is more important than being 100% accurate.

Velocity in the non-vertical directions (the directions not effected by gravity) is virtually constant while the ball is in the air. Air resistance will have some effect, but if you need to speed it up more, compute the horizontal velocity once.

Air resistance will be almost negligable.

Also, mass of an object does not effect an object once it is in the air.

While these will cause your code to be inaccurate, the inaccuracies will be inconsequential for a soccer game. They will speed it up a little bit though, which is more important than being 100% accurate.