Integrating Force And Torque
Post: #1
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;
}
Post: #2
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.
Post: #3Skorche 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.
Post: #4
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.
Post: #6OneSadCookie Wrote:% doesn't work with floating-point 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 | 8,583 |
Feb 9, 2011 11:47 PM Last Post: omarmaris |
|
| Is Force Feedback broken in Tiger? | Andrew | 3 | 3,263 |
Aug 23, 2005 03:59 AM Last Post: Andrew |
|
| Torque: Help for Beginners | AGhost | 17 | 9,532 |
Dec 30, 2004 07:09 PM Last Post: Dr. Light |
|
| Torque: RTS Starter Kit - First Impressions | BeyondCloister | 4 | 5,296 |
Nov 29, 2004 12:47 PM Last Post: BeyondCloister |
|
| Force feedback example? | rvangaal | 7 | 4,284 |
Mar 24, 2003 03:01 AM Last Post: rvangaal |
|