Jump to content
  • Advertisement
Sign in to follow this  
kylecrass

Help with acceleration

This topic is 4477 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi! Okay I have been working on my game for awhile and its been nmissing something crucial, acceleration. The game would be fine if it were just characters moving around, but i am making a sci-fi game that uses space ships, and they need to model acceleration My collision detection system uses delta t and velocity vectors atm, first off if i use acceleration will i have to modify existing collision routine? Now, how do i implement acceleration? I am at a loss I thought i would do this: speed = speed + (delta t) * acceleration but that does not seem to work...am i missing something?

Share this post


Link to post
Share on other sites
Advertisement
1. use a force and a mass on your spaceship. Say like force 10, mass 2 => accel 10/2 =5 or with the same force but with a bigger mass like 5 you only get accelation to 2. The bigger the ship the slower the acceleration.

2.
speed = speed + (delta t) * acceleration

this seems correct. Do you remember that accelaration and speed is a vector. And did you also do position = position + speed * (delta t) to get the new position. Position is also a vector.

Share this post


Link to post
Share on other sites
Quote:
Original post by kylecrass
I thought i would do this:

speed = speed + (delta t) * acceleration

but that does not seem to work...am i missing something?


This would work all right (assuming of course you're doing the same to find position from speed, as Zyberant suggested), it is -in fact- numerical integration, but this one (euler's method) is prone to some problems and it's not that accurate for more advanced simulations.

Make sure to use a constant, small enough timestep. Else you'll get jittering objects and the time will not be uniform... I suggest you do sth like this:

void SimulationHeartBeat()
{

1. const float dt = 1.f/60.f; (max)
2. unprocessed_time += (time - last_update_time);
3. while( unprocessed_time > dt )
{
4. update_simulation_objects();
5. unprocessed_time -= dt;
}
6. last_update_time = time;
}


This will make sure that the required number of simulations will have been performed, anytime...

Share this post


Link to post
Share on other sites
Quote:
Original post by someusername
... but this one (euler's method) is prone to some problems and it's not that accurate for more advanced simulations.

What I coincident! I have just released a demo showing the differerence in accurucy between the Euler integration and the more sophisticated 4th order Runge-Kutta integration (aka RK4).

Check out the thread RK4 vs Euler integration (for physics in games) demo, GPL:ed C#/MDX app to get more information. Spoiler: Euler integration sucks for non trivial games.

[Edited by - Enselic on March 12, 2006 5:56:18 AM]

Share this post


Link to post
Share on other sites
Well, to start with theory, Euler's method is a 2nd order method while the spcific RK is 4th order. This means that the cutoff error from the entire Taylor expansion is -in 1st case- of the order of magintude of dt3, while in the RK it reduces to order of dt5. (!)

Euler's method introduces severe errors especially with integrands that have quite large (and quite often) maximum values of second derivative (like stiff spring forces). This quantity can be considered a measure of how fast the rate of change of the integrand is, and affects immediately the stability of Euler's method since it controls how much of the function's curve may end up completely missed/ignored by the method...

However, don't rush to deem it useless. Considering the CPU overhead in both cases, many would opt for Euler instead, especially in games where maximum possible precision isn't *that* necessary...

Share this post


Link to post
Share on other sites
Well, I would also like to use jerk in my simulation, the third order derivative of velocity right?

v = dp / dt
a = dv / dt
j = da / dt

so, if i use the formula of f(x) = xi + vi * (x) + [a * (x)²] / 2

implementing jerk would expand the equation to this right? (Using integration)

f(x) = xi + vi * (x) + [a * (x)²] / 2 + [j * (x)³] / 6

if so, then i would do this if using a time step right?

a += j * dt
v += a * dt
p += v * dt

am i right?

Also, If I am using jerk, (or even if not), if delta t can fluctuate, how badly will it mess up my simulation? Obviously if delta time is 1 second, it will be very off course, will jerk make the error more pronounce using the euler method? I mean, I know if delta t was ideal it would be the limit as it approches 0 :P But in this particular situation I will never get delta t below 1/120th a second and delta t will never go above 1 second.

Share this post


Link to post
Share on other sites
f(x) = xi + vi * (x) + [a * (x)²] / 2
f(x) = xi + vi * (x) + [a * (x)²] / 2 + [j * (x)³] / 6

isn't it f(t). t instead of x. You use time to get the position.

Also this is the exact method. Given some start condition and the time, you get the exact position. The delta time is another method.

If the start condition change with the time then i don't think you can use the exact method then. This is where the delta time method come in.

Share this post


Link to post
Share on other sites
@Kylecrass
If you've figured out an (independent) way to calculate the derivative of the acceleration, and then calculate all other quantities (acceleration, velocity, position) from it, then theoretically, yes, you would have better accuracy. You would have limited the cutoff error by a whole order of magnitude!
This is theoretical though; I don't know whether the extra integration will cost any precision loss, but it should be better.
Notice though, that you'll have to come up with a way to calculate the derivative of acceleration first.
I mean, don't do something like that: (It's not gonna make a difference!)

1. prevAcc = a;
2. a = (total F)/mass;
3. v+= a*dt;
4. x += v*dt + (1/2)*a*dt2 + (1/6)*((a-prevAcc)/dt)*dt3



@Zyberant
Quote:

isn't it f(t). t instead of x. You use time to get the position.

Also this is the exact method. Given some start condition and the time, you get the exact position. The delta time is another method

You can use anything to get position, so long as it is expressed with respect to that quantity. Of course, its derivatives wouldn't be -then- velocity and acceleration, but it is perfectly legal...
The Taylor series expansion of a function, around any point x0 of its domain, is:
f(x) = f(x0) + (x-x0)*f'(x0) + (x-x0)2*f"(x0)/2 + ... + (x-x0)n*f(n)(x0)/n!

If "x" was time "t" instead, then substituting t=t0+dt in the formula, yields:
f(t0+dt) = f(t0) + dt*f'(t0) + dt2*f"(t0)/2 + dt3*f(3)(t0)/3! + ...

Therefore, the "dt" formula is the very same thing.
(You meant this one, didn't you?)

Share this post


Link to post
Share on other sites
sweet yeah I was thinking of that exact extra derivation


//ForcesApplied would be a list of forces, applied to an object
totalforcevector = Sum(ForcesApplied)

jerkvector = totalforcevector / mass

accelerationvector += (jerkvector * dt);
velocityvector += (acceleration * dt)
posvector += (velocityvector * dt);

This method should theoretically give me better precision?

I can use the extra processing in my game cuz its going to be used in one of those fancy new games coming up ;)

I have taken calc, quite a few classes actually....but the sad ting is they hadn't gone into much detail about this :(

Share this post


Link to post
Share on other sites
Quote:

This method should theoretically give me better precision?

I really doubt you can tweak the Euler method to get any better precision. The only way is to decrease the timestep, and it doesn't come cheap.

If you really need precision, I suggest you should turn to another integration method like Verlet or RK4, especially if you'll be dealing with springs and constraints.
Verlet is still 2nd order, however it calculates position without using any velocity, thus restricting the error to a minimum. Constraints are also very easy to implement with verlet.

RK on the other hand, is far more accurate, because it uses an estimated "average" value of the derivative throught the timestep, but be prepared to pay the price in cpu overhead.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!