Integrating Force And Torque
I'm currently working on a 2D physics library starting with particles. They behave correctly, but don't seem to accelerate and respond to forces properly. I believe my function for updating them is correct, but I wanted to make sure before I just assume it's my input forces. Is this correct?
Code:
void SimParticle::integrateForceAndTorque( float timeStep ) {
m_linearAcceleration = m_force / m_mass;
m_linearVelocity += m_linearAcceleration * timeStep;
m_position += m_linearVelocity * timeStep;
m_angularAcceleration = m_torque / m_mass;
m_angularVelocity += m_angularAcceleration * timeStep;
m_angle += m_angularVelocity * timeStep;
if( m_angle < 0.0f )
m_angle += 360.0f;
else if( m_angle > 360.0f )
m_angle = 360.0f;
m_force.set( 0.0f, 0.0f );
m_torque = 0.0f;
}
Yeah, that's pretty standard Euler integration. It won't give you completely accurate results if that's your problem. Smaller time steps or a better integration technique would help.
Exact integration would be as trivial to implement, but slightly slower. Considering the expense of drawing the particles vs. simulating them, I'd go with exact integration anyway.
Exact integration would be as trivial to implement, but slightly slower. Considering the expense of drawing the particles vs. simulating them, I'd go with exact integration anyway.
Scott Lembcke  Howling Moon Software
Author of Chipmunk Physics  A fast and simple rigid body physics library in C.
Skorche Wrote:Yeah, that's pretty standard Euler integration. It won't give you completely accurate results if that's your problem. Smaller time steps or a better integration technique would help.What would be a good search term to find out how to get better integration? Dealing with 2D I'd rather be accurate. Plus I am finding out that OpenGL is causing more slow downs than my physics.
Exact integration would be as trivial to implement, but slightly slower. Considering the expense of drawing the particles vs. simulating them, I'd go with exact integration anyway.
It's pretty basic calculus. You've probably encountered the equation in a physics book without even knowing it was derived using calculus.
For constant acceleration, the position is simply:
s(dt) = s0 + v0*dt + (1/2)*a*dt^2
where s0 is the initial displacement, and v0 is the initial velocity.
So you'd do something like this instead:
Notice that the position is updated before the velocity.
[/quote]
So it boils down to a couple more multiplications and an addition.
A couple of other random suggestions:
1) Use radians instead of degrees. Radians are mathematically simpler than degrees and are a natural unit for many physics equations. It will make your life simpler down the road.
2) Unless you specifically need your angle to be in the range [0, 360), just normalize using: angle = angle%360.0f
3) (Highly controversial) Learn the physics equations and use the standard physics names for variables. f = ma is readily recognizable, z_force_linear = object_mass*acceleration_due_to_something is not. This makes it much easier to spot mathematical problems in my code anyway.
For constant acceleration, the position is simply:
s(dt) = s0 + v0*dt + (1/2)*a*dt^2
where s0 is the initial displacement, and v0 is the initial velocity.
So you'd do something like this instead:
Notice that the position is updated before the velocity.
Code:
void SimParticle::integrateForceAndTorque( float timeStep ) {
m_linearAcceleration = m_force / m_mass;
m_position += m_linearVelocity * timeStep + m_linearAcceleration*0.5f*timeStep*timeStep;
m_linearVelocity += m_linearAcceleration * timeStep;
//angular effects are similar
//...
}
So it boils down to a couple more multiplications and an addition.
A couple of other random suggestions:
1) Use radians instead of degrees. Radians are mathematically simpler than degrees and are a natural unit for many physics equations. It will make your life simpler down the road.
2) Unless you specifically need your angle to be in the range [0, 360), just normalize using: angle = angle%360.0f
3) (Highly controversial) Learn the physics equations and use the standard physics names for variables. f = ma is readily recognizable, z_force_linear = object_mass*acceleration_due_to_something is not. This makes it much easier to spot mathematical problems in my code anyway.
Scott Lembcke  Howling Moon Software
Author of Chipmunk Physics  A fast and simple rigid body physics library in C.
% doesn't work with floatingpoint numbers
OneSadCookie Wrote:% doesn't work with floatingpoint numbers
*Smacks forehead*
Yeah, so I meant really meant fmodf().
Scott Lembcke  Howling Moon Software
Author of Chipmunk Physics  A fast and simple rigid body physics library in C.
Possibly Related Threads...
Thread:  Author  Replies:  Views:  Last Post  
Force Touch Events?  Ropeburn  12  10,744 
Feb 9, 2011 11:47 PM Last Post: omarmaris 

Is Force Feedback broken in Tiger?  Andrew  3  3,967 
Aug 23, 2005 03:59 AM Last Post: Andrew 

Torque: Help for Beginners  AGhost  17  11,759 
Dec 30, 2004 07:09 PM Last Post: Dr. Light 

Torque: RTS Starter Kit  First Impressions  BeyondCloister  4  6,171 
Nov 29, 2004 12:47 PM Last Post: BeyondCloister 

Force feedback example?  rvangaal  7  5,668 
Mar 24, 2003 03:01 AM Last Post: rvangaal 