Jump to content

  • Log In with Google      Sign In   
  • Create Account

lastcodewarrior

Member Since 06 Jan 2008
Offline Last Active May 03 2012 04:42 AM

Posts I've Made

In Topic: 2D airplane physics calculations

03 May 2012 - 04:41 AM

I must admit that I haven't inspected your code very thoroughly. However, the physics of a plane is made of the "four forces":

- gravity
- lift
- drag
- engine power (this one may be absent in gliders)

Gravity is trivial to compute (it's a fixed amount always directed downward in the earth reference frame).

Lift and Drag are very similar. They both depends upon speed (squared) and other factors (air density and other constants depending upon the plane's geometry); they must be calculated using the absolute speed of the plane, and then applied in the right direction: drag must be applied in the opposite direction of speed, lift must be applied toward the plane "top", in the plane reference frame (NOT in the earth absolute reference frame!).

Engine power is applied toward the plane "front", again in the plane reference frame.

If you're doing everything correctly and the plane is still continuously accelerating, you're probably using an unrealistic lift/drag ratio, ie you're generating too much lift and too few drag so that you're violating energy conservation. In that case, simply try to reduce the lift coefficient (and/or increase the drag one) until the system becomes "stable"...

In Topic: collision detection w/compenetration

03 May 2012 - 04:15 AM

Also consider separate collision geometry. Graphic meshes build up in complexity much faster than collision can handle.

Yes, you are right, but from my previous example you can see that I'm having problems even with a very very simple geometry (a perfectly flat wall made by a simple triangle strip). Thank you, however, for the gimpact link, I'll give it a look!

In Topic: collision detection w/compenetration

03 May 2012 - 04:10 AM

I can't quite envision the situation where this happens

Well, look at the picture attached. The grey triangles are part of the wall, and the red one is part of the object. The red triangle is colliding with the wall (the 'c' vertex is penetrating the wall with a penetretation depth showed by the green arrows). Problem is that the red triangle is in collision with two wall triangles, both sharing the a-b side, and when the narrow-phase triangle-to-triangle collider calculates the penetration depth it will report a side-to-side collision between one (well, both) of the grey (wall) triangles a-b side and the red (object) triangle c-d side (showed by the blue arrows), because maybe the "blue" penetration depth is smaller than the "green" one. So, the collision normal will be reported along the blue line, whereas it's quite obvious that this is a "wrong" collision normal and that in that case the only "right" collision normal should be along the green line. Any subsequent penalty force applied to the red object, of course, will be wrong and the object will rebounce in a "wrong" way (which is, btw, exactly what is happening to me...) Posted Image

PARTNERS